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

134

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

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

Глорфиндел
источник
Что ты читаешь? Можете ли вы предоставить нам цитаты или ссылки или некоторую справочную информацию? Мы не знаем, сколько вы знаете - или не знаете.
S.Lott
3
До тех пор, пока они не будут перенесены сюда, существует несколько очень похожих вопросов о StackOverflow , включая Когда использовать MongoDB или другие системы баз данных, ориентированные на документы?
Николь
1
Это веб-масштаб mongodb-is-web-scale.com / s
Froome
3
Цинично: потому что это шумиха, и многим нравится следовать за шумихой.
Сьерд
@Pace: Я думаю, что будет трудно обойти этот пост .
Роберт Харви

Ответы:

34

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

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

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

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

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

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

Сообщество
источник
31
Первые два примера звучат как хороший домен для традиционной реляционной СУБД.
Джонас
4
@yati: Такое приложение звучит похоже на StackOverflow.com, и я считаю, что оно очень хорошо работает с традиционной реляционной базой данных.
Джонас
4
@yatisagade: я не говорю о динамичных социальных сайтах. Но небольшое приложение для заметок и система микроблогов .
Джонас
2
Как не иметь определенную схему когда-либо плюс? В реляционной базе данных, если через три месяца вам нужно дополнительное поле, вы просто добавляете это поле. С реляционной БД вы не можете динамически добавлять поле, но вы также не можете динамически изменять код приложения для работы с динамически добавляемым полем.
Секрет Соломонова
12
Этот ответ, кажется, предполагает, что схема реляционной базы данных не может быть изменена. Я не могу понять, какое количество недоразумений может заставить кого-то в это поверить. Добавить новый столбец в реляционную базу данных тривиально. Как правило, есть хороший пользовательский интерфейс, или, если вы предпочитаете писать его, это можно сделать одним оператором SQL.
JacquesB
24

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

Плюсы:

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

Минусы:

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

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

  • Как MongoDB, так и реляционные базы данных поддерживают индексацию. Их производительность запросов схожа с точки зрения выполнения больших запросов .
  • MongoDB не устраняет необходимость миграции или, более конкретно, обновления существующих данных по мере развития вашей схемы. Например: если у вас есть приложение, которое использует таблицу пользователей для хранения определенных данных, и вы изменяете эту таблицу, чтобы она содержала другие данные (допустим, вы добавили поле изображения профиля), вам все равно потребуется:
    • Напишите ваше приложение для обработки объектов, для которых это свойство не определено ИЛИ
    • Напишите одноразовую миграцию, чтобы ввести значение по умолчанию для этого свойства ИЛИ
    • Напишите код для предоставления значения по умолчанию во время запроса, если это поле отсутствует ИЛИ
    • Обработайте пропущенное поле другим способом
аллюр
источник
2
Я хотел бы добавить огромную вещь, которая так или иначе упускается во многих обсуждениях NoSQL против RDBMS: базы данных NoSQL намного сложнее для специальных запросов (это «не часть SQL». Это правда, являетесь ли вы разработчиком или нет. Поэтому они также гораздо труднее создавать отчеты с, что имеет решающее значение для любого серьезного бизнеса.
Майкл
Хех, я бы почти назвал это функцией MongoDB, поскольку я не одобряю такого рода взаимодействие с моими базами данных. Однако у Mongo есть специальный язык запросов и специальный графический клиент (Compass). Он не так богат, как SQL, поэтому я согласен, что это потенциальный недостаток, но лично для меня это никогда не изменит, когда я решу, какую базу данных использовать.
Пейс
1
Почему бы вам не рекомендовать исследовать данные в вашей базе данных? Если в этой базе данных есть какая-либо полезная информация для бизнеса, она должна быть максимально доступной. Очевидно, что, не добавляя нагрузку на производство, вы прочли реплики.
Майкл
Это, вероятно, интересный вопрос сам по себе, и я думаю, что многие люди будут иметь разные точки зрения. Лично я избегаю этого, потому что это становится проблемой обслуживания. Я создаю веб-приложения и предоставляю API-интерфейсы REST, которые обязуюсь поддерживать и оптимизировать производительность. Я был в ситуациях, когда я не мог вносить оптовые изменения в базу данных, потому что это сломало бы слишком много сценариев запросов инженеров по продажам, и я пытаюсь избежать этого сценария сейчас. Например, я только недавно стал частью моей базы данных с PostgreSQL на Cassandra для высокой производительности и не должен был менять мой API.
Пейс
В конце концов у вас всегда будут заинтересованные стороны, заинтересованные в просмотре данных. Будь то с помощью SQL-запроса или какого-либо скрипта ipython для ноутбука, или с помощью re: dash. Поэтому, когда вы вносите изменения в базу данных, вы всегда должны быть уверены, что не нарушаете эти зависимости. SQL (не RDBMS) делает данные более доступными, и это хорошо для бизнеса.
Майкл
13

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


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

Matthew Читать
источник
4
«В СУБД интенсивное использование индексации для повышения производительности» Разве индексирование не используется и в MongoDB?
Ротарети
Когда использовать MongoDB или другие системы баз данных, ориентированные на документы? в настоящее время удалено на SO ... не более .. вновь открыли вопрос, а также защитили его. Не уверен, что причина удаления.
Рахул
9

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

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

Грэм Хилл
источник
8

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

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

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

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

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

Ravenstine
источник
6

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

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

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

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

Захари К
источник
Следует помнить, что шардинг сильно зависит от архитектуры вашего центра обработки данных. Если у вас есть серверная стойка, ее производительность потрясающая. На распределенных ДЦ не так уж и много. Согласились с тем, что вы говорите об общей простоте разбиения на базы данных NoSql - но надежность является ключевой проблемой.
Апурв Хурасия
Если вы делаете много записей, у вас может быть просто две модели: модель чтения денормализованных стронных индексов и модель неиндексированной записи. Естественно, необходима репликация, которая добавляет сложности. Вам придется оценить, что для вас более невыгодно: справиться с ограничениями NoSQL, т.е. выполнить гораздо больше работы по программированию самостоятельно, чтобы сопоставить записи в домене java, либо использовать имеющуюся технологию репликации БД, или вы будете стоить дороже на условиях конфигурации и оборудования.
Лоуренс
1

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

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

Рой Диктус
источник
Если вы пишете много данных, не повлияют ли глобальные блокировки записи на вас?
Апурв Хурасия
1
Обратите внимание, что Mongodb больше не использует глобальную блокировку записи (и уже была обновлена, чтобы не требовать ее при публикации вышеуказанного комментария).
Жюль
1

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

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

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

Дивакар упадхяй
источник
1

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

Marko
источник