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

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

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

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

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

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

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

Ответ 1

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

Модель данных на основе документов. Базовая единица хранения аналогична JSON, словарям Python, хэшам Ruby и т.д. Это богатая структура данных, способная хранить массивы и другие документы. Это означает, что вы можете часто представлять в едином объекте конструкцию, которая требует, чтобы несколько таблиц должным образом отображались в реляционном db. Это особенно полезно, если ваши данные неизменяемы.
Глубокая способность запроса. MongoDB поддерживает динамические запросы в документах, используя язык запросов на основе документов, который почти такой же мощный, как SQL.
Никаких миграций схемы. Поскольку MongoDB не является схемой, ваш код определяет вашу схему.
Ясный путь к горизонтальной масштабируемости.

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

http://try.mongodb.org/

Ответ 2

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

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

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 Ryan. Это очень интересно и заставляет вас сразу начать!

Ответ 3

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

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

Ответ 4

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

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

Некоторые будут обозначать, что грубый недостаток, некоторые другие не будут.

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

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

Ответ 5

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

Ответ 6

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

Postgres (СУБД)

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

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

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

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

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

НЕТ баз данных SQL

Mongo DB (Wired Tiger)

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

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

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

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

Ответ 7

Bellow Lines, написанные в MongoDB: окончательное руководство.

Существует несколько веских причин:

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

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

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

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

Ответ 8

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

Ответ 9

MongoDB поддерживает поиск по полям, поиск регулярных выражений. Включает пользовательские функции java script.
MongoDB может использоваться как файловая система, используя преимущества балансировки нагрузки и функции репликации данных на нескольких компьютерах для хранения файлов.