Что такое CouchDB

[ermouth]

Прочитал на Хабре про успехи npm и решил написать пост. npm – это пакетный менеджер и публичный репозиторий для node.js, и успехи реально очень впечатляющие.

Фишка в том, что этот репозиторий – база CouchDB. Не “веб-сервер плюс БД”, а именно просто БД. Кластер там, с обвесами – но основные функции выполняет CouchDB, вот на её мету прямой выход. И именно CouchDB там используется неспроста.

Доступность

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

По-хорошему, CouchDB сразу после установки становится веб-сервисом. Доступ к БД – только через http(s)-запросы, через REST-интерфейс, то-есть веб-сервер уже встроен в БД. Веб-приложение админки тоже встроено в БД, аж в двух версиях.

Система контроля доступа – простая, но совершенно железобетонная – тоже встроена в БД, как и механика авторизации.

БД умеет синхронизироваться в непрерывном режиме с другими экземплярами через http(s), в тч в режиме “мастер-мастер”. Протокол репликации хорошо документирован и основан на согласовании деревьев ревизий.

Последняя фича, например, значит, что можно иметь полную локальную “живую” копию npm. Можно даже в браузере, без установки CouchDB.

Хранение и запись

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

Операция записи/обновления – просто POST запрос, например, аяксом. Запись неблокирующая, это называется MVCC, и тут он честный, а не как в табличных БД.

У каждого дока есть ревизия, которая состоит из номера версии и случайного значения (типа 15-12efdab). При каждой записи в док версия инкрементится, а значение меняется. Записать в док можно только отправив значение предыдущей ревизии, причём если сохранённая ревизия не равна отправляемой, запись отменяется.

Запись идёт в режиме “append only”, ничего не пишется поверх. Это значит, что база помнит все ревизии документов до тех пор пока не будет выполнена операция очистки/оптимизации. Также это значит, что база выжимает из SSD-дисков всё, на что они способны – и при этом их бережёт.

И самое главное – к JSON-документам возможны файловые аттачи, примерно как к емэйлам. То-есть это не просто блобы, это блобы с именем и mime-типом.

Выборка по ключу

Нет ничего проще – GET-запрос типа domain/dbname/doc_id – например https://ermouth.couchappy.com/cwmanual/cw-Demo-Controls-4vx1 – сразу отдаст JSON-документ.

В этом документе есть приаттаченный файл – картинка. Она тоже доступна по прямой ссылке https://ermouth.couchappy.com/cwmanual/cw-Demo-Controls-4vx1/turing.jpg. Вот она, отображается прямо из CouchDB.

Выборка запросами

Любая выборка запросом из CouchDB – это выполнение map/reduce и выдача запрошенного диапазона ключей.

Именованные пары map/reduce функций, к которым выполняются запросы, хранятся в самой БД в специальных документах. Документ выглядит примерно так ermouth.couchappy.com/cloudwall/_design/cloudwall. Видно, что функция – javascript.

Запрос к этой map/reduce паре (в которой reduce, правда, нет) выглядит примерно так:
ermouth.couchappy.com/cloudwall/_design/cloudwall/_view/info?startkey="cw"&endkey="cwz"

На выходе – краткая информация о документах в базе, подготовленная map-функцией. В диапазоне ключей cw…cwz.

Важнейшее отличие CouchDB от других БД – результаты вычислений map/reduce кэшируются и повторно map-функции не вычисляются, если документ не обновился.

То-есть map/reduce не требует фуллскана каждый раз, как, например, это происходит в Mongo. Фактически map-функции используются для построения индексов.

Валидация записи и частичное обновление

POST-запросы на запись могут проверяться в БД функциями-валидаторами. Они тоже js и тоже хранятся прямо в БД как специальные документы. Например, вот эта функция не даст писать в БД, если вы не авторизованы:

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

Ну то-есть например надо обновить в документе только таймстамп. Чтоб не гонять весь док по сети, можно вызвать на сервере сохранённую функцию, которая это сделает “не отходя от кассы”.

Применимость CouchDB

