Когда использовать CouchDB vs RDBMS

Я смотрю CouchDB, у которого есть множество привлекательных функций над реляционными базами данных, включая:

интуитивно понятный интерфейс REST/HTTP
простая репликация
данные, хранящиеся в виде документов, а не нормализованные таблицы

Я ценю, что это не зрелый продукт, поэтому его следует принимать с осторожностью, но мне интересно, действительно ли это реальная замена для РСУБД (несмотря на вводную страницу, в которой говорится иначе) http://couchdb.apache.org/docs/intro.html).

В каких обстоятельствах CouchDB будет лучшим выбором базы данных, чем RDBMS (например, MySQL), например. с точки зрения масштабируемости, дизайна + времени разработки, надежности и обслуживания.
Есть ли еще случаи, когда RDBMS по-прежнему остается правильным выбором?
Является ли это либо или или выбором, либо гибридным решением, которое, скорее всего, появится как лучшая практика?

Ответ 1

Недавно я присутствовал на конференции NoSQL в Лондоне и думаю, что теперь мне лучше понять, как ответить на исходный вопрос. Я также написал сообщение в блоге, и есть еще пара good те.

Ключевые моменты:

Мы накопили, вероятно, 30-летний опыт администрирования реляционных баз данных, поэтому не должны заменять их без тщательного рассмотрения; нереляционные хранилища данных менее зрелые, чем реляционные, и поэтому по своей сути более рискованно принимать
Существуют разные типы нереляционных хранилищ данных; некоторые из них хранятся в ключевом значении, некоторые из них хранятся в документах, некоторые из них представляют собой базы данных графов.
Вы можете использовать гибридный подход, например. комбинация СУРБД и хранилища данных графа для сайта социального обеспечения.
Хранилища данных документов (например, CouchDB и MongoDB), вероятно, наиболее близки к реляционным базам данных и предоставляют структуру данных JSON со всеми полями, представленными иерархически, что позволяет избежать необходимости объединения таблиц, и (некоторые могут утверждать) - это улучшение на традиционное объектно-реляционное сопоставление, которое большинство используемых в настоящее время приложений
Не реляционные базы данных поддерживают репликацию (включая master-master); реляционные базы данных также поддерживают репликацию, но она может быть не такой всеобъемлющей, как нереляционная опция
Очень крупные сайты, такие как Twitter, Digg и Facebook, используют Cassandra, которая построена с нуля для поддержки кластеризации.
Реляционные базы данных, вероятно, подходят для 90% случаев

Таким образом, консенсус, похоже, "следует проявлять осторожность".

Ответ 2

Пока кто-то дает более подробный ответ, вот некоторые плюсы и минусы для CouchDB

Плюсы:

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

Минусы:

вам нужно создавать представления для каждого запроса, то есть запросы ad-hoc, подобные запросам (например, конкатенация динамических запросов WHERE и SORT в SQL), недоступны.
у вас либо будут избыточные данные, либо вы будете сами внедрять логику объединения и сортировки на стороне клиента (например, сортировка отношений "многие-ко-многим" для нескольких полей).

Плюсы или минусы:

Создание ваших представлений не так прямолинейно, как в SQL, это больше похоже на решение головоломки. Зависит от вашего типа, если это pro или con:)

Ответ 3

CouchDB является одним из нескольких доступных "хранилищ ключей/значений", другие включают в себя такие старые, как BDB, ориентированные на веб-сайты, такие как Persevere, MongoDB и CouchDB, новый супер-быстрый, как memcached (только RAM) и Tokyo Cabinet, и огромные магазины как Hadoop и Google BigTable (MongoDB также утверждает, что находится в этом пространстве).

Конечно, пространство для хранилищ ключей/значений и реляционных БД. Традиционно большинство RDB считаются слоем выше ключа/значения. Например, MySQL использовал BDB как дополнительный бэкэнд для таблиц. Короче говоря, ключ/значения ничего не знают о полях и отношениях, которые являются основой SQL.

Ключи/ценности обычно легче масштабируются, что делает их привлекательным выбором при разрастании, например, Twitter. Конечно, это означает, что любые отношения между сохраненными значениями должны управляться вашим кодом, а не просто объявляться в SQL. Подход CouchDB заключается в том, чтобы хранить большие "документы" в части ценности, делая их (в основном) автономными, поэтому вы можете получить большую часть необходимых данных в одном запросе. Многие варианты использования подходят для этой идеи, другие - нет.

Текущая тема, которую я вижу, заключается в том, что после того, как "Rails не масштабируется!" пугают, теперь многие люди понимают, что это не о вашей веб-инфраструктуре; но и о интеллектуальном кэшировании, чтобы избежать попадания в базу данных и даже веб-приложения, когда это возможно. Восходящая звезда имеет memcached.

Как всегда, все зависит от ваших потребностей.

Ответ 4

Это трудный вопрос для ответа. Поэтому я попытаюсь выделить области, в которых CouchDB может работать против вас.

Два самых больших источника сложности в списках рассылки Couch Users и Dev, которые есть у людей:

Сложные объединения данных.
Многоступенчатая карта/сокращение.

Couch Views довольно много островов для себя. Если вам нужно агрегировать/объединить/пересечь набор представлений, вы в значительной степени должны сделать это на прикладном уровне. Есть несколько трюков, которые вы можете сделать с помощью сортировки вида и сложных ключей, чтобы помочь с объединениями, но они до сих пор доступны для некоторых типов данных. Это может быть или не быть пригодным для использования в различных приложениях. При этом много раз эта проблема может быть уменьшена или устранена путем структурирования ваших данных по-разному.

Комментарии других людей по этому вопросу демонстрируют некоторые из разных типов данных, которые хорошо подходят для CouchDB.

Еще одна вещь, о которой следует помнить, заключается в том, что много раз данные, которые могут потребоваться для объединения/слияния/пересечения, будут представлять собой данные, которые вы будете делать в автономном режиме в базе данных РСУБД, так что вы можете ничего не потерять, в CouchDB.

Короткий ответ: Думаю, в конце концов CouchDB сможет справиться с любой проблемой, которую вы хотите бросить на нее. Но уровень комфорта, который у вас есть, может отличаться от разработчика к разработчику. Думаю, это несколько субъективно. Мне нравится использовать полный язык turing для запроса моих данных и сохранения большей логики в прикладном уровне. Ваш пробег может отличаться.

Ответ 5

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

Ответ 6

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

Ответ 7

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

Для более вложенных данных, таких как xml, база данных документов должна обеспечивать более быстрый доступ к вашим данным. Кроме того, модель хранения более похожа на модель хранения данных, поэтому поиск должен быть более прямым.