Re[13]: Про NoSQL
От: ArhAngelVezel Россия  
Дата: 03.12.10 11:54
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Неверно, объект это то что имеет Identity в первую очередь. Все в базе SQL Server имеет стурктурную эквивалентность.

Wiki: Объект (программирование) — некоторая сущность в виртуальном пространстве, обладающая определённым состоянием и поведением, имеет заданные значения свойств (атрибутов) и операций над ними (методов).
Тут мы имеем объект и методы работы с ним.

G>Поэтому не объект. Думаешь что-нить принципиально изменилось бы если бы писали GetLevel(HIERARCHYID id)?

Нет.. Это одна из ранних разновидностей ООП...



AAV>>Проблема в том что NoSQL глубоко залез в современные RDBMS. Или они в него залезли. В общем любой NoSql это просто сильно обрезанный заоптимизированный RDBMS, и если его расширять то мы получим RDBMS, и наоборот если уменьшать и оптимизировать доступ до RDBMS можно получить NoSql. Чем в общем не гнушаются производители RDBMS всовывая в себя элементы NoSql...

G>Большего бреда не читал никогда.
А вы почитайте и подумайте. А прежде всего скажите нам, что по вашему RDBMS, а что NoSql...
Re[14]: Про NoSQL
От: ArhAngelVezel Россия  
Дата: 03.12.10 11:56
Оценка: -2
Здравствуйте, gandjustas, Вы писали:

G>Такому явлению как NoSQL

Ржуу... Конфигурационные файлы в Unix по сути NoSql...
Re[14]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 12:03
Оценка:
Здравствуйте, ArhAngelVezel, Вы писали:

AAV>Здравствуйте, gandjustas, Вы писали:


G>>Неверно, объект это то что имеет Identity в первую очередь. Все в базе SQL Server имеет стурктурную эквивалентность.

AAV>Wiki: Объект (программирование) — некоторая сущность в виртуальном пространстве, обладающая определённым состоянием и поведением, имеет заданные значения свойств (атрибутов) и операций над ними (методов).
AAV>Тут мы имеем объект и методы работы с ним.
"Состояние и поведение" слова ни о чем. Так объектами можно вообще все назвать, и целые числа тоже.
Нужен критерий отделения объектов от не-объектов. Основной критерий это наличие Identity, которого как раз БД нету и не будет.


G>>Поэтому не объект. Думаешь что-нить принципиально изменилось бы если бы писали GetLevel(HIERARCHYID id)?

AAV>Нет.. Это одна из ранних разновидностей ООП...
Ну тогда весь SQL это ООП язык.
Бред короче.


AAV>>>Проблема в том что NoSQL глубоко залез в современные RDBMS. Или они в него залезли. В общем любой NoSql это просто сильно обрезанный заоптимизированный RDBMS, и если его расширять то мы получим RDBMS, и наоборот если уменьшать и оптимизировать доступ до RDBMS можно получить NoSql. Чем в общем не гнушаются производители RDBMS всовывая в себя элементы NoSql...

G>>Большего бреда не читал никогда.
AAV>А вы почитайте и подумайте. А прежде всего скажите нам, что по вашему RDBMS, а что NoSql...
Берем существующие хранилища и смотрим на них.
Со стороны SQL у нас MS SQL Server, oracle, DB2, mysql, postgres, firebird
Со стороны NoSQL: couchdb, mongodb, cassandra, redis, raven

Классифицировать алгоритмы не буду, они не зависят от хранилища.
Re[17]: Про NoSQL
От: ArhAngelVezel Россия  
Дата: 03.12.10 12:07
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>Ну и? приведешь как сделать указанный мной запрос на mongodb?


db.documents.find({"accepted": "иванов", "date_accepted" : { $gt: date1, $lt: date2 } }).skip((pageNumber-1)*nPerPage).limit(nPerPage)
Re[18]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 12:11
Оценка:
Здравствуйте, ArhAngelVezel, Вы писали:

