CouchDB

Ok, афера с упоминанием CouchDB в прошлом посте удалась :-).

Если серьезно, то есть один комментарий, на который я хочу ответить отдельным постом, чтобы не смешивать с впечателниями о HighLoad.

Одна из ключевых фишек, если я правильно понял - RESTful JSON API и она в целом документо-ориентированная бд (точнее ее нельзя сейчас назвать полноценной СУБД, т.е. да, хранилище данных), т.е. она не для всех типов данных.

Не будь эпитета "полноценная", я бы почти согласился :-). Я считаю, что точка зрения, что реляционные СУБД полноценны, а остальное — поделки, не для серьезных дел и не для всех типов данных — это чистой воды консерватизм и больше ничего. Автор CouchDB в своей презентации доходчиво показывает, что все нужные характеристики хранения и доступа к данным (атомарность, непротиворечивость, изоляция и долговечность) не предписывают использования реляционной модели. Она конечно проверена временем, но тем же самым временем проверены и ее недостатки, в частности — упорное нежелание удобно масштабироваться.

Как видно из презентации дальше, CouchDB — это полноценное ACID-совместимое хранилище данных. Называть ли это термином "база данных" — вопрос второстепенный. Также и ее документо-ориентированность означает не то, что там можно хранить только HTML и PDF, а то, что для доступа вместо реляционного аппарата используется другой. А хранить-то там можно что угодно.

Потом такое ощущение что если JSON поменять на XML то получится XML-нативная бд, которые уже “тысячу” лет как существуют.

Что интересно, на данный момент CouchDB работает именно с XMLной выдачей, JSON к ней только планируют прикрутить :-).

Вообще, про нативные XML-базы я не знаю, к своему стыду, ничего, поэтому ничего не скажу о том, насколько на них похожа CouchDB. Но вот от реляционной модели она отличается сутью, а не форматом файлов. В реляционной модели данные размазываются в плоские нормализованные кучки, и составление нужных пользователю результатов ("документов") происходит во время выборки. CouchDB предназначена для хранения документов, про структуру которых сама база ничего знать не хочет. Как их составлять, насколько плоскими или глубоким, нормализованными или избыточными они должны быть — это дело приложения. CouchDB обеспечивает только транзакции, хранение и масштабирование, а целостность логичнее обеспечивать на уровне приложения. И это хорошо, потому что там в любом случае больше выразительных средств, чем в декларативном SQL. Впрочем, я повторяюсь. Только тогда я еще не верил, что это может быть быстро, а теперь верю, потому что реализация идеи не обязана быть такой наивной, какую я тогда описывал.

Вот критика CoachDB http://www.25hoursaday.com/weblog/2007/09/12/SomeThoughtsOnCouchDBAndRelationalDatabases.aspx

Мне, признаться, очень тяжело читать Dare Obasanjo, я все время теряю фокус, потому что он обычно начинает использовать очень обобщенные понятия. Поэтому я проленюсь и просто сошлюсь на ответ ему того же Сэма Руби. Из него я понял, что Dare предсказывает много теоретических проблем, но только для того понятия документо-ориентированных хранилищ, которое он сам использует.

Еще думаю то, что она разрабатывается на Erlang что не есть хорошо, его мало кто знает.

Ну это-то поправимо. Язык становится все известней и популярней. По-русски из известных мне людей про него периодически пишут lrrr и Александр Соловьев. Хотя для меня он действительно тоже пока "темная лошадка".

Вообщем, имхо, ничего особенного (на данный момент), в том плане что ничего страшного если кто-то ни в курсе :)))

Да, CouchDB в текущем виде пока слаба и похожа больше на концепцию. Но что же вы хотите от версии, которая едва стала вообще собираться хоть где-то кроме машины разработчика? Это вопрос развития.

Но вот концепция, на мой взгляд, просто чумовая. Мне кажется, что через пару лет такие вещи (не обязательно именно эта реализация) начнут уделывать реляционные СУБД по полной, и тогда на коне будет тот, кто успеет раньше. Так что быть в курсе надо.

Комментарии: 27

Egor Margineanu

Ну собиралась она еще в прошлом году если мне память не изменяет :) Но будущее есть у нее. И тем более учитывая что автор (Damien Katz http://damienkatz.net/) известный как товарищ переписавший Formula Engine (http://damienkatz.net/2005/01/formula-engine-rewrite.html) в одном не безизвестном продукте Lotus Domino, который тоже использует документо-ориентированный подход хранения данных. Соглашусь что еще сыроват, но так поигратся перед сном прекрасно подходит :)

Dyadya Zed

Я тут пошуршал в гугле и нашел Python library for working with CouchDB http://code.google.com/p/couchdb-python/ . Поколупаю на досуге...

Давид Мзареулян

Концепция (плоское пространство ключей), кстати, и так уже шагает по планете. Memcached, Amazon S3…

Давид Мзареулян

Между прочим, у меня к Вам рацпредложение. Почему бы не прикрутить к этому блогу wfw:commentRss? Тогда бы я мог комменты в RSS-ридере читать:)

