Когда кто-то будет использовать MongoDB (или аналогичный) поверх реляционной СУБД?

Я немного сбит с толку насчет всего NoSQL и тому подобного. Когда вы решите использовать что-то вроде MongoDB над чем-то вроде Oracle или MySQL? Я не очень понимаю "разницу", насколько использование идет между ними.

Насколько я понимаю, базы данных типа NoSQL не предназначены для замены СУБД, но что именно они должны делать?

Я использовал CouchDB раньше для трех проектов домашних животных.

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

Основная причина, по которой я выбрал это, а не MSSQL или MySQL, заключается в гибкости, которую вы получаете при его использовании. Нет жесткой схемы. Если через три месяца вам понадобится определенная таблица, чтобы иметь дополнительное поле, и то, и это, вы просто меняете его, и оно оттуда выходит наружу.

Я использовал Beginning CouchDB от Apress, чтобы узнать, как его использовать.

Например, CouchDB использует json для связи с базой данных. Если ваш язык может POST-данные, то вы можете использовать его для связи с БД.

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

Извините, что добавил еще один ответ, но ни один из ответов здесь не является удовлетворительным Этот ответ специфичен для MongoDB (в отличие от огромного множества других вариантов хранения данных, которые не являются реляционными базами данных).

Плюсы:

• MongoDB имеет меньшую задержку на запрос и тратит меньше процессорного времени на запрос, потому что он выполняет намного меньше работы (например, нет соединений, транзакций). В результате он может обрабатывать более высокую нагрузку с точки зрения количества запросов в секунду и поэтому часто используется, если у вас огромное количество пользователей.
• MongoDB легче разделить (использовать в кластере), потому что он не должен беспокоиться о транзакциях и согласованности.
• MongoDB имеет более высокую скорость записи, потому что ему не нужно беспокоиться о транзакциях или откатах (и, следовательно, не нужно беспокоиться о блокировке).
• MongoDB не имеет схемы, если у вас есть особый вариант использования, который может воспользоваться этим.

Минусы:

• MongoDB не поддерживает транзакции . Вот как он получает большинство своих преимуществ.
• Как правило, MongoDB создает больше работы (например, увеличивает стоимость процессора) для клиентского сервера . Например, для объединения данных необходимо выполнить несколько запросов и выполнить соединение на клиенте.
• Даже здесь, в 2017 году, инструментальная поддержка MongoDB меньше, чем у реляционных баз данных, просто потому, что она новее. Кроме того, экспертов MongoDB меньше, чем их коллег по реляционным технологиям.

Пункты, часто неправильно понятые:

• Как MongoDB, так и реляционные базы данных поддерживают индексацию. Их производительность запросов схожа с точки зрения выполнения больших запросов .
• MongoDB не устраняет необходимость миграции или, более конкретно, обновления существующих данных по мере развития вашей схемы. Например: если у вас есть приложение, которое использует таблицу пользователей для хранения определенных данных, и вы изменяете эту таблицу, чтобы она содержала другие данные (допустим, вы добавили поле изображения профиля), вам все равно потребуется:
  • Напишите ваше приложение для обработки объектов, для которых это свойство не определено ИЛИ
  • Напишите одноразовую миграцию, чтобы ввести значение по умолчанию для этого свойства ИЛИ
  • Напишите код для предоставления значения по умолчанию во время запроса, если это поле отсутствует ИЛИ
  • Обработайте пропущенное поле другим способом

Чтобы бесстыдно украсть у Renesis (на самом деле я делаю этот ответ CW):

Использование СУБД вместо других типов:

• Ознакомьтесь с идеей "NoSQL" и других типов БД:
  • NoSQL: если бы это было так просто
  • (выше связано с) Когда использовать MongoDB или другие системы баз данных, ориентированные на документы? ^{в настоящее время удалено на SO} ( подробнее )
  • https://softwareengineering.stackexchange.com/questions/5354/are-nosql-databases-going-to-take-the-place-of-relational-databases-is-sql-going
  • Когда использовать CouchDB против RDBMS
• СУРБД интенсивно используют индексацию для повышения производительности. В очень больших базах данных это может отрицательно сказаться на производительности или даже уменьшить оптимальное количество строк на БД / шард, требующее больше оборудования
• Не так идеально, если вы храните огромное количество данных, но читаете реже
• Если у вас мало внешних связей, реляционные базы данных могут быть не идеальными (хранение документов)

Когда ваши данные не являются реляционными, использование баз данных NoSQL может иметь большие преимущества, такие как производительность и масштабируемость (конечно, в зависимости от обстоятельств). Некоторые шаблоны проектирования, такие как CQRS, значительно упрощают использование нереляционных данных в областях, которые обычно требуют эксклюзивного использования базы данных SQL.