AAV>Здравствуйте, gandjustas, Вы писали:


G>>Ну и? приведешь как сделать указанный мной запрос на mongodb?


AAV>db.documents.find({"accepted": "иванов", "date_accepted" : { $gt: date1, $lt: date2 } }).skip((pageNumber-1)*nPerPage).limit(nPerPage)


"Визы" это список, привязанный к документу.
Категории забыл.
Re[13]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 03.12.10 12:11
Оценка:
A>hierarchyid — специальный тип для хранения иерархических отношений

имхо, для иерархических данных пользовать какой-нить graph db + gremlin. но эти базы вообще в зачаточном состоянии


dmitriid.comGitHubLinkedIn
Re[7]: Про NoSQL
От: Mamut Швеция http://dmitriid.com
Дата: 03.12.10 12:15
Оценка:
M>>>>>С NoSQL что еще плохо — то, что этот buzzword объял слишком разные системы, предназначенные для слишком разных нужд. То есть и на всю голову шизанутая Cassandra — это NoSQL и любое key-value хранилище — тоже NoSQL.
F>>>> По моему глупо пихать SQL сервер туда где достаточно key-value хранилища, разве нет?

G>>>А где его достаточно? Таких задач исчезающе мало.


M>>memcached, который некоторые заменяют redis'ом, например

G>Те NoSQL это не более чем распределенный кеш?

Тек, которые key-value store — по сути, да

M>>вообще, все можно свести к понятию «ключ-значение» при условии, что «значение» может быть достаточно сложным

G>Да, тогда станет вопрос о том как получать список нужных ключей. Собственно язык SQL дает ответ на этот вопрос, а различные NoSQL хранилища — нет.

Вообще-то, отвечают. Но кадый — по-разному.

G>Полнотекстовым индеском все не заменишь, а вручную создавать индексы под каждый запрос — как то слишком круто.


Можно и не создавать

NoSQL — это не только kv-store И в этом проблема — так как каждый под NoSQL подразумевает что-то свое.


M>>тот же couchdb, кторый весь хайп и начал, по сути, тоже есть ничто иное, как «ключ-значение». Только значение — это документ произвольной форы, который можно скармливать в map/reduce для получения плюшек и девиц (или домомучительниц — это как кому повезет )

G>Ну кучадб используется в очень малом количестве проектов. StackOverflow на нем не сделаешь.

Сделаешь StackOverflow — очень легкий с точки зрения логики сайт. На CouchDB ляжет на раз Только не надо У CouchDB есть свои проблемы.


dmitriid.comGitHubLinkedIn
Re[15]: Про NoSQL
От: ArhAngelVezel Россия  
Дата: 03.12.10 12:19
Оценка: :)
Здравствуйте, gandjustas, Вы писали:

G>"Состояние и поведение" слова ни о чем. Так объектами можно вообще все назвать, и целые числа тоже.

В SmallTalk так и есть ...

G>Со стороны SQL у нас MS SQL Server, oracle, DB2, mysql, postgres, firebird

G>Со стороны NoSQL: couchdb, mongodb, cassandra, redis, raven

G>Классифицировать алгоритмы не буду, они не зависят от хранилища.

А вот и нет:
couchdb, mongodb — это документоорентированные базы
cassandra — это столбцоорентированная база
redis — это key-value орентированная база.

А в первой строчке у вас одни RDBMS...

http://habreffect.ru/files/814/5d37eb18d/visualguide.png
Re[8]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 12:20
Оценка:
Здравствуйте, Mamut, Вы писали:

M>>>тот же couchdb, кторый весь хайп и начал, по сути, тоже есть ничто иное, как «ключ-значение». Только значение — это документ произвольной форы, который можно скармливать в map/reduce для получения плюшек и девиц (или домомучительниц — это как кому повезет )

G>>Ну кучадб используется в очень малом количестве проектов. StackOverflow на нем не сделаешь.

