Как стать автором
Обновить

Комментарии 61

Отличнейшая статья, резко контрастирует с большинством других заметок, публикуемых на хабре. Поставил бы большущий плюсище, если б мог.
Согласен, поэтому поставил плюс и посту, и карме, и Вашему каменту. Как раз вчера слышал про этот проект, буду ждать его развития.
держите в курсе, интересно как будет развиваться :)
спасибо за пост (плюс поставил)
ну, еще один success story для Erlang'а

кстати, интересно почитать "Why Does CouchDB Not Use Mnesia?" в их FAQ(mnesia — это встроенная в Erlang распределенная БД)
Ну success story пока можно назвать только амазоновский сервис :)

А mnesia (или даже тупо ets) отлично дополняет CouchDb — она ж довольно шустрая, там можно хранить разнообразные кэши и сессии юзеров.
встречаем отечественную разработку — StrokeDB

вот что там пишут о CouchDB, кстати:


CouchDB is very nice, but has several disadvantages for us. We plan to port a kernel of the StrokeDB to “thin client” languages (JavaScript, ActionScript etc.) to enable offline work with the data with the very same features server version has. CouchDB is written in Erlang and that’s the first problem.
Another thing is that CouchDB doesn’t scale data properly yet. It lacks distributed indexes and storages.
There’s also a huge argument for pure-Ruby version: StrokeDB integrates so well with Ruby apps, so it is a pleasure to configure different environments and optimize performance by injecting the database right into your application.
это от создателя "вкадре.ру"? :)
угумс
Он, кстати, есть на Хабре - жестко заминусованный :) посмотреть профиль oleganza
нормально, у меня такая же карма была :) но спасибо, было интересно увидеть его тут.
Хоть что-то интересное , а то либо "как меньше спать и больше работать" либо "я голодный студент дайте мне работу" .
Relational Databases are dead, long live relational databases.
Таких постов становится много (например как минимум два есть на инсайт-айти). Их общий недостаток - автор помимо теории, как правило, понятия не имеет о практической реализации проектов с использованием подобных БД.

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

А так получается еще одна перепечатка абаута с апача.
Развертывание занимает пять минут — svn co && ./bootstrap && ./configure && make && make install, никаких проблем.

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

Насчет практики — будет отдельный отчет, когда запустим defun.ru на эрланге и couchdb :) Работа идет.
Простите, но у вас же там Друпал. Или вы свой движок написали?
Да, друпал, но это временно. Пишем свой.

Новая версия будет совсем новая, в смысле — в ней не будет ни строчки от старой: ни друпала, ни пхп, ни mysql, ни даже апача :)
Ну что сказать. Поздравляю :)
Чем-то мне это напомнило ZODB - базу данных от Zope. Много красивых идей, каждый объект содержит все поля, джойны не нужны и т.п.
Но работает эта штука... примерно как называется, так и работает :)
Она работает хорошо, по скорости выборки (поднятие объекта по ИД) обгонит многие селекты. Однако конкурентная запись там порождала постоянные ZODB Conflict Errorы.
С тех пор я буду долго изучать объектную (или подобную) базу данных, прежде чем начну использовать, особенно при нагрузке.
Однако скорость разработки на Zope была более чем заманчивой (:
Насчет скорости очень спорно. Вот товарищ чуть ниже как раз опровергает это мнение. Скорость выборки примерно равна, а запись отстает на 2 порядка(!). Кроме того, после большого числа записей базу раздувает неимоверно, необходимо делать упаковку.
Какие именно выборки имеются ввиду? Как быстро будет выбираться не просто объект, а скажем группа последний новостей по данному тегу, к которому есть право доступа у пользователя?
Вобщем у меня примерно такие же впечатления. На первый взгляд все круто. А когда копнешь глубже, то вылезает масса проблем.
Почитай статью про сравнение производительности ZODB и MySQL http://zope3.ru/stati/testiruem-zodb-na-… Работает она прекрасно, вот только не всегда результаты от неправильно поставленных задач соответствуют ожиданиям
Прочитал. Ты только подтвердил мой тезис. Проигрыш по скорости записи на 2 порядка плюс проблемы с конкурентностью, а по скорости выборки примерно одинаково. На самой простой операции выборки zodb оказалась быстрее в 2 раза. При этом не забываем, что zodb хранит свой индекс в памяти. С одной стороны это дает ей выигрыш по скорости, а с другой привносит ограничения на размер, которых нет у того же мускуля. А если взять операцию поинтереснее? Типа 20 последних новостей по выбранному тегу с учетом прав доступа?
В простом случае можно использовать zcatalog, а в более сложных начинаются веселые фокусы - ...индекс выносится в реляционную БД :) Ха! Так зачем городить весь огород, если все равно пришли к тому же? Только сделали жуткогетерогенную систему, которая уже сама в себе таит проблемы.
Не реляционный язык программирования для баз данных mumps/m, рулил когда современные SQL были еще в зародыше, но в 90е одна компания с ужасным маркетингом и подходом ведения бизнеса, почти как у Майкрософт (только еще хуже) скупила все коммерческие реализации (с десяток компаний), и заморозила соответствующие продукты, фактически они монополизировали этот рынок.
Речь о компании Intersystems.
Тупо надстроив SQL транслятор над M технологией они назвали это Каше(Cach
Ха-ха, хабр подавился буковкой из названия программного продукта.
отличная статься... большое спасибо
НЛО прилетело и опубликовало эту надпись здесь
=)) а ты не мысли записями, ты мысли ДОКУМЕНТАМИ и ОБЪЕКТАМИ
и тогда все встанет на свои места