Сергей Ткачук

Честно говоря не очень понятен такой энтузиазм.

Внимательно не смотрел, но если правильно понимаю, то CouchDB может применяться в очень узкой нише - доступ к изолированным, не связанным между собой, сущностям. Никаких связей, и, тем более, целостности этих связей оно не обеспечивает.

Плюс большой вопрос с эффективностью выборок нескольких записей. Сомнительно мне, чтобы перебор кучи данных и фильтрация их на JavaScript'е будет работать быстро. Разве что сделают API для быстрых запросов и, думается мне, это будет жалким подобием того же SQL :-)

Для какой-нибудь Wiki-образной системы оно подойдет, а вот даже тупейший интернет-магазин на такое хранилище уже не ложится.

DEkart

Сергей Ткачук, каждой задаче своя технология. В технологическом мире ведь не бывает "серебрянных пуль".

Базы подобные CouchDB имеет смысл использовать там, где структура отдельного документа не известна заранее, либо очень плохо ложится в реляционную модель.

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

О производительности системы речь пока не идет, только о концепции. А концепция, на мой взгляд, просто блеск. Ее бы довести до ума... :)

Alexander Solovyov

Хотя для меня он действительно тоже пока “темная лошадка”.

Для меня ещё тоже совсем не такая светлая, как питон. :) 4 задачи на projecteuler.net я решил, но в целом решение на питоне из меня выбегало заметно быстрее.

Хотя надо сказать, что очень интересно. В питоне некоторые штуки были бы очень и очень в тему. :)

Dyadya Zed

объясните почему "не ложится" интернет магазин? По-моему, вы просто невнимательно смотрели примеры.

Иван Сагалаев

CouchDB может применяться в очень узкой нише - доступ к изолированным, не связанным между собой, сущностям. Никаких связей, и, тем более, целостности этих связей оно не обеспечивает.

В мире бывают и другие связи помимо реляционных :-). CouchDB делается в REST стиле, и связями там выступают URL'ы. Предвосхищая возражение, что по URL'ам невозможно быстро выбирать зависимости, скажу, что это только с помощью реляционной алгебры невозможно. Вообще же подходов полно.

Сомнительно мне, чтобы перебор кучи данных и фильтрация их на JavaScript’е будет работать быстро.

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

Вообще, у меня появляется четкое déjà vu с комментариев к прошлым своим статьям, на которые я ссылался :-). Речь идет о полностью отличной от реляционной модели хранения данных, а возражения сводятся к тому, что "но оно же не сможет делать реляционные выборки!" :-)

Муркт

Сомнительно мне, чтобы перебор кучи данных и фильтрация их на JavaScript’е будет работать быстро.

При чём здесь Javascript? Javascript Object Notation используется просто для обмена данными. Если бы обмен осуществлялся s-exp'ами, вы бы написали что фильтрация выполняется на Lisp'е? А если в XML данные гонять?

Иван Сагалаев

Javascript там есть. На нем описываются выборки: http://www.couchdbwiki.com/index.php?title=Views

Муркт

А. Тогда извините :) (Javascript - остой).

Давид Мзареулян

Предвосхищая возражение, что по URL’ам невозможно быстро выбирать зависимости, скажу, что это только с помощью реляционной алгебры невозможно. Вообще же подходов полно.

А как?

Konstantin

Дежавю =). Очень напоминает дебаты: RDBMS vs файловая система. Наверное потому что CouchDB - по сути ACID-ная файловая система.

Иван Сагалаев

Ну то, что он файловая система — вообще не важно. Важно, что они, отказавшись от реляционных ссылок могут размазывать данные как угодно по скольки угодно серверам, устраняя тем самым принципиальную проблему реляционных СУБД, когда мастер-база является узким местом при записи. То есть даже если CouchDB будет медленней чем любая реляционная база на одной и той же машине, для очень (очень!) большого класса задач она будет выгодна просто потому, что можно добавлять серверы без оглядки и получать линейный рост производительности.

Иван Сагалаев

Предвосхищая возражение, что по URL’ам невозможно быстро выбирать зависимости, скажу, что это только с помощью реляционной алгебры невозможно. Вообще же подходов полно.

А как?

Системно не отвечу :-). Могу только поспекулировать.

Мне нравится,, что решение о том, как связывать данные, выносится на уровень приложения. Можно использовать избыточность, сохраняя, например, статистическую информацию в постоянно обновляемом документе, а не считать ее по group by. Или вот вещи, которые в RDBMS кажутся нонсенсом: вместо того, чтобы составить один большой join а потом отфильтровать нужное, можно просто выбрать небольшое количество ключевых данных, а по ним отдельно попросить зависимости.

Koudesnik

Сегодня побольше почитал про CouchDB. Какое-то непонятное впечатление получилось - вообщем, решил, что напишу пост и заодно отвечу на ваш :) Ссылку оставлю здесь в комментариях.