M>Сделаешь StackOverflow — очень легкий с точки зрения логики сайт. На CouchDB ляжет на раз Только не надо У CouchDB есть свои проблемы.

Да ну?
Не удалось ни тут
Автор: gandjustas
Дата: 29.09.10
, ни там
Re[16]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 12:22
Оценка:
Здравствуйте, ArhAngelVezel, Вы писали:

AAV>Здравствуйте, gandjustas, Вы писали:


G>>"Состояние и поведение" слова ни о чем. Так объектами можно вообще все назвать, и целые числа тоже.

AAV>В SmallTalk так и есть ...
А толку?


G>>Со стороны SQL у нас MS SQL Server, oracle, DB2, mysql, postgres, firebird

G>>Со стороны NoSQL: couchdb, mongodb, cassandra, redis, raven

G>>Классифицировать алгоритмы не буду, они не зависят от хранилища.

AAV>А вот и нет:
AAV>couchdb, mongodb — это документоорентированные базы
AAV>cassandra — это столбцоорентированная база
AAV>redis — это key-value орентированная база.
Так это все и есть NoSQL.

AAV>А в первой строчке у вас одни RDBMS...

Именно.
Re[10]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.12.10 12:29
Оценка:
Здравствуйте, noetic, Вы писали:

N>netch80 спрашивал именно о целесообразности такой укладки. просто указал на правильный акцент в вопросе

Так вот я и спрашиваю, в чем его проблема? вот это — правильный акцент.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[6]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.12.10 12:29
Оценка:
Здравствуйте, netch80, Вы писали:

N>Где тут "не ложится"? Тут неадекватность, неэффективность, громоздкость укладки.

Переводя на русский — это и есть "не ложится". =)

N>Возвращаюсь к исходному. Я привёл пример задачи. Чуть обобщу: есть key-value хранилище с иерархией ключей. Операции — выборка по конкретному ключу, выборка поддерева от одной точки, добавление/замена/удаление по ключу, удаление поддерева. То есть вообще ничего хитрого.

В Реляционках для этого давно есть специальные типы данных. А до этих типов данных было несколько разнообразных решений в зависимости от конкретного сценария, так что не вижу тут никакой проблемы =)
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[9]: Про NoSQL
От: Cyberax Марс  
Дата: 03.12.10 12:42
Оценка:
Здравствуйте, IB, Вы писали:

N>>Предложи метод укладки, а я оценю его адекватность для наших задач.

IB>Ну, не читать же мне тут тебе ликбез по SQL-ю? =) Уложить в него можно все и это строго математически доказано. )
Ага. Только в заметном числе случаев у нас получается унылое Г. К примеру, в достаточно стандартной задаче представления строки с переменным числом столбцов.
Sapienti sat!
Re[13]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.12.10 12:45
Оценка: 45 (1) +2
Здравствуйте, adontz, Вы писали:

A>Всегда в теле таблицы.

Нет, либо всегда отдельно, либо в теле таблицы до определенного размера.
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[11]: Про NoSQL
От: Cyberax Марс  
Дата: 03.12.10 12:45
Оценка:
Здравствуйте, gandjustas, Вы писали:

G>>>С NoSQL полностью аналогично. По факту лучше NoSQL вообще не использовать как основное хранилище.

N>>Ты опять используешь недоказанные постулаты. А хотелось бы увидеть доказательства.
G>Чуть менее чем все NoSQL базы (я имею ввиду именно хранилища) не имеют ACID транзакций. В итоге для надежного хранения данных в них надо поднимать неслабую инфраструктуру так сказать upfront, еще до того как реально будет сделано что-то нужное.
А тут как бы полный CAP. На практике ты в высоконагруженных системах можешь выбрать только одно из двух — Availability или Consistency. Partition Tolerance — он обязательный.
Sapienti sat!
Re[10]: Про NoSQL
От: IB Австрия http://rsdn.ru
Дата: 03.12.10 12:47
Оценка: +1
Здравствуйте, Cyberax, Вы писали:

