Техническое: 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

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