CouchDB (не путать с Couchbase !) — документо-ориентированная СУБД, написанная на языке Erlang . В вышедшей недавно версии 2.0 в CouchDB добавили Riak -подобное шардирование, что наконец-то делает эту СУБД кому-то интересной. К тому же, в отличие от Riak, в CouchDB всегда была совершенно бесплатная (не в enterprise edition версии и т.д.) кросс-датацентровая master-slave и master-master репликация. Давайте попробуем разобраться, как же этим хозяйством вообще пользоваться, и подходит ли оно уже для продакшена.

Установка

Для своих страшных экспериментов я использовал Ubuntu 16.04. Готовых пакетов для различных дистрибутивов Linux разработчики CouchDB не предоставляют, поэтому имеет смысл один раз настроить его в Docker или LXC-контейнере , и потом использовать этот контейнер на всех узлах кластера. Для быстрой установки CouchDB мной был написан bash-скрипт . Имеет смысл сразу воспользоваться им. В ближайших двух параграфах я расскажу, как этот скрипт работает.

Ставим зависимости:

Качаем архив с исходниками с зеркала, которое предложат на официальном сайте. Затем говрим:

Создаем пользователя couchdb:

Копируем rel/couchdb в домашний каталог пользователя и выставляем правильные права:

Проверяем, что все было сделано правильно:

У меня в логи стали сыпаться ворнинги про отсутствующую базу данных _users. Не переживайте, мы это вот-вот пофиксим.

На http://localhost:5984 должны увидеть:

Заметьте, что все общение клиентов с CouchDB происходит по REST API (иногда не REST, а просто какому-то кастомному HTTP API), со всеми вытекающими отсюда преимуществами и недостатками .

На http://localhost:5984/_utils/ увидим красивый веб-интерфейс вроде такого:

В веб-интерфейсе открываем Setup и создаем кластер из одной ноды (там все просто). После этого в логи перестанут сыпаться какие-либо ошибки.

Автозапуск через runit

Для автоматического запуска CouchDB при запуске системы разработчики рекомендуют использовать runit (как подсказал мне @listochkin , читается run-it, а не r-unit :).

Создаем директорию, куда будут писаться логи:

Создаем директории с конфигурацией для запуска couchdb:

В /etc/sv/couchdb/log/run пишем:

Опционально можно создать /etc/sv/couchdb/log/config c указанием, когда производить ротацию логов и подобного рода вешей, если дэфолты не устраивают. Формат конфига, а также дэфолты описаны в man svlogd .

Также создаем скрипт /etc/sv/couchdb/run:

Делаем обоим скриптам chmod u+x . Затем:

Через несколько секунд runit должен заметить новый сервис и запустить его. Управление:

Можно проверить, что после рестарта системы CouchDB запускается автоматически.

Объединение нод в кластер

Важно! Максимальный размер кластера в CouchDB по умолчанию составляет 8 нод. Чтобы изменить это, нужно отредактировать значение параметра q в секции [cluster] в etc/local.ini. Подробности см здесь .

Поднимаем три совершенно ненастроенные ноды. Если нода уже настроена, например, вы создали кластер в диалоге Setup, вот вам bash-скрипт , который все это откатывает.

Шаг 1. В /home/couchdb/etc/vm.args меняем параметры name и cookie. Кука должна быть супер секретной ( pwgen 16 ) и одинаковой на всех нодах кластера; имена нод должны быть уникальны:

Примечание: Узнать больше про распределенный Erlang и его куки можно из заметки Мои страшные эксперименты с Erlang и gen_server .

На всех нодах говорим:

Смотрим список известных нод:

Пример ответа:

Шаг 2. На каждой ноде указываем имя пользователя и пароль, а также какой IP-адрес должна слушать нода:

Шаг 3. Объединяем ноды в кластер. Для этого на одной ноде для кадой ноды выполняем:

По окончании добавления нод говорим:

Проверяем, что ноды действительно объединились в кластер:

Список all_nodes — это ноды, которые сейчас онлайн, cluster_nodes — это вообще все существующие ноды.

Работа с документами

Итак, у нас есть настроенный кластер CouchDB. Попробуем сделать с ним что-нибудь сравнительно полезное.

Создаем пользователя для доступа к БД:

Заметьте, что пользователей в CouchDB может создавать кто угодно, как это делается на веб-сайтах. Тут пишут , что это такая фича.

Проверяем, что пользователь действительно создался:

Ответ:

Под админом создаем базу contacts (по аналогии с базой из заметки Пишем простой RESTful сервис с использованием Scotty ):

Даем права для работы с этой базой пользователю afiskon:

Проверяем, что пользователь теперь имеет доступ к базе:

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

Проверяем, что пользователь не может удалить базу:

Для этого пользователь должен быть среди admins базы, а не members.

Создаем документ:

Ответ:

Читаем документ:

Ответ:

Обновление и удаление документа выглядит так. Вы читаете весь документ, меняете его, и затем шлете запрос с указанием _rev считанного документа. Это нужно для ситуаций, когда один документ одновременно меняется несколькими клиентами. В сущности это означает, что вы всегда делаете CAS. Напомню, что в тех же Riak и Cassandra это не так. Поддержка CAS в частности означает, что поверх CouchDB можно написать распределенные транзакции .

Пример обновления документа:

В случае конфликта получим ответ:

Удаление документа:

А еще можно получить id всех документов в базе:

Пример ответа:

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

Разумеется, рассмотреть весь API CouchDB в рамках одной статьи не представляется возможным. Подробности вы найдете в официальной документации . Там еще немало интересного про аттачи, репликацию и views, а также специальный API поиска безо всякого MapReduce.

Заключение

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

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

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

Из приятных моментов хочется отметить, что CouchDB действительно пытается не терять данные. Например, он делает fsync на все записи. В отличие от него тот же Couchbase по умолчанию старается держать все в памяти, сбрасывая данные на диск лишь изредка. Впрочем, в Couchbase есть репликация, так что, возможно, это и не такая уж большая проблема. Еще из интересного — максимальный размер документа в CouchDB по умолчанию равен 64 Мб и может быть увеличен при помощи параметра max_document_size. Для сравнения, в MongoDB и Couchbase захардкожено, что докуметов размером больше 16 и 20 Мб соответственно не бывает. Также CouchDB из коробки поддерживает сжатие документов при помощи snappy и zlib , а также подписку на обновление документов при помощи change feeds, push/pull replication и возможности вызывать указанные программы при изменении документов.

Наконец, сообщество разработчиков CouchDB — пожалуй, самое открытое и дружелюбное из всех, что мне до сих пор встречались. Мейнтейнеры проекта отвечают на любые вопросы в IRC и охотно принимают посылаемые пулл реквесты (см раз , два ). Если вдруг вы ищите интересный open source проект для работы над ним в свободное время , лучше CouchDB вам будет сложно что-то найти.

Таковы мои впечатления от CouchDB. А вы что скажете?