Мне кажется, что через пару лет такие вещи (не обязательно именно эта реализация) начнут уделывать реляционные СУБД по полной
"Такие вещи" реляционные бд не уделают, они не для этого или как в ихнем вики сказано "Not a replacement for relational databases."

То есть даже если CouchDB будет медленней чем любая реляционная база на одной и той же машине, для очень (очень!) большого класса задач она будет выгодна просто потому, что можно добавлять серверы без оглядки и получать линейный рост производительности.
А можно здесь подробнее, на пальцах? :) Какие например задачи?

Иван Сагалаев

“Такие вещи” реляционные бд не уделают, они не для этого или как в ихнем вики сказано “Not a replacement for relational databases.”

Ну позвольте мне немножко эмоциональных преувеличений! :-)

А можно здесь подробнее, на пальцах? :) Какие например задачи?

Я в целом имею в виду веб. Типовому веб-сервису редко нужно делать сложные запросы из множества данных, вместо этого делается очень много простых запросов от кучи клиентов. Поэтому здесь вместо одной очень мозговитой машины, которая в состоянии построить в оперативной памяти дикое декартово произведение и произвести нетривиальную фильтрацию, требуется длинная ферма одинаковых машин, которые одинаково быстро отвечают на короткие запросы. Важно, чтобы в ней не было какого-то одного центрального управляющего звена, в которое упрется производительность.

Пример. Представьте что вы делаете, например, Twitter. Большую часть запросов там, мне думается, составляют "добавить сообщение от юзера X" и "получить все сообщения юзера X после момента T". Ничего сложного, и все данные, по сути не централизованы. Но традиционная реляционная теория диктует нам схему с одной длинной табличкой юзеров и длинной табличкой сообщений, которые будут вечно расти, и которые скоро очень дорого станет join'ить. Вот для такого сценария нужно хранилище, которое умеет аккуратно размазывать себя по всем компьютерам кластера. И фактически, кстати, все советы по масштабированию реляционных СУБД в таких случаях сводятся в итоге к разбиванию базы на части. При этом она перестает быть целостной базой, но это, как оказывается, и не проблема.

Сергей Ткачук

Базы подобные CouchDB имеет смысл использовать там, где структура отдельного документа не известна заранее, либо очень плохо ложится в реляционную модель.

... и нет/мало связей между документами.

Система данных интернет-магазина лучше ложится в реляционную модель в том случае, если параметры товара или категории товаров известны заранее.

Помимо товаров в магазине есть категории/клиенты/скидки/заказы и прочее такое. И все это взаимосвязано. Получить актуальную корзину заказа для клиента зачастую можно одним SQL-запросом. В случае с CouchDB это будет куча запросов. Кстати, там ведь еще и транзакций нет, так что про интернет-магазин лучше забыть сразу.

В том случае, если у нас, например, каждый товар может иметь свой собственный набор параметров, упихивать это в реляционную модель будет некрасиво.

Сериализовать объект в XML/JSON и положить в BLOB-поле будет не сильно хуже, чем то, что дает CouchDB. Разве что view не будет, но они в этом случае не сильно-то и нужны.

О производительности системы речь пока не идет, только о концепции. А концепция, на мой взгляд, просто блеск. Ее бы довести до ума… :)

А в чем блеск? В модных словах REST и JSON?

В мире бывают и другие связи помимо реляционных :-)

Угу, к примеру я в молодости баловался dbVista. Только думается мне, что CouchDB не предоставляет вообще никаких.

CouchDB делается в REST стиле, и связями там выступают URL’ы.

Если я удалю документ по определенному URL, то что будет с такими "связями" на него в других документах?

Предвосхищая возражение, что по URL’ам невозможно быстро выбирать зависимости, скажу, что это только с помощью реляционной алгебры невозможно. Вообще же подходов полно.

Например? "Можно использовать избыточность" и "выбрать небольшое количество ключевых данных, а по ним отдельно попросить зависимости" - это ответ на какой-то другой вопрос :-)

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

У них так оно и есть, строятся индексы для вьюшек. Но речь не о тех view, которые играют роль SQL-евых вьюшек, а о тех динамических view (_temp_view), которые играют роль SQL-запросов. Они именно что динамические и предварительно их вычислить нельзя.

Вообще, у меня появляется четкое déjà vu с комментариев к прошлым своим статьям, на которые я ссылался :-). Речь идет о полностью отличной от реляционной модели хранения данных, а возражения сводятся к тому, что “но оно же не сможет делать реляционные выборки!” :-)

Возражений-то как раз нет (чему тут возражать?). Просто я хочу понять, откуда такая радость. Мне представляется что в модель "плоский список наборов полей" мало чего полезного можно хорошо положить и хорошо достать. Самодостаточные документы встречаются не так уж и часто.

Дежавю =). Очень напоминает дебаты: RDBMS vs файловая система. Наверное потому что CouchDB - по сути ACID-ная файловая система.

Хе-хе. Думается мне, что CouchDB не ACID-ная (нет транзакций при изменении нескольких документов) убогая (нет иерархии/симлинков) файловая система.

