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

Question

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

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

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

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

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

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

Answer 1

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

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

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

http://try.mongodb.org/

Answer 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 от Райан . Это очень интересно и хочется сразу начать!

Answer 3

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

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

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

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

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

Answer 4

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

Postgres (RDBMS)

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

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

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

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

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

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

Mongo DB (Wired Tiger)

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

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

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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

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

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

Answer 8

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

Answer 9

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