voldemort vs. couchdb

Question

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

Каковы плюсы и минусы каждого из них?

Благодаря

Answer 1

ли memcacheDB вариант? Я слышал, что Digg справлялся с проблемами HA.

Answer 2

Project Voldemort выглядит красиво, но я пока не смотрел глубоко в него.

В этом текущем состоянии CouchDB может оказаться неправильной для «массивных объемов данных». Распределение данных между узлами и запросами маршрутизации соответственно включено в дорожную карту, но пока не реализовано. Крупнейшие известные производственные установки CouchDB используют «таблицы» («базы данных» на кушетке) около 200G.

HA не поддерживается CouchDB, но может легко создавать: все узлы CouchDB реплицируют узлы базы данных между собой в настройке с несколькими мастерами. Мы положили два Varnish proxies перед машинами CouchDB, а ящики для лаков сделаны избыточными с CARP. Дизайн CouchDBs «build from the Web» делает такие вещи очень легкими.

Наиболее актуальной проблемой в our setup является тот факт, что все еще существуют проблемы с репликацией больших (многобайтовых) вложений в документы CouchDB.

Я предлагаю вам также проверить традиционный RDBMS-маршрут. There are huge issues с имеющимся талантом вне RDBMS подхода и есть очень способные предложения, доступные из Oracle & Co.

Answer 3

Не достаточно знать, из вашего вопроса, я бы все-таки сказать Project Волдеморт или распределенный хеш-таблицу (DHTs) как CouchDB в целом являются решением вашей проблемы HA.

Эти DHT очень хороши для высокой доступности, но сложнее писать код, чем традиционные реляционные базы данных (РСУБД) относительно согласованности.

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

• Самое большое ограничение большинства магазинов является то, что они не транзакционно безопасны (см Scalaris для транзакционно безопасного магазина), и вам необходимо обеспечить согласованность данных самостоятельно - наиболее использовать согласованность чтения времени путем объединения конфликтующих данные). RDBMS гораздо проще в использовании для согласованности данных (ACID)
• Присоединение данных намного сложнее. В RDBM вы можете легко запрашивать данные по нескольким таблицам, вам нужно написать код в CouchDB для агрегирования данных. Для других магазинов Hadoop может быть хорошим выбором для агрегирования информации.

Читайте о БАЗЫ и CAP теорема о согласованности против доступности.

См

• http://www.metabrew.com/article/anti-rdbms-a-list-of-distributed-key-value-stores/
• http://queue.acm.org/detail.cfm?id=1394128