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

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

Из моего понимания Базы данных типа NoSQL не предназначены для замены RDBMSes, но что именно они должны делать?

128 голосов | спросил user6791 3 MarpmThu, 03 Mar 2011 21:48:20 +03002011-03-03T21:48:20+03:0009 2011, 21:48:20

9 ответов


33

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

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

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

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

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

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

ответил 3 MarpmThu, 03 Mar 2011 21:55:18 +03002011-03-03T21:55:18+03:0009 2011, 21:55:18
13

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

Плюсы:

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

Минусы:

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

Баллы Часто неправильно понимают:

  • Обе MongoDB и реляционные базы данных поддерживают индексирование. Их производительность запросов сходна с точки зрения выполнения больших запросов .
  • MongoDB не устраняет необходимость переноса или, более конкретно, обновление существующих данных по мере развития вашей схемы. Например: если у вас есть приложение, которое полагается на таблицу пользователей, чтобы содержать определенные данные, и вы изменяете эту таблицу, чтобы содержать разные данные (допустим, вы добавляете поле изображения профиля), вам все равно необходимо:
    • Напишите вам приложение для обработки объектов, для которых это свойство не определено OR
    • Напишите одноразовую миграцию, чтобы установить значение по умолчанию для этого свойства ИЛИ
    • Введите код, чтобы указать значение по умолчанию во время запроса, если это поле отсутствует ИЛИ
    • Обработать недостающее поле каким-либо другим способом.
ответил Pace 18 PMpTue, 18 Apr 2017 23:13:21 +030013Tuesday 2017, 23:13:21
12

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


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

ответил Pace 18 PMpTue, 18 Apr 2017 23:13:21 +030013Tuesday 2017, 23:13:21
9

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

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

ответил Graeme Hill 4 MaramFri, 04 Mar 2011 00:17:15 +03002011-03-04T00:17:15+03:0012 2011, 00:17:15
7

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

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

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

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

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

ответил Ravenstine 24 MaramTue, 24 Mar 2015 00:14:03 +03002015-03-24T00:14:03+03:0012 2015, 00:14:03
6

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

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

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

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

ответил Zachary K 22 MarpmTue, 22 Mar 2011 17:57:07 +03002011-03-22T17:57:07+03:0005 2011, 17:57:07
1

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

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

ответил Roy Dictus 22 MarpmTue, 22 Mar 2011 17:45:45 +03002011-03-22T17:45:45+03:0005 2011, 17:45:45
1

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

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

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

ответил Diwakar upadhyay 23 MarpmMon, 23 Mar 2015 14:00:43 +03002015-03-23T14:00:43+03:0002 2015, 14:00:43
1

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

ответил marko 24 MarpmTue, 24 Mar 2015 15:04:24 +03002015-03-24T15:04:24+03:0003 2015, 15:04:24

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132