Пример. Представьте что вы делаете, например, Twitter. Большую часть запросов там, мне думается, составляют “добавить сообщение от юзера X” и “получить все сообщения юзера X после момента T”. Ничего сложного, и все данные, по сути не централизованы. Но традиционная реляционная теория диктует нам схему с одной длинной табличкой юзеров и длинной табличкой сообщений, которые будут вечно расти, и которые скоро очень дорого станет join’ить.

Join'ить будет недорого, выборка резко сократится из-за "после момента Т". К тому же наверняка sql view не зовут join на каждый чих.

А вот будет ли CouchDB быстро отрабатывать запросы "все сообщения юзера X после момента Т" - бооольшой вопрос. Смущают слова "юзера X". А потом ведь захочется "все сообщения друзей юзера X", "все сообщения с тегом 'django'" и т.п.

Давид Мзареулян

Мне нравится,, что решение о том, как связывать данные, выносится на уровень приложения. Можно использовать избыточность, сохраняя, например, статистическую информацию в постоянно обновляемом документе, а не считать ее по group by. Или вот вещи, которые в RDBMS кажутся нонсенсом: вместо того, чтобы составить один большой join а потом отфильтровать нужное, можно просто выбрать небольшое количество ключевых данных, а по ним отдельно попросить зависимости.

Честно говоря, ниччего не понял:) А можно какой-нибудь пример более-менее практический? Бог с ним, с общим решением.

Алексей К.

Статья вызвала бурю эмоций. :)
Зачем выносить целостность на уровень приложения?? Таким образом, возможность пользования вашей базой данных ограничивается приложением, обеспечивающим ограничения, в то время, как любое другое (со своими ограничениями) может натворить чёрт знает что.

Документно-ориентированная концепция, на мой взгляд, отлично укладывается в объектно-реляционные СУБД. :) Документ нужно лишь обернуть в атрибуты (могут быть при необходимости получены из самого документа), которые упростят поиск, классификацию, права доступа, ограничения и т.п. Честно говоря, я просто не представляю себе сложность СУБД, пытающихся реализовать чистую документно-ориентированную концепцию.

В базу нужно нести логику. В базу. А не из неё. :) В этом плане радуют гиганты, вроде Оракла...

В остальном, абсолютно согласен с критикой Сергея Ткачука.

Иван Сагалаев

Зачем выносить целостность на уровень приложения?? Таким образом, возможность пользования вашей базой данных ограничивается приложением, обеспечивающим ограничения, в то время, как любое другое (со своими ограничениями) может натворить чёрт знает что.

Я веду речь в основном про веб, где у базы всегда один клиент. Это очень большая по нынешним временам область, и она как раз выставляет свои требования к оптимизации. Другие клиент-серверные архитектуры меня не особенно интересуют, и туда я и лезть не собираюсь :-).

В базу нужно нести логику. В базу. А не из неё. :) В этом плане радуют гиганты, вроде Оракла…

Вот у веб-приложений четко обратная тенденция. По факту гиганты вроде Оракла предоставляют очень умные средства оптимизаций, которые на вебе не востребованы вообще. С другой стороны они не умеют выражать целостность данных в той мере, в которой она выражается в веб-приложении на императивных языках.

Именно поэтому на вебе тенденция такая: БД не должна задумываться о семантике хранящихся там данных, а быть тупым быстрым и надежным хранилищем с поддержкой транзакций, множественного доступа, бекапов... Всего того, что можно сделать, воспринимая данные как BLOB.

Роман Коблов

А в чем собственно проблема? У документа есть поля, по которым можно сортировать, соответсвенно просто добавяем в поле ид документа на который нужна ссылка и сортируем по нему. По поводу blob'a — разве по данным в блобе можно быстро и удобно сортировать? Получается очень удобная и масштабируемая бд, которая не подходит в очень редких задачах. Нужно вытащить все обьекты ссылающиеся на данный? делаем выборку с полем link=ид_данного документа. Нужны поля документа на который ссылается текущий? делаем запрос просто по имени документа. В ОО языках документ прекрасно отображается в обьект, у которого можно задать любой параметр. Причем, на примере интернет магазина: у товаров разных категорий могут быть разные параметры, причем у товаров в под категориях тоже могут быть разные параметры. В реляционной бд придется создавать дополнительные таблицы, или теряя в производительности создавать таблицы для дополнительных параметров, тут же достаточно просто создать различные документы с различными типами. Так же можно организовать наследование документов — создавать новый документ и делать ссылку на наследуемый документ, и делать запрос документа. Да, нельзя получить в запросе связанные документы, или конечный документ, после наследования (разве что с помощью вьюшек), но теряя некоторую производительность на нескольких запросах мы получим очень расширяемую структуру.

Akel

Поэтому здесь вместо одной очень мозговитой машины, которая в состоянии построить в оперативной памяти дикое декартово произведение и произвести нетривиальную фильтрацию, требуется длинная ферма одинаковых машин, которые одинаково быстро отвечают на короткие запросы.

