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

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

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

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

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

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

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

CouchDB (с их сайта )

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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