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

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

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

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

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

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

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

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

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

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

http://try.mongodb.org/

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

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

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

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

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

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

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

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

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

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

Мой опыт работы с 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 были оптимизированы в новых версиях и выпусках, которые в значительной степени преодолели предыдущие ограничения».

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

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

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

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

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

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