Этот самый расчет, можно делать один раз и потом обращаться к ней. Просто предварительно расчитать, что выгодней по ресурсам - каждый раз считать или хранить дополнительные данные.

german

Уже Есть jQuery плагин для доступа к CouchDB:

http://jquery.com/plugins/project/jqcouch

jQuery plugin for CouchDB, handling different type of couchdb connections.

jqcouch requires the new JSON-based CouchDB, which currently has to be installed from svn.
More details on this in the CouchDB projects website.

$.jqcouch.db.exists('/some_database');
$.jqcouch.db.create('/some_database');
$.jqcouch.doc.save('/some_database/note1', {
    name: 'Test',
    title: 'Test title'
});
$.jqcouch.doc.get('/some_database/note1');

Дмитрий Овсянко

Базы подобные CouchDB имеет смысл использовать там, где структура отдельного документа не известна заранее, либо очень плохо ложится в реляционную модель.

Если структура документа хоть как-то влияет на результаты работы программы, использовать её всё-таки придётся. А значит, и описать — пусть не "предварительно", но в какой-то момент.

Скажем, для фильтра по дате регистрации документа необходимо вообще знать, что у документа есть такой реквизит: дата регистрации. Надо вводить и редактировать его в специально нарисованном поле и в БД хранить под известным именем.

Можно, конечно, на каждый запрос:

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

И если что-то притормаживает, ставить кластер потолще. Ну-ну.

Или, скажем, ситуация с хотя бы 2 независимыми таблицами фактов. Вакансии с одной стороны и CV с другой. Всё хранить в одной помойке? Заодно со справочниками кандададтов, работодателей, всевозможных статусов и прочего? Да ради-бога.

Александр Соловьёв

выполнять сравнение и, наконец, то ли выдавать запись, то ли нет.

Прежде чем высказывать скептицизм, неплохо бы познакомиться с предметом обсуждения.

Добавить комментарий

Egor Margineanu

Ну собиралась она еще в прошлом году если мне память не изменяет :) Но будущее есть у нее. И тем более учитывая что автор (Damien Katz http://damienkatz.net/) известный как товарищ переписавший Formula Engine (http://damienkatz.net/2005/01/formula-engine-rewrite.html) в одном не безизвестном продукте Lotus Domino, который тоже использует документо-ориентированный подход хранения данных. Соглашусь что еще сыроват, но так поигратся перед сном прекрасно подходит :)
Dyadya Zed

Я тут пошуршал в гугле и нашел Python library for working with CouchDB http://code.google.com/p/couchdb-python/ . Поколупаю на досуге...
Давид Мзареулян

Концепция (плоское пространство ключей), кстати, и так уже шагает по планете. Memcached, Amazon S3…
Давид Мзареулян

Между прочим, у меня к Вам рацпредложение. Почему бы не прикрутить к этому блогу wfw:commentRss? Тогда бы я мог комменты в RSS-ридере читать:)
Сергей Ткачук

Честно говоря не очень понятен такой энтузиазм.

Внимательно не смотрел, но если правильно понимаю, то CouchDB может применяться в очень узкой нише - доступ к изолированным, не связанным между собой, сущностям. Никаких связей, и, тем более, целостности этих связей оно не обеспечивает.

Плюс большой вопрос с эффективностью выборок нескольких записей. Сомнительно мне, чтобы перебор кучи данных и фильтрация их на JavaScript'е будет работать быстро. Разве что сделают API для быстрых запросов и, думается мне, это будет жалким подобием того же SQL :-)

Для какой-нибудь Wiki-образной системы оно подойдет, а вот даже тупейший интернет-магазин на такое хранилище уже не ложится.
DEkart

Сергей Ткачук, каждой задаче своя технология. В технологическом мире ведь не бывает "серебрянных пуль".

Базы подобные CouchDB имеет смысл использовать там, где структура отдельного документа не известна заранее, либо очень плохо ложится в реляционную модель.

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

О производительности системы речь пока не идет, только о концепции. А концепция, на мой взгляд, просто блеск. Ее бы довести до ума... :)
Alexander Solovyov

Хотя для меня он действительно тоже пока “темная лошадка”.

Для меня ещё тоже совсем не такая светлая, как питон. :) 4 задачи на projecteuler.net я решил, но в целом решение на питоне из меня выбегало заметно быстрее.

Хотя надо сказать, что очень интересно. В питоне некоторые штуки были бы очень и очень в тему. :)
Dyadya Zed

объясните почему "не ложится" интернет магазин? По-моему, вы просто невнимательно смотрели примеры.
Иван Сагалаев

CouchDB может применяться в очень узкой нише - доступ к изолированным, не связанным между собой, сущностям. Никаких связей, и, тем более, целостности этих связей оно не обеспечивает.

В мире бывают и другие связи помимо реляционных :-). CouchDB делается в REST стиле, и связями там выступают URL'ы. Предвосхищая возражение, что по URL'ам невозможно быстро выбирать зависимости, скажу, что это только с помощью реляционной алгебры невозможно. Вообще же подходов полно.

Сомнительно мне, чтобы перебор кучи данных и фильтрация их на JavaScript’е будет работать быстро.

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

