Хочу немного разбавить этот поток лести суровой реальностью:
— Из-за 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 человек, где данные только вручную вбиваются — конечно подойдет.
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2015-01-10 12:23 pm (UTC)— Из-за 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 человек, где данные только вручную вбиваются — конечно подойдет.