Обычно для кэширования данных используются базы данных, такие как mongo. Например, если вам нужно сгенерировать отчет, вы можете выполнить сложный SQL-запрос, который объединяет и объединяет кучу данных на лету, или вы можете просто получить один JSON-документ из базы данных Mongo, в котором уже есть все, что вам нужно для генерации. Отчет. Это делает чтение данных действительно легким (и быстрым!), Но может сделать запись данных довольно сложной (вот где приходит CQRS).

Такие базы данных, как MongoDB, хороши, когда вы обычно знаете, где находятся ваши данные (в отличие от необходимости писать несколько сложных запросов). В Mongo «связанные» данные либо вложены в родительские данные, либо имеют первичные / внешние ключи. Это замечательно, если, например, у вас есть сообщения и комментарии; как правило, вы не собираетесь отображать комментарии вне контекста поста, поэтому имеет смысл, чтобы комментарии содержались внутри поста (таким образом вы получаете все комментарии к посту без необходимости запрашивать отдельную таблицу).

MongoDB не имеет схемы. Это означает, что он по большей части будет принимать любую структуру данных, которую вы ему предоставите.

С другой стороны, если вам необходимо использовать агрегатные функции и вы чувствуете необходимость запрашивать данные сложными способами, которые не могут быть достигнуты с помощью встраивания или простых отношений в Mongo, тогда вы знаете, что пришло время использовать СУБД, такие как MySQL или PostgreSQL.

MongoDB не предназначен для замены SQL. Он просто удовлетворяет различные потребности, и MongoDB и RDBMS могут использоваться совместно. На мой взгляд, MongoDB не так уж и необходим, если вам не нужно, чтобы ваши данные были гибкими или встроенными в родительский документ. Разработка с MongoDB очень увлекательна, потому что для запуска и запуска проекта (скажем, в Rails) требуется гораздо меньше шагов. Нужно внести изменения? Нет проблем. Просто добавьте атрибут к вашей модели. Готово.

Я не могу говорить о многих других базах данных NoSQL, хотя я знаю, что они, как правило, аналогичным образом предназначены для удовлетворения конкретных потребностей, которые не могут быть удовлетворены СУБД. Некоторые из них полностью находятся в памяти или могут быть очень легко защищены. Я почти уверен, что Cassandra предназначена для продолжения работы без потери данных, если узел выходит из строя. Redis - это в основном хранилище значений ключей, которое хранится в памяти (с периодической записью на диск для сохранения), но также имеет возможность хранить типы данных, такие как наборы, и сортировать их.

Главный выигрыш - когда вы хотите разделить данные или иметь несколько основных баз данных. Вы можете разделить данные в MySQL, но это превращается в серьезную проблему. Если вы выполняете много операций записи, часто полезно разделить данные между несколькими серверами, проблема заключается в том, что если вы хотите иметь сильную ссылочную согласованность при выполнении этого, это может быть очень сложно, если не невозможно, найти теорему CAP.

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

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

У SE Radio было несколько хороших эпизодов на эту тему.

MongoDB хорошо работает, когда вы пишете много данных, и когда ваши запросы не слишком сложны. Поэтому MongoDB хорошо подходит для реализации CQRS с источником событий на командной стороне, т. Е. Ваше хранилище событий является базой данных MongoDB.

Что касается запросов, то мы по-прежнему используем базу данных SQL Server с представлениями и службами данных WCF наверху из-за ее гибкости. Я думаю, что в большинстве случаев вам действительно понадобятся возможности реляционной БД для запросов.

Непосредственное и фундаментальное различие между MongoDB и RDBMS заключается в базовой модели данных. Реляционная база данных структурирует данные в таблицы и строки, в то время как MongoDB структурирует данные в коллекции документов JSON. JSON - это самоописываемый, читаемый человеком формат данных. Первоначально разработанный для облегченного обмена между браузером и сервером, он стал широко распространенным для многих типов приложений.

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

JSON также является естественным форматом данных для использования на прикладном уровне. JSON поддерживает более богатую и гибкую структуру данных, чем таблицы, состоящие из столбцов и строк. Помимо поддержки типов полей, таких как число, строка, логическое значение и т. Д., Поля JSON могут быть массивами или вложенными подобъектами. Это означает, что мы можем представлять набор сложных отношений, которые представляют собой более близкое представление объектов, с которыми работают наши приложения. Использование документов JSON в нашей базе данных означает, что нам не нужно объектно-реляционное отображение между нашей базой данных и приложениями, которые она обслуживает. Мы можем сохранить наши данные в правильной форме

Если ваши данные требуют большого количества запросов, тогда решение NoSQL не годится, а когда вам нужна поддержка транзакций (ACID), тогда NoSql не подходит лучше всего. Я думаю, что NoSQL светит, когда у вас много операций чтения, которые должны быть быстрыми, а когда структура работает несколько раз, вы извлекаете документы или структуру страницы, что-то в этом роде. Но многие NoSQL-решения улучшаются довольно быстро, поэтому недостатки, возможно, скоро исчезнут. В любом случае, я думаю, что реляционные базы данных по-прежнему хорошо подходят для большинства приложений.