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

Question

Почему я должен использовать базу данных на основе документов, такую ​​как CouchDB, вместо использования реляционной базы данных. Существуют ли типичные виды приложений или доменов, в которых база данных на основе документов более подходит, чем реляционная база данных?

Answer 1

Вероятно, вы не должны: -)

Второй наиболее очевидный ответ - вы должны использовать его, если ваши данные не являются реляционными. Обычно это проявляется в отсутствии простого способа описать ваши данные как набор столбцов. Хорошим примером является база данных, где вы фактически храните бумажные документы, например, сканируя офисную почту. Данные - это отсканированный PDF, и у вас есть некоторые метаданные, которые всегда существуют (отсканировано в, отсканировано, тип документа) и множество возможных полей метаданных, которые существуют когда-то (номер клиента, номер поставщика, номер заказа, сохраняются в файле до тех пор, пока Полный текст и т. Д.). Обычно вы заранее не знаете, какие поля метаданных вы добавите в течение следующих двух лет. Такие вещи, как CouchDB, работают намного лучше для такого рода данных, чем реляционные базы данных.

Мне также лично нравится тот факт, что мне не нужны никакие клиентские библиотеки для CouchDB, кроме HTTP-клиента, который в настоящее время включен почти в каждый язык программирования.

Вероятно, наименее очевидный ответ: если вы не чувствуете боли при использовании RDBMS, оставайтесь с ней. Если вам всегда нужно обходить свою СУБД, чтобы выполнить свою работу, вам стоит взглянуть на документно-ориентированную базу данных.

Для более подробной проверки списка это сообщение Ричарда Джонса .

Answer 2

CouchDB (с их сайта )

• Сервер базы данных документов, доступный через RESTful JSON API. Как правило, реляционные базы данных не просто доступны через службы REST, но требуют гораздо более сложного SQL API. Часто эти API (JDBC, ODBC и т. Д.) Довольно сложны. ОТДЫХ довольно прост.

• Специальная и без схемы с плоским адресным пространством. Реляционные базы данных имеют сложную фиксированную схему. Вы определяете таблицы, столбцы, индексы, последовательности, представления и другие вещи. Диван не требует такого уровня сложного, дорогого, хрупкого расширенного планирования.

• Распределенная, обладающая надежной, инкрементальной репликацией с двунаправленным обнаружением и управлением конфликтами. Некоторые коммерческие продукты SQL предлагают это. Из-за API SQL и фиксированных схем это сложно, сложно и дорого. Для Дивана это кажется простым и недорогим.

• Возможность запроса и индекса, с механизмом отчетов, ориентированным на таблицы, который использует Javascript в качестве языка запросов. Так же, как SQL и реляционные базы данных. Здесь ничего нового.

Итак. Почему CouchDB?

• REST проще, чем JDBC или ODBC.
• Нет схемы проще, чем схема.
• Распространяется так, чтобы казаться простым и недорогим.

Answer 3

Для тупого хранения и обслуживания других серверов-данных.

В последние пару недель я играл с приложением lifestream, которое опрашивает мои каналы (вкусные, flickr, github, twitter ...) и сохраняет их в couchdb. Прелесть couchdb в том, что он позволяет мне сохранять исходные данные в их первоначальной структуре без лишних затрат. Я добавил поле 'class' к каждому документу, хранящему исходный сервер, и написал класс визуализации javascript для каждого источника.

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

Answer 4

Быстрая разработка приложений приходит на ум.

Когда я постоянно развиваю свою схему, я постоянно расстраиваюсь из-за необходимости поддерживать схему в MySQL / SQLite. Хотя я еще не сделал слишком много с CouchDB, мне нравится, как просто развивать схему во время процесса RAD.

Случай, когда вы можете не захотеть использовать нереляционную базу данных, - это когда у вас много отношений «многие ко многим»; Я еще не разобрался, как создавать хорошие функции MapReduce для таких отношений, особенно если вам нужны метаданные в отношениях соединения. Я не уверен, но я не думаю, что функции CouchDB Map могут вызывать свои собственные запросы к базе данных, поскольку это может вызвать бесконечные циклы.

Answer 5

Используйте базу данных на основе документов, когда вам не нужно хранить данные в таблицах с полями одинакового размера для каждой записи. Вместо этого вам нужно хранить каждую запись как документ, имеющий определенные характеристики. Любое количество полей любой длины может быть динамически добавлено в документ в любое время без необходимости сначала «модифицировать таблицу». Поля на основе документов также могут содержать несколько частей данных.