Каковы преимущества использования базы данных без схемы, такой как MongoDB, по сравнению с реляционной базой данных?

95

Я привык использовать реляционные базы данных, такие как MySQL или PostgreSQL, в сочетании с фреймворками MVC, такими как Symfony, RoR или Django, и я думаю, что это отлично работает.

Но в последнее время я много слышал о MongoDB, которая является нереляционной базой данных, или, если цитировать официальное определение ,

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

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

В каких случаях использование MongoDB (или подобных баз данных) лучше, чем использование «классических» реляционных баз данных? И каковы в целом преимущества MongoDB перед MySQL? Или, по крайней мере, почему все так иначе?

Если у вас есть указатели на документацию и / или примеры, это тоже будет большим подспорьем.

Гийом Фландр
источник

Ответы:

57

Вот некоторые из преимуществ MongoDB для создания веб-приложений:

  1. Модель данных на основе документов. Базовая единица хранения аналогична JSON, словарям Python, хешам Ruby и т. Д. Это богатая структура данных, способная хранить массивы и другие документы. Это означает, что вы часто можете представить в одном объекте конструкцию, которая потребует нескольких таблиц для правильного представления в реляционной базе данных. Это особенно полезно, если ваши данные неизменяемы.
  2. Возможность глубокого запроса. MongoDB поддерживает динамические запросы к документам, используя язык запросов на основе документов, который почти такой же мощный, как SQL.
  3. Никаких миграций схемы. Поскольку MongoDB не содержит схемы, ваш код определяет вашу схему.
  4. Четкий путь к горизонтальной масштабируемости.

Вам нужно будет узнать об этом больше и поиграть с ним, чтобы получить лучшее представление. Вот онлайн-демонстрация:

http://try.mongodb.org/

Кайл Банкер
источник
3
Я принял этот ответ, но взгляните на другие хорошие ответы ниже. @marcgg ответил, например, интересными ссылками.
Guillaume Flandre
Сказать «лучшая производительность» неверно; это зависит от того, что вы делаете. MongoDB, не поддерживающий соединения, не делает его быстрее, это просто означает, что он лучше справляется с простыми операциями с БД (предположительно, я на самом деле не видел теста, чтобы доказать это). Как только вам понадобится функциональность, которую предоставляет объединение, ваша производительность с Mongo резко упадет. Но если вам вообще не нужны объединения или реляционные функции, тогда, конечно, Mongo может быть более производительным / масштабируемым.
Саша Чедыгов
Спасибо @SashaChedygov. Я согласен с тобой. Это было довольно небрежно с моей стороны в 2010 году :)
Kyle Banker
@KyleBanker: Не беспокойтесь, просто комментируйте, если кто-то увидит это в 2013 году и поймет неверное представление. :) +1 за правку.
Саша Чедыгов
Mongo предлагает очень специфический путь горизонтальной масштабируемости, который полезен в определенных сценариях ....
AK_
23

Есть множество преимуществ.

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

class Setting
  include MongoMapper::Document

  key :news_search, String, :required => true
  key :is_availaible_for_iphone, :required => true, :default => false

  belongs_to :movie
end

Добавление ключа - это просто добавление строки кода!

Есть и другие преимущества, которые появятся в долгосрочной перспективе, например, лучшая масштабируемость и скорость.

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

Чтобы прочитать больше, я бы порекомендовал взглянуть на « Почему я думаю, что Mongo для баз данных такой же, как Rails для Frameworks » или этот пост на сайте mongodb. Чтобы получить удовольствие и если вы говорите по-французски, прочтите эту статью, в которой объясняется, как настроить MongoDB с нуля.

Изменить: Я почти забыл рассказать вам об этом railscast по Райан . Это очень интересно и сразу же хочется начать!

Marcgg
источник
Этот железнодорожный выпуск кажется действительно интересным; собираюсь взглянуть на это, надеюсь, я лучше пойму, как это работает.
Гийом Фландр,
5

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