я думаю что это будет нормально работать на коллекции до 100 000 документов на один шард

основной прикол в ДРУГОМ подходе
нахер джойны и нормальные формы, даешь денормализацию и произвольную иерархию внутри объекта с безболезненным изменением схемы =)
боюсь все же в web приложениях объекты наоборот проще, чем ERP приложениях.
C ERP я там погорячился, да, не так все просто.
простите, я правильно понимаю, что для того чтобы найти все документы по какому то критерию, и потом
надо писать map функцию???
а для того чтобы потом из найденных документов вытащить какие то конкретные поля и на их основе составить какой нибудь "сгрупированный" и "отсортированный" результат, надо писать reduce ф-цию???
Половина первого предложения куда-то пропала у вас, но ответ скорее всего "да" на оба вопроса :)

Да, эти механизмы предполагаются довольно-таки легкими и шустрыми, и эту часть логики предлагается перенести на сторону БД. Результаты работы map/reduce тоже можно фильтровать — на выходе у них не просто документы или часть документов, а пары json-объектов {ключ, значение}, и через HTTP API можно запрашивать не все результаты, а только для диапазона ключей, или первые N, и т.п.

Вот хороший пример, как примерно это выглядит на практике.
Больше всего хотел бы увидеть пример реализации стандартного веб-приложения с использованием этой (или любой другой среди всех этих нереляционных) базы. Приложение самое простое, есть база (таблица) статей на сайте, БД пользователей они регистрируются на сайте, они могут оставлять комментарии к этим статьям, и все это выглядит ну к примеру как элементарных новостной сайт или блог.
Любой сайт на Lotus Notes/Domino.
Вообще, Notes, по-моему, старейшая из документоориентированных СУБД.
Да, кстати, Damien Katz был каким-то мощным консультантом по Notes, соавтором книжки какой-то по ним и все такое. Потом в IBM лет пять работал непосредственно над Lotus Notes, потом ушел, написал CouchDb, и теперь с января его IBM обратно наняла чтоб он над CouchDb уже фултайм работал.

Вот такая вот загогулина :)
Надо же, оказывается я читал его историю о том как он переписывал движок @-формул, для шестого Лотуса.
То-то я смотрю, похоже на Notes — документы, поля...
а дайте ссылку, инетересно :)
странно. для домино у IBM есть почти рабочий мост .nsf -> DB2, который позволяет фактически запихивать неструктурированные данные в реляционную базу.
Добавление еще одной сущности (CouchDb)? как-то нелогично. если CouchDB они поверх DB2 гонять - получится урезанный Domino, только без собак и LotusScript (а яву наверняка прикрутят, имхо)
Насколько я понимаю, у IBM пока нету планов куда-то прикручивать CouchDb. Это совершенно отдельный проект, появился он независимо от них, они его просто "под крыло" взяли — они же вообще много open source проектов спонсируют.
Все это конечно хорошо, интересно посмотреть на "select". Каким способом будет производиться поиск, и как скажется большие объемы данных на этот поиск?
В теории для данного подхода большие объемы будут не так пагубны как для реляционной базы. Когда нужно обрабатывать десятки и сотни терабайт данных то тут выигрыш будет налицо. Но как будет именно в данном случае (не забываем что альфа версия) это еще неизвестно.
Как раз таки в теории именно для такого подхода хранения данных поиск скажется не лучшим образом.
Можете точнее прокомментировать в чем и как"выигрыш будет налицо"?
Смотря какие select'ы имеются ввиду.