Везде, где reads>>writes и структура хранимых данных – более-менее сложная. Также в силу специфики http и сериализации как читать, так и писать лучше сразу помногу.

Табличка вот по кейсам, 0 – совсем не подходит, 5 – лучше не придумаешь.

Версионированные хранилища доков	5
Распределённые синхронизированные хранилища	4
Хранилища частично нормализованных связанных данных	1-4
Полностью нормализованные данные	0
Быстрые логи	2
Медленные логи / Агрегаторы логов для анализа	5
Вообще большие наборы данных для анализа	5
Необходимость транзакционной целостности	0
Сложные повторяющиеся “фигурные” выборки	4
Выборки сабсетов узлов документов (частей документов)	5
Подключенные клиенты хотят уведомлений, что база обновилась	4
Хранение файлов (типизированных блобов)	4
SSD диски как хранилище	5+++
Синхронизация / репликация по каналам с потерями и обрывами	5+++

CouchDB вместо сервера приложений

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

Так вот, жизнь показала, что в подавляющем большинстве случаев сервер приложений рядом с CouchDB не нужен вообще – хранимые функции прекрасно со всем справляются. То-есть получается связка из веб-приложения в браузере и БД на сервере, и между ними ничего, кроме сети и https-запросов.

Такая архитектура проста и надёжна, как железный лом – если в ней что-то и ломается (что почти невероятно), то мгновенно понятно что.

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

----

В общем, всем ребятам, кто в вебе или около, очень советую как минимум покрутить-попробовать. Тем более анонимные эксперты вот говорят, что эта технология – один из трендов 2015.

Есчо, на Винде тоже прекрасно работает.

Comments

[morfizm.livejournal.com]

"По-хорошему такая целостность вообще очень редко когда нужна и *недостижима* для распределённых систем в общем случае, но это тема отдельного поста."

Что, правда? Очень хочу прочесть пост с доказательством недостижимости :)
(Я думаю, что могу строго доказать достижимость в общем случае :))

[tonsky.livejournal.com]

Хочу немного разбавить этот поток лести суровой реальностью:

— Из-за append-only природы, CouchDB не умеет чистить базу «на лету». Когда нужно избавиться от старых ревизий, надо создать рядом новую базу и перенести свежие ревизии туда. Что вообще говоря нетривиальная операция, потому что сам CouchDB никак не помогает в этом. Все это cильно ограничивает область применения CouchDB: либо мы никогда не чистим старые ревизии (always grow, пишем мало, места на диске много), либо городим сложный огород поверх него сами.

— Репликация eventual consistent, то есть запись на один сервер появится на соседних не сразу. Это усложняет сценарий «записали в таблицу и тут же выбрали из нее записанное» в условиях кластера и round-robin балансера. Спасибо хотя бы conflict resolution можно управлять.

— CouchDB репликация инкрементальная, то есть то что ты записал на один сервер ничего не гарантирует: ты записал, сервер сдох, запись потерялась, не успев синхронизироваться. DynamoDB модель, например, дает гораздо более весомые гарантии и позволяет ими управлять (какое мин. кол-во серверов должно подтвердить запись).

— Поднятие CouchDB процесса после сбоя требует чтения _всего_ файла БД (потому что он append-only, и самый свежий корень индекса записан скорее всего где-то ближе к концу)

Про неупомянутые плюсы:

— база хранится в append-only файле и считается неубиваемой. Что бы не произошло с приложением (kill, выключение питания с недосинкавшейся дисковой очередью), файл можно будет прочитать и базу — открыть

В целом, CouchDB известен (и положительно, и печально) из-за особенностей своего алгоритма хранения (append-only btree), и недостатки вытекают напрямую из фундаментальных его особенностей, с реализацией все более-менее в порядке. Плюс он был одним из пионеров nosql революции — сейчас, впрочем, по ощущениям, болтается где-то на задворках.

Если нужно что-то минимальное, типа бэкенда для UI чего-то внутреннего, для 10 человек, где данные только вручную вбиваются — конечно подойдет.