Вообще, у меня появляется четкое déjà vu с комментариев к прошлым своим статьям, на которые я ссылался :-). Речь идет о полностью отличной от реляционной модели хранения данных, а возражения сводятся к тому, что "но оно же не сможет делать реляционные выборки!" :-)
Муркт

Сомнительно мне, чтобы перебор кучи данных и фильтрация их на JavaScript’е будет работать быстро.

При чём здесь Javascript? Javascript Object Notation используется просто для обмена данными. Если бы обмен осуществлялся s-exp'ами, вы бы написали что фильтрация выполняется на Lisp'е? А если в XML данные гонять?
Иван Сагалаев

Javascript там есть. На нем описываются выборки: http://www.couchdbwiki.com/index.php?title=Views
Муркт

А. Тогда извините :) (Javascript - остой).
Давид Мзареулян

Предвосхищая возражение, что по URL’ам невозможно быстро выбирать зависимости, скажу, что это только с помощью реляционной алгебры невозможно. Вообще же подходов полно.

А как?
Konstantin

Дежавю =). Очень напоминает дебаты: RDBMS vs файловая система. Наверное потому что CouchDB - по сути ACID-ная файловая система.
Иван Сагалаев

Ну то, что он файловая система — вообще не важно. Важно, что они, отказавшись от реляционных ссылок могут размазывать данные как угодно по скольки угодно серверам, устраняя тем самым принципиальную проблему реляционных СУБД, когда мастер-база является узким местом при записи. То есть даже если CouchDB будет медленней чем любая реляционная база на одной и той же машине, для очень (очень!) большого класса задач она будет выгодна просто потому, что можно добавлять серверы без оглядки и получать линейный рост производительности.
Иван Сагалаев

Предвосхищая возражение, что по URL’ам невозможно быстро выбирать зависимости, скажу, что это только с помощью реляционной алгебры невозможно. Вообще же подходов полно.

А как?

Системно не отвечу :-). Могу только поспекулировать.

Мне нравится,, что решение о том, как связывать данные, выносится на уровень приложения. Можно использовать избыточность, сохраняя, например, статистическую информацию в постоянно обновляемом документе, а не считать ее по group by. Или вот вещи, которые в RDBMS кажутся нонсенсом: вместо того, чтобы составить один большой join а потом отфильтровать нужное, можно просто выбрать небольшое количество ключевых данных, а по ним отдельно попросить зависимости.
Koudesnik

Сегодня побольше почитал про CouchDB. Какое-то непонятное впечатление получилось - вообщем, решил, что напишу пост и заодно отвечу на ваш :) Ссылку оставлю здесь в комментариях.

Мне кажется, что через пару лет такие вещи (не обязательно именно эта реализация) начнут уделывать реляционные СУБД по полной
"Такие вещи" реляционные бд не уделают, они не для этого или как в ихнем вики сказано "Not a replacement for relational databases."

То есть даже если CouchDB будет медленней чем любая реляционная база на одной и той же машине, для очень (очень!) большого класса задач она будет выгодна просто потому, что можно добавлять серверы без оглядки и получать линейный рост производительности.
А можно здесь подробнее, на пальцах? :) Какие например задачи?
Иван Сагалаев

“Такие вещи” реляционные бд не уделают, они не для этого или как в ихнем вики сказано “Not a replacement for relational databases.”

Ну позвольте мне немножко эмоциональных преувеличений! :-)

А можно здесь подробнее, на пальцах? :) Какие например задачи?

Я в целом имею в виду веб. Типовому веб-сервису редко нужно делать сложные запросы из множества данных, вместо этого делается очень много простых запросов от кучи клиентов. Поэтому здесь вместо одной очень мозговитой машины, которая в состоянии построить в оперативной памяти дикое декартово произведение и произвести нетривиальную фильтрацию, требуется длинная ферма одинаковых машин, которые одинаково быстро отвечают на короткие запросы. Важно, чтобы в ней не было какого-то одного центрального управляющего звена, в которое упрется производительность.

Пример. Представьте что вы делаете, например, Twitter. Большую часть запросов там, мне думается, составляют "добавить сообщение от юзера X" и "получить все сообщения юзера X после момента T". Ничего сложного, и все данные, по сути не централизованы. Но традиционная реляционная теория диктует нам схему с одной длинной табличкой юзеров и длинной табличкой сообщений, которые будут вечно расти, и которые скоро очень дорого станет join'ить. Вот для такого сценария нужно хранилище, которое умеет аккуратно размазывать себя по всем компьютерам кластера. И фактически, кстати, все советы по масштабированию реляционных СУБД в таких случаях сводятся в итоге к разбиванию базы на части. При этом она перестает быть целостной базой, но это, как оказывается, и не проблема.
Сергей Ткачук

Базы подобные CouchDB имеет смысл использовать там, где структура отдельного документа не известна заранее, либо очень плохо ложится в реляционную модель.

... и нет/мало связей между документами.