Это также означает, что все, что вы в него бросаете, остается полностью лишенным смысла после того, как вы это сделали.

Некоторые назвали бы это серьезным недостатком, другие - нет.

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

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

Эрвин Смаут
источник
1
Это действительно антиответ. Большинство значений, как их понимает большинство людей, возникает не только из концепций отношений. На самом деле большинству разработчиков приложений сложнее различить смысл в строго нормализованной схеме, чем в хранилище документов.
user1020853 01
1
Смысл, как гласит логика, происходит из предложений. Предложения могут возникать из предикатов со свободными местами, если и когда эти свободные места заменяются фактическими элементами данных. Но эти элементы данных должны происходить из структуры. А если есть структура, значит, есть и схема. Следовательно, если нет схемы, нет никакой структуры, которая могла бы служить для построения предложений, которые затем порождают смысл, кроме как показывать пальцем в воздухе и выдумывать его. Это не против чего-либо и не за что-либо, это простой очевидный факт.
Эрвин Смаут, 01
3
Это только один взгляд на значение, который подходит только для довольно узкого интеллектуального контекста (и он философский, а не логический). Ваш ответ в основном гласит: «Если у вас нет схемы, как у реляционной базы данных, значит, у вас нет смысла». Вряд ли это ответ на первоначальный вопрос «каковы преимущества?» поэтому я называю это антиответом. Это также не совсем верно, если мы не ограничим «значение» этим узким контекстом, из которого вы пришли. Есть много места для «значения» без «устоявшейся схемы».
user1020853 01
1
Так как насчет того, чтобы показать мне, каково ваше «более широкое» представление о «значении», и как оно может существовать без логических предикатов или предложений. Обратите внимание, что в моем комментарии ни разу не упоминалось слово «реляционный». У технологий до реляционных данных были схемы, и поэтому они подходили для вывода «значения». У технологии до создания базы данных были схемы, и поэтому они подходили для вывода «значения». Схема без схемы не имеет схемы (если только «бесплатная» часть не является откровенной ложью) и поэтому не подходит для вывода «значения». ...
Эрвин Смаут 01
1
... Отсутствие схемы заставляет пользователей играть в угадайку. И даже если этим пользователям удастся понять это правильно в 90 или 99% случаев, это все равно просто игра в угадывание.
Эрвин Смаут, 01
3

MongoDB была представлена ​​в еженедельнике FLOSS на этой неделе - http://twit.tv/floss105 База данных, использующая аналогичную концепцию, - это CouchDB, которая была представлена ​​на другом еженедельнике FLOSS: http://twit.tv/floss36

Я думаю, что их стоит послушать в дополнение к ссылкам, предоставленным @marcgg

Патрик
источник
3

Мой опыт работы с Postgres и Mongo после работы с обеими базами данных в моих проектах.

Postgres (СУБД)

Postgres рекомендуется, если ваши будущие приложения имеют сложную схему, которая требует большого количества объединений или все данные имеют отношения, или если у нас есть тяжелая запись. Postgres имеет открытый исходный код, работает быстрее, совместим с ACID и использует меньше памяти на диске, а также обеспечивает хорошую производительность для хранилища JSON и включает полную сериализуемость транзакций с 3 уровнями изоляции транзакций.

Самым большим преимуществом использования Postgres является то, что у нас есть лучшее из обоих миров. Мы можем хранить данные в JSONB с ограничениями, единообразием и скоростью. С другой стороны, мы можем использовать все функции SQL для других типов данных. Базовый движок очень стабилен и хорошо справляется с большим диапазоном объемов данных. Он также работает на выбранном вами оборудовании и операционной системе. Postgres предоставляет возможности NoSQL вместе с полной поддержкой транзакций, храня документы JSON с ограничениями на данные полей.

Общие ограничения для Postgres

