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

188

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

Бартош Блимке
источник
Возможно, документно-ориентированная база данных может быть в некотором роде похожа на базу данных «entity-attribute-value» (EAV).
ChrisW

Ответы:

167

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

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

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

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

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

Максимум
источник
1
Я никогда не видел, чтобы какая-либо схема базы данных за два года напоминала исходную схему, с которой мы начинали ... так что все равно (что не так ...), вы всегда должны использовать базу данных без схемы = ориентированную на документ; которое я считаю довольно вводящим в заблуждение именем ...
ᆼ ᆺ ᆼ
3
@ int3 Если вы не можете описать свои данные как набор столбцов, как вы должны писать интеллектуальные запросы на этих данных?
Клей Смит
46

CouchDB (с их сайта )

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

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

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

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

Так. Почему CouchDB?

  • REST проще, чем JDBC или ODBC.
  • Нет схемы проще, чем схема.
  • Распространяется таким образом, что кажется простым и недорогим.
С. Лотт
источник
12
Хотя я большой поклонник баз данных NoSQL, первое утверждение (REST проще, чем JDBC) очень сомнительно.
ᆼ ᆺ ᆼ
2
Протокол REST кажется мне довольно простым, поскольку это просто HTTP: без сохранения состояния, несколько методов и т. Д. И т. Д. Возможно, JDBC (под капотом) прост; это не кажется более простым, основанным только на том, чтобы быть состоящим из состояния.
С.Лотт
5
@ S.Lott Разве ответ не должен быть более «общим» вместо того, чтобы ориентироваться только на CouchDb?
Пейсер
"хрупкое перспективное планирование" против чего? По моему опыту, альтернативой является отсутствие планирования, которое приводит к изменению структуры данных спагетти по прихоти.
Теджей Кардон
26

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

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

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

daonb
источник
Почему бы просто не сохранить их в файле или файле для каждого канала?
j_random_hacker
6
потому что couchdb также позволяет создавать интересные представления, используя карту / уменьшить. Например, я могу создать представление на основе источника данных или вычислить итоги для каждого источника.
Daonb
4
Это замечательный момент ... если вы потребляете данные и не имеете никакого контроля над входящей схемой данных - используйте хранилище документов.
Джошуа Робинсон
1
Это первый действительно убедительный аргумент в пользу ценности баз данных NoSQL
Калеб МакНевин
20

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

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

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

pixelcort
источник
1
Отличный момент. Документные (и другие бесщеточные) хранилища данных отлично подходят для быстрой разработки на ранней стадии. Однако по тем же причинам, по которым они отлично подходят для создания прототипов на ранних этапах, они проблематичны для надежных производственных приложений.
Теджей Кардон
6

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

smdelfin
источник
1

Разрабатывать smdelfin: гибкость. Вы можете хранить данные в любой структуре (будучи неструктурированной и все), и каждый документ может быть совершенно другим. CouchDB особенно полезен, потому что с их индексами «представления» вы можете отфильтровывать конкретные документы и запрашивать только это представление, когда вам нужны эти подмножества вашей базы данных.

Моя самая большая победа среди баз данных документов, которые хранят данные в формате JSON: это родной формат для JavaScript. Поэтому веб-приложения JavaScript невероятно хорошо работают с CouchDB. Недавно я создал веб-приложение, которое использует CouchDB, и оно очень быстрое, а также способно обрабатывать постоянно меняющуюся структуру данных.

MitchB
источник
0

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

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

Еще одним преимуществом является простота использования баз данных на основе документов в веб-разработке. Для получения более подробной информации о моделях баз данных NoSQL обратитесь к этому источнику: https://arxiv.org/ftp/arxiv/papers/1509/1509.08035.pdf

evidrascu
источник