C>Ага. Только в заметном числе случаев у нас получается унылое Г.

Ага, в _не_ заметном числе случаев, и если руки под унылое Г. заточены. =)

C> К примеру, в достаточно стандартной задаче представления строки с переменным числом столбцов.

У строки нет столбцов
... << RSDN@Home 1.2.0 alpha 4 rev. 1082>>
Мы уже победили, просто это еще не так заметно...
Re[11]: Про NoSQL
От: Cyberax Марс  
Дата: 03.12.10 12:50
Оценка:
Здравствуйте, IB, Вы писали:

C>>Ага. Только в заметном числе случаев у нас получается унылое Г.

IB>Ага, в _не_ заметном числе случаев, и если руки под унылое Г. заточены. =)
Ну да. Если понасиловать РБД, то часто можно научить её немного работать как NoSQL.

C>> К примеру, в достаточно стандартной задаче представления строки с переменным числом столбцов.

IB>У строки нет столбцов
Ок. "Способ представления кортежей с произвольным числом элементов" тебя устроит?
Sapienti sat!
Re[12]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 12:50
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, gandjustas, Вы писали:


G>>>>С NoSQL полностью аналогично. По факту лучше NoSQL вообще не использовать как основное хранилище.

N>>>Ты опять используешь недоказанные постулаты. А хотелось бы увидеть доказательства.
G>>Чуть менее чем все NoSQL базы (я имею ввиду именно хранилища) не имеют ACID транзакций. В итоге для надежного хранения данных в них надо поднимать неслабую инфраструктуру так сказать upfront, еще до того как реально будет сделано что-то нужное.
C>А тут как бы полный CAP. На практике ты в высоконагруженных системах можешь выбрать только одно из двух — Availability или Consistency. Partition Tolerance — он обязательный.
Мы уже это проходили. 90% проектов не столкнутся с высоконагруженными распределенными системами. А те которые столкнутся будут применять совершенно аналогичные подходы независимо от того какое хранилище.

Только для NoSQL хранилищ это обязательно надо делать, а для SQL — по мере необходимости.
Re[13]: Про NoSQL
От: Cyberax Марс  
Дата: 03.12.10 12:56
Оценка:
Здравствуйте, gandjustas, Вы писали:

C>>А тут как бы полный CAP. На практике ты в высоконагруженных системах можешь выбрать только одно из двух — Availability или Consistency. Partition Tolerance — он обязательный.

G>Мы уже это проходили. 90% проектов не столкнутся с высоконагруженными распределенными системами. А те которые столкнутся будут применять совершенно аналогичные подходы независимо от того какое хранилище.
А те которые не столкнутся — нам и неинтересны.

G>Только для NoSQL хранилищ это обязательно надо делать, а для SQL — по мере необходимости.

Ну так никто и не просит применять NoSQL сразу везде.
Sapienti sat!
Re[14]: Про NoSQL
От: gandjustas Россия http://blog.gandjustas.ru/
Дата: 03.12.10 13:03
Оценка:
Здравствуйте, Cyberax, Вы писали:

C>Здравствуйте, gandjustas, Вы писали:


C>>>А тут как бы полный CAP. На практике ты в высоконагруженных системах можешь выбрать только одно из двух — Availability или Consistency. Partition Tolerance — он обязательный.

G>>Мы уже это проходили. 90% проектов не столкнутся с высоконагруженными распределенными системами. А те которые столкнутся будут применять совершенно аналогичные подходы независимо от того какое хранилище.
C>А те которые не столкнутся — нам и неинтересны.
Нам как раз интересны насущные проблемы, а не теоретические. странно что тебе ровно наоборот.

G>>Только для NoSQL хранилищ это обязательно надо делать, а для SQL — по мере необходимости.

C>Ну так никто и не просит применять NoSQL сразу везде.
Ну да, потом распределенный кеш сделать для оптимизации.
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.