Система данных интернет-магазина лучше ложится в реляционную модель в том случае, если параметры товара или категории товаров известны заранее.

Помимо товаров в магазине есть категории/клиенты/скидки/заказы и прочее такое. И все это взаимосвязано. Получить актуальную корзину заказа для клиента зачастую можно одним SQL-запросом. В случае с CouchDB это будет куча запросов. Кстати, там ведь еще и транзакций нет, так что про интернет-магазин лучше забыть сразу.

В том случае, если у нас, например, каждый товар может иметь свой собственный набор параметров, упихивать это в реляционную модель будет некрасиво.

Сериализовать объект в XML/JSON и положить в BLOB-поле будет не сильно хуже, чем то, что дает CouchDB. Разве что view не будет, но они в этом случае не сильно-то и нужны.

О производительности системы речь пока не идет, только о концепции. А концепция, на мой взгляд, просто блеск. Ее бы довести до ума… :)

А в чем блеск? В модных словах REST и JSON?

В мире бывают и другие связи помимо реляционных :-)

Угу, к примеру я в молодости баловался dbVista. Только думается мне, что CouchDB не предоставляет вообще никаких.

CouchDB делается в REST стиле, и связями там выступают URL’ы.

Если я удалю документ по определенному URL, то что будет с такими "связями" на него в других документах?

Предвосхищая возражение, что по URL’ам невозможно быстро выбирать зависимости, скажу, что это только с помощью реляционной алгебры невозможно. Вообще же подходов полно.

Например? "Можно использовать избыточность" и "выбрать небольшое количество ключевых данных, а по ним отдельно попросить зависимости" - это ответ на какой-то другой вопрос :-)

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

У них так оно и есть, строятся индексы для вьюшек. Но речь не о тех view, которые играют роль SQL-евых вьюшек, а о тех динамических view (_temp_view), которые играют роль SQL-запросов. Они именно что динамические и предварительно их вычислить нельзя.

Вообще, у меня появляется четкое déjà vu с комментариев к прошлым своим статьям, на которые я ссылался :-). Речь идет о полностью отличной от реляционной модели хранения данных, а возражения сводятся к тому, что “но оно же не сможет делать реляционные выборки!” :-)

Возражений-то как раз нет (чему тут возражать?). Просто я хочу понять, откуда такая радость. Мне представляется что в модель "плоский список наборов полей" мало чего полезного можно хорошо положить и хорошо достать. Самодостаточные документы встречаются не так уж и часто.

Дежавю =). Очень напоминает дебаты: RDBMS vs файловая система. Наверное потому что CouchDB - по сути ACID-ная файловая система.

Хе-хе. Думается мне, что CouchDB не ACID-ная (нет транзакций при изменении нескольких документов) убогая (нет иерархии/симлинков) файловая система.

Пример. Представьте что вы делаете, например, Twitter. Большую часть запросов там, мне думается, составляют “добавить сообщение от юзера X” и “получить все сообщения юзера X после момента T”. Ничего сложного, и все данные, по сути не централизованы. Но традиционная реляционная теория диктует нам схему с одной длинной табличкой юзеров и длинной табличкой сообщений, которые будут вечно расти, и которые скоро очень дорого станет join’ить.

Join'ить будет недорого, выборка резко сократится из-за "после момента Т". К тому же наверняка sql view не зовут join на каждый чих.

А вот будет ли CouchDB быстро отрабатывать запросы "все сообщения юзера X после момента Т" - бооольшой вопрос. Смущают слова "юзера X". А потом ведь захочется "все сообщения друзей юзера X", "все сообщения с тегом 'django'" и т.п.
Давид Мзареулян

Мне нравится,, что решение о том, как связывать данные, выносится на уровень приложения. Можно использовать избыточность, сохраняя, например, статистическую информацию в постоянно обновляемом документе, а не считать ее по group by. Или вот вещи, которые в RDBMS кажутся нонсенсом: вместо того, чтобы составить один большой join а потом отфильтровать нужное, можно просто выбрать небольшое количество ключевых данных, а по ним отдельно попросить зависимости.

Честно говоря, ниччего не понял:) А можно какой-нибудь пример более-менее практический? Бог с ним, с общим решением.
Алексей К.

Статья вызвала бурю эмоций. :)
Зачем выносить целостность на уровень приложения?? Таким образом, возможность пользования вашей базой данных ограничивается приложением, обеспечивающим ограничения, в то время, как любое другое (со своими ограничениями) может натворить чёрт знает что.

Документно-ориентированная концепция, на мой взгляд, отлично укладывается в объектно-реляционные СУБД. :) Документ нужно лишь обернуть в атрибуты (могут быть при необходимости получены из самого документа), которые упростят поиск, классификацию, права доступа, ограничения и т.п. Честно говоря, я просто не представляю себе сложность СУБД, пытающихся реализовать чистую документно-ориентированную концепцию.

В базу нужно нести логику. В базу. А не из неё. :) В этом плане радуют гиганты, вроде Оракла...

В остальном, абсолютно согласен с критикой Сергея Ткачука.
Иван Сагалаев

