Техническое: CouchDb с практической точки зрения

На днях вновь пробовал CouchDb — одна из column-based баз данных которая ныне в живёт в инкубаторе проектов Apache.

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

Распишу чуть подробнее о проблемах и ограничениях, ответив вначае на вопросы «почему нет» и только потом «почему да».

1.  Использование Javascript в качестве языка запроса

Собственно это одна из специфичных особенностей именно CouchDb, все запросы идут через функции в Javascript — используется Mozilla SpiderMonkey и, фактически, каждый запрос это «сдвоенные функции» map/reduce. В этом есть свои плюсы, но это и серьёзно меняет сам подход, например, для программистов воспитанных на SQL + ORM + объектной модели потребуется смена мировоззрений чтобы начать использовать такие возможности на полную катушку.

Отдельный вопрос в том что Javascript традиционно считается несерьёзным языком и разработчиков хорошо им владеющих не так уж много.

2. Производительность и хранение данных

Пока ещё производительность CouchDb это не самая сильная сторона движка. Базы того же размера и структуры могут быть загружены в реляционную БД и использоваться куда быстрее. Аналогично с потреблением дискового пространства которое у CouchDb изначально высокое. Особенность здесь в оптимизации базы к изменениями и хранении каждой новой версии документа без перезаписывания — в виде новой записи. Подход довольно радикальный, удобный для репликации, но требующий периодического запуска команды compact для удаления старых версий документов.

3. Промышленные инструменты

У большинства SQL баз данных есть немалое число коммерческих и некоммерческих интерфейсов и инструментов для работы. У большинства бесплатных column-based баз и CouchDb в частности пока они отсутствуют. Web GUI хоть и неплох, но пока ещё лишь слабофункционален. Для промышленной эксплуатации — это важный вопрос.

4. Цена гибкости

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

Отсюда же и отсутствии каких-либо жёстких связей между документами.

И, теперь, про плюсы. У продукта и вообще подхода сейчас такой же статус как был у Ruby-on-Rails или виртуализации в моменты зарождения, недостатков много, но и переспективы видны явно.

Например, для ряда моих исследовательских задач, CouchDb подходит на 100%. Фактически это простой (и дешёвый) способ хранить сложные иерархические данные и map/reduce’ить большие коллекции датасетов, с возможностями репликации и экспорта в JSON.

Лично я считаю что пройдёт не более года когда CouchDb, Thrudb или иной подобный движок пойдёт в активное использование.

About This Author

  • suvit

    На самом деле почти все это уже было в ZODB в 2001 году.

  • http://ivan.begtin.name ivbeg

    А ещё был Metakit и другие решения, суть в том что сейчас этим заинтересовались серьёзные игроки и есть шанс что подход станет мейнстримом.

  • http://marting.myopenid.com amelentev

    А еще есть Java Content Repository, http://jcp.org/en/jsr/detail?id=283
    Но у него довольно ограниченые языки запросов.

  • http://ivan.begtin.name ivbeg

    Java Content Repository — это, всё таки, не база данных и не припомню чтобы там были map/reduce функции.

Яндекс.Метрика