Масштабирование Postgres по горизонтали значительно сложнее, но выполнимо.

Операции быстрого чтения не могут быть полностью реализованы с помощью Postgres.

БЕЗ баз данных SQL

Mongo DB (проводной тигр)

MongoDB может превзойти Postgres в измерении «горизонтального масштаба». Хранение JSON - это то, для чего оптимизирован Mongo. Mongo хранит свои данные в двоичном формате BSONb, который (примерно) является просто двоичным представлением надмножества JSON. MongoDB хранит объекты в точности так, как они были разработаны. Согласно MongoDB, для приложений с интенсивной записью, по словам Монго, новый движок (Wired Tiger) дает пользователям до 10-кратного увеличения производительности записи (я должен попробовать это) с 80-процентным сокращением использования хранилища, что помогает снизить затраты на хранилище. , добиться большего использования оборудования.

Общие ограничения MongoDb

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

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

ПрограммистПанда
источник
2

Все дело в компромиссах. MongoDB работает быстро, но не ACID, в нем нет транзакций. В одних случаях он лучше MySQL, в других - хуже.

AABBCCDD
источник
Пожалуйста, просмотрите этот комментарий сейчас. MongoDb 4.0 теперь поддерживает кислотные транзакции.
Анант Симран Сингх
1

Ниже приведены строки, написанные в MongoDB: полное руководство.

Есть несколько веских причин:

  1. Хранение разных типов документов в одной коллекции может стать кошмаром для разработчиков и администраторов. Разработчикам необходимо убедиться, что каждый запрос возвращает документы только определенного типа или что код приложения, выполняющий запрос, может обрабатывать документы различной формы. Если мы запрашиваем сообщения в блоге, очень сложно отсеять документы, содержащие данные об авторах.
  2. Получить список коллекций намного быстрее, чем извлечь список типов в коллекции. Например, если бы у нас был ключ типа в коллекции, в котором говорилось, является ли каждый документ «беглым», «целым» или «коротким» документом, было бы гораздо медленнее найти эти три значения в одной коллекции, чем иметь три отдельные коллекции и запрашивать их имена
  3. Группирование документов одного типа в одну коллекцию позволяет определить местоположение данных. Получение нескольких сообщений в блоге из коллекции, содержащей только сообщения, вероятно, потребует меньшего количества обращений к диску, чем получение тех же сообщений из коллекции, содержащей сообщения и данные об авторах.
  4. Мы начинаем налагать некоторую структуру на наши документы, когда создаем индексы. (Это особенно верно в случае уникальных индексов.) Эти индексы определяются для каждой коллекции. Помещая в одну коллекцию только документы одного типа, мы можем более эффективно индексировать наши коллекции.
Нанхе Кумар
источник
0

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

PhiLho
источник
1
В вашем ответе есть пара заблуждений. Хотя MongoDB не уязвим для SQL-инъекций, в целом он восприимчив к инъекциям. Вы можете указать произвольный Javascript в предложении $ where запроса. Кроме того, в отличие от многих других вариантов NoSQL, MongoDB на самом деле может выполнять довольно сложные запросы.
Эмили
Спасибо за точность. Обратите внимание, что, как я уже сказал, ограничения на реляционные запросы были созданы самим сайтом MongoDB. Если я не понял чего-то еще ...
PhiLho
Кажется весьма вероятным, что они сказали, что MongoDB не подходит для сложных реляционных запросов, но для сложных нереляционных запросов он вполне подходит. Взгляните на mongodb.org/display/DOCS/Advanced+Queries, чтобы узнать о некоторых интересных вещах, которые вы можете сделать.
Эмили
0
  1. MongoDB поддерживает поиск по полям, поиск по регулярным выражениям. Включает в себя определенные пользователем функции сценария Java.
  2. MongoDB можно использовать в качестве файловой системы, используя функции балансировки нагрузки и репликации данных на нескольких машинах для хранения файлов.
user2982063
источник