Тут результат выборки строится инкрементально — то есть промежуточные результаты сохраняются и повторно используются при последующих запросах. Я не разработчик RDBMS, конечно, но, мне кажется, вряд ли они могут делать так же — слишком много разных запросов может быть (а в couchdb их набор фактически заранее задан разработчиком). Функции map/reduce распраллеливаются на кластере на ура.

А основная засада с джоинами: с обычными RDBMS приходится либо их использовать — а они масштабируются со скрипом и работают небыстро, либо использовать суровую денормализацию, в результате мощная СУБД используется в режиме гигантской тупой хэш-таблицы, причем куча усилий разработчиков тратится на сборку/разборку результатов запросов в объекты предметной области, кэширование, partitioning и борьбу со схемами (при этом, в денормализованных таблицах они уже не могут поддерживать consistency).
select'ы имелись ввиду " where name='вася'" или "between дата1 and дата2". Не могу себе представить быстрого поиска без создания ключа. По сути джоины это и есть поиск + добавление.
Почему поиск скажется не лучшим образом? Ну как минимум объем дисковых операций уменьшается. Ну и возможность раскидывания по кластеру нужного размера почти без потери производительности разве не полезна при большом объеме данных? Имхо как раз это то самое в чем проблема реляционных баз для больших объемов. Опять же это для документов, они вряд ли короткие, а реляционные БД лучше заточены под таблицы с малым размером столбцов и короткой длине их содержимого.
Да и википедия говорит что для data warehouses лучше колоночная БД
Ну а для примера можете посмотреть на гугль, у него отнюдь не маленькая база, я бы сказал что она вполне себе подходит под критерии больших объемов данных. Так вот их BigTable вполне тянет все это.
Я не эксперт по БД, не сертифицировался, так что могу и ошибаться. В таком случае буду рад услышать преимущества реляционной структуры, перед всеми этими колоночными БД, для случая хранения большой базы текстовых документов.
> Ну как минимум объем дисковых операций уменьшается.
Это почему? С чего вы взяли? Как раз таки поиску без ключа придется просмотреть все записи, которые лежат на винтах!

> Ну и возможность раскидывания по кластеру нужного ...
Кластеризация это обычная вещь для "нормальной" СУБД. И это не проблема.

Мне интересно на низком уровне как будет осуществляться поиск в неструктурируемых данных по какому нибудь полю. Нет ключа, что означает что данные не отсортированы. Я не смогу принять решение не просмотрев всех записей (допустим min(дата)).
Нет-нет, смотрите: само хранилище — это тупо набор документов, неструктурированных. Точнее, индексированных только по имени.

Плюс к документам есть набор view, то бишь срезов, отображающих с помощью функций map/reduce множество документов в список {key, value}, отсортированный, естественно, по ключу. То есть view это индекс такой по сути (ключ тут, кстати, довольно сложный может быть, не просто циферка или строчка).

При этом и построение этих срезов, и выборка из них легко масштабируются и распределяются по кластеру.
Ну теперь более менее понятно, спасибо за разъяснения. А нет ли у вас тестов скорости?
По скорости вставки она довольно небыстрая, вот тут есть какие-то результаты, http://userprimary.net/user/2007/12/16/a…, и я сам похожие цифры наблюдал.

Насчет чтения не знаю, должно быть довольно шустро, но все сильно зависит от размера выборки, как давно не пересчитывался view и так далее. Тут чтоб нормально потестировать нужен стенд тестовый, вообще говоря.
Не очень впечатляет. Но все равно буду посматривать за развитием этого проекта.
Аналог Лотуса, я так понимаю... Изучал Лотус в IBM - они утверждают, что всё равно бэкенд частично реляционный, так как у документоориентированной БД очень большие проблемы с производительностью.
Спасибо за информацию, будем пробовать :) Вам плюс.
НЛО прилетело и опубликовало эту надпись здесь
Ну, это тоже про эрланг отчасти :)

Просто сейчас почти все свободное время уходит на то чтоб *на* эрланге писать. Новые впечатления пока коплю, в общем :)
как на счет реализованных web проектов на couchDB - они есть , если да то насколько крупные ?
Поскольку это пока альфа, API меняется, фичи актвно добавляются — крупных проектов, понятно, нету. Сейчас нужно быть таким тру early adopter'ом чтоб ее промышленно использовать, хотя в этом тоже есть свои плюсы — пока проект не разросся, его проще подпилить напильником в нужных местах самому.

Тут вот список проектов, он небольшой
http://wiki.apache.org/couchdb/InTheWild
Звучит жизнеутверждающе. Пошел копаться :)
Извиняюсь за некропостинг. Прошло два с половиной года. Что вы скажете сейчас о CouchDB? Есть практика использования?
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории