Зачем NoSQL программистам

[rainman_rocks]

В последнее время, как видим, пошла мода на NoSQL.
Термин, собака, размыт до черезвычайности, под ним все подразумевают разное, кто во что горазд - кто-то интересуется переработанными RDBMS типа BigTable, кто-то болеет за key-value storage, парни с PostgreSQL вообще пошутили на тему QUEL.

Сконцентрируемся всё-таки на основном значении: системы

Comments

[asinitsyn]

Написал свое мнение по этому поводу

http://asinitsyn.livejournal.com/33307.html

Вкратце - последствия описаны верно, но у меня свой взгляд на причины.

[octo47]

отлично. прямо в точку.

Отличный пост.

[gabaidulin]

Но ведь были такие попытки(объектные стораджа, например, cache db)? Да и Завалишин чего-то подобное делает в своем Фантоме.

Но не пошло. Как вы думаете, почему?

Re: Отличный пост.

[rainman_rocks]

Чтобы технология пошла в массы, нужно одно из двух условий: аццкий маркетинг или гики-фанаты. У InterSystems Caché первое в ограниченном объёме есть, а второго нет из-за платности. У ZODB первого было ещё меньше, а второго нет из-за общей громоздкости и унылости.

Короче, громких/открытых проектов хорошего уровня доработанности не было. Сейчас вот вокруг HBase есть какая-то движуха. Это интересно, за этим можно последить.

А про Duke Zavalishin Forever лучше тактично промолчать. Фантом он и есть фантом, игра воображения.

Re: Отличный пост.

[avnik]

У вас какое-то устаревшее видение зопы (в частности без учета модных веяний типа repoze)

Re: Отличный пост.

[rainman_rocks]

Не спорю.

В зопе очень много всего накручено (я её застал в тот момент, когда она переходила с одного движка шаблонов на другой). Кроме того, там слишком много XML. Кроме того, там не было прямого доступа к коду в файловой системе, а веб-интерфейс - не лучший текстовый редактор.

Меня это всё как-то оттолкнуло, знаете ли. Особенно по контрасту с Django.

[vitus_wagner]

Это из серии "я хочу чтобы у меня все было, и мне за это ничего не было". А так не бывает. SQL хорош тем, что под ним лежит хорошая математика - реляционная алгебра. Эта математика накладывает на возможности представления довольно большие ограничения. Но эти ограничения являются платой за возможность эффективно оптимизировать запросы.

К сожалению, большинство разработчиков, хватающихся сейчас за NoSQL никогда в жизни не слышали слова CODASYL. Поэтому не знают, что история баз данных начиналась с объектно-ориентированных БД, где не было никаких ограничений. Но и искать было крайне затруднительно.

[zhengxi]

> Но эти ограничения являются платой за возможность эффективно оптимизировать запросы.

Вот взять тот же пример с постами и коментами.
Там ровно наоборот получается - для реаляционного решения нужен индекс по всем коментам, поиск по которому не будет лучше логарифмического (а комментов много, так много, что они и на один сервер могут не поместиться).
При этом post_id используется только для связи поста и коммента.
Есть RDBMS которые это "поймут" и эффективно соптимизируют до O(1), до (неявного, скрытого от автора SQL-запросов) хранения указателей на комменты рядом с постом ?

> К сожалению, большинство разработчиков, хватающихся сейчас за NoSQL никогда в жизни не слышали слова

Еще есть слово IMS, IMS is reportedly IBM's highest revenue software product, and it continues to grow.
Вполне такой NoSQL.

[legolegs]

>Там ровно наоборот получается - для реаляционного решения нужен индекс по всем коментам, поиск по которому не будет лучше логарифмического (а комментов много, так много, что они и на один сервер могут не поместиться).

Однажды встаёт необходимость в чём-то вроде списка комментов одного юзера - иноэскуэльщикам остаётся сказать "%ляяяяяяяя.....".

[rainman_rocks]

Вы слыхали фразу Д. Кнута о предварительной оптимизации?

А фразу О. Бендера касательно битья и плача?

Для реляционных БД такая внезапная "необходимость" обернётся точно таким же create index, который точно так же займёт N часов-дней-недель.

Поймите, в РСУБД никакой сверхъестественной магии нет. Там все те же структуры данных и алгоритмы. Вы их точно так же можете воспроизвести и при помощи NoSQL.

[metaclass]

Я не понимаю, почему в SQL до сих пор нет типа поля результата "список"?
Т.е. делая запрос к таблице, мы одно из полей делаем подзапросом, выбирающим список из связанной таблицы и так его и возвращаем. Конечно, придется массово переделывать API, придумывать, как это все дело отобразить(и вставлять тоже) но "выбрать объект и его подчиненные объекты одним запросом" было бы весьма удобно.

[plumqqz]

Ну как нет. Есть. Оракловые курсоры. В постгресе мне пришлось эмулировать.

[metaclass]

Что-то они больше нигде мне не попадались.

[plumqqz]

Ну, в ответ могу только развести руками.