Зачем выносить целостность на уровень приложения?? Таким образом, возможность пользования вашей базой данных ограничивается приложением, обеспечивающим ограничения, в то время, как любое другое (со своими ограничениями) может натворить чёрт знает что.

Я веду речь в основном про веб, где у базы всегда один клиент. Это очень большая по нынешним временам область, и она как раз выставляет свои требования к оптимизации. Другие клиент-серверные архитектуры меня не особенно интересуют, и туда я и лезть не собираюсь :-).

В базу нужно нести логику. В базу. А не из неё. :) В этом плане радуют гиганты, вроде Оракла…

Вот у веб-приложений четко обратная тенденция. По факту гиганты вроде Оракла предоставляют очень умные средства оптимизаций, которые на вебе не востребованы вообще. С другой стороны они не умеют выражать целостность данных в той мере, в которой она выражается в веб-приложении на императивных языках.

Именно поэтому на вебе тенденция такая: БД не должна задумываться о семантике хранящихся там данных, а быть тупым быстрым и надежным хранилищем с поддержкой транзакций, множественного доступа, бекапов... Всего того, что можно сделать, воспринимая данные как BLOB.
Роман Коблов

А в чем собственно проблема? У документа есть поля, по которым можно сортировать, соответсвенно просто добавяем в поле ид документа на который нужна ссылка и сортируем по нему. По поводу blob'a — разве по данным в блобе можно быстро и удобно сортировать? Получается очень удобная и масштабируемая бд, которая не подходит в очень редких задачах. Нужно вытащить все обьекты ссылающиеся на данный? делаем выборку с полем link=ид_данного документа. Нужны поля документа на который ссылается текущий? делаем запрос просто по имени документа. В ОО языках документ прекрасно отображается в обьект, у которого можно задать любой параметр. Причем, на примере интернет магазина: у товаров разных категорий могут быть разные параметры, причем у товаров в под категориях тоже могут быть разные параметры. В реляционной бд придется создавать дополнительные таблицы, или теряя в производительности создавать таблицы для дополнительных параметров, тут же достаточно просто создать различные документы с различными типами. Так же можно организовать наследование документов — создавать новый документ и делать ссылку на наследуемый документ, и делать запрос документа. Да, нельзя получить в запросе связанные документы, или конечный документ, после наследования (разве что с помощью вьюшек), но теряя некоторую производительность на нескольких запросах мы получим очень расширяемую структуру.
Akel

Поэтому здесь вместо одной очень мозговитой машины, которая в состоянии построить в оперативной памяти дикое декартово произведение и произвести нетривиальную фильтрацию, требуется длинная ферма одинаковых машин, которые одинаково быстро отвечают на короткие запросы.

Этот самый расчет, можно делать один раз и потом обращаться к ней. Просто предварительно расчитать, что выгодней по ресурсам - каждый раз считать или хранить дополнительные данные.
german
Уже Есть jQuery плагин для доступа к CouchDB:

http://jquery.com/plugins/project/jqcouch

jQuery plugin for CouchDB, handling different type of couchdb connections.

jqcouch requires the new JSON-based CouchDB, which currently has to be installed from svn.
More details on this in the CouchDB projects website.
```
$.jqcouch.db.exists('/some_database');
$.jqcouch.db.create('/some_database');
$.jqcouch.doc.save('/some_database/note1', {
    name: 'Test',
    title: 'Test title'
});
$.jqcouch.doc.get('/some_database/note1');
```
Дмитрий Овсянко
Базы подобные CouchDB имеет смысл использовать там, где структура отдельного документа не известна заранее, либо очень плохо ложится в реляционную модель.

Если структура документа хоть как-то влияет на результаты работы программы, использовать её всё-таки придётся. А значит, и описать — пусть не "предварительно", но в какой-то момент.

Скажем, для фильтра по дате регистрации документа необходимо вообще знать, что у документа есть такой реквизит: дата регистрации. Надо вводить и редактировать его в специально нарисованном поле и в БД хранить под известным именем.

Можно, конечно, на каждый запрос:
- перерывать всё множество документов,
- для каждого из них выискивать нужный атрибут по имени (возможно, имена вынесены в глобальный словарь, но местонахождение атрибута для каждой отдельной записи непредсказуемо),
- вероятно, преобразовывать его из презентационного формата в тот, в котором даты поддаются сравнению (количество секунд с 01.01.1970, ISO-формат...),
- выполнять сравнение и, наконец, то ли выдавать запись, то ли нет.
И если что-то притормаживает, ставить кластер потолще. Ну-ну.

Или, скажем, ситуация с хотя бы 2 независимыми таблицами фактов. Вакансии с одной стороны и CV с другой. Всё хранить в одной помойке? Заодно со справочниками кандададтов, работодателей, всевозможных статусов и прочего? Да ради-бога.
Александр Соловьёв

выполнять сравнение и, наконец, то ли выдавать запись, то ли нет.

Прежде чем высказывать скептицизм, неплохо бы познакомиться с предметом обсуждения.