Документно-ориентированные базы данных предназначены для замены реляционных баз данных?

Question

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

Однако мне кажется, что он может полностью заменить практически любую реляционную базу данных, которую вы можете иметь, и в большинстве случаев работать лучше, что ошеломляет. Это заставляет меня задать несколько вопросов:

1. Разрабатываются ли документно-ориентированные базы данных для следующего поколения баз данных и полностью заменяют реляционные базы данных?
2. Возможно ли, что в проектах было бы лучше использовать одновременно ориентированную на документы базу данных и реляционную базу данных для различных данных, которые лучше подходят для одной или другой?
3. Если ориентированные на документы базы данных не предназначены для замены реляционных баз данных, то есть ли у кого-нибудь пример структуры базы данных, которая была бы абсолютно лучше в реляционной базе данных (или наоборот)?

Answer 1

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

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

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

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

Да. На самом деле, у меня очень большой производственный веб-сайт, который использует оба. Система была запущена в MySQL, но мы перенесли часть ее в MongoDB, потому что нам нужно хранилище Key-Value, и MySQL просто не очень хорош в поиске одного элемента в записях 150M.

Если ориентированные на документы базы данных не предназначены для замены реляционных баз данных, то есть ли у кого-нибудь пример структуры базы данных, которая была бы абсолютно лучше в реляционной базе данных (или наоборот)?

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

Тем не менее, реляционные базы данных все еще имеют сильные позиции в таких вещах, как отчетность, которая, как правило, основана на множестве.

Честно говоря, я вижу мир, в котором большая часть данных "обрабатывается" базой данных, ориентированной на документы, но где отчеты создаются в реляционной базе данных, которая обновляется заданиями Map-Reduce.

Answer 2

Это действительно вопрос соответствия цели.

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

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

Кроме того, я рекомендую вам следить за блогами Ayende Rahien на эту тему.

http://ayende.com/blog/

Answer 3

@ Сони на месте. Я мог бы добавить, что реляционные базы данных

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

Спросите себя, что вы хотите сделать, и какие качества важны для вас. Вы можете делать все, что связано с программированием в скриптах оболочки. Хотите ли вы?

Answer 4

Я продолжаю задавать один и тот же вопрос, который и привел меня сюда. Я использую как MySQL, так и MongoDB (не в тандеме в настоящее время, хотя это идея). Я должен честно сказать, что я очень рад никогда больше не трогать MySQL. Конечно, есть соответствие "ACID", но сталкивались ли вы когда-нибудь с необходимостью восстанавливать таблицы с MySQL? У вас когда-нибудь была поврежденная база данных? Такое случается. Были ли у вас какие-либо другие проблемы с MySQL? Какие-нибудь блокировки или мертвые замки? Есть проблемы с кластеризацией? Насколько легко было установить и настроить?

MongoDB ... Вы включаете его, и все готово ... Тогда это автошард. Это невероятно просто и невероятно быстро. Так что подумай об этом. Ваше время.

Нет, у них нет JOINs, но это совершенно неверное утверждение, что оно сокращает более 99% потребностей в управлении данными. Я часто сталкиваюсь с оппозицией, когда пытаюсь объяснить MongoDB, люди даже хихикают. Давайте просто посмотрим правде в глаза. Люди не хотят изучать новые вещи, и они думают, что все, что они знают, - это все, что им нужно. Конечно, вы можете использовать MySQL до конца своей жизни и создавать свои веб-сайты. Это работает, мы знаем, что это работает. Мы также знаем, что это не удается. Если этого не произойдет, вы никогда не зададите вопрос, и мы, вероятно, не увидим так много баз данных, ориентированных на документы. Мы знаем, что да, он масштабируется, но задняя боль - масштабировать его.

Также давайте уберем трафик и масштабирование с картинки. Вынуть настройки. Теперь давайте сосредоточимся на использовании. Каков ваш опыт использования MySQL? Насколько хорошо вы работаете с архитектурой MySQL и делаете эффективные запросы? Сколько времени вы проводите, просматривая запросы с помощью EXPLAIN? Сколько времени вы тратите на создание схем? ... Я говорю, возьми это время назад. Лучше провести в другом месте.

Это мои два цента. Я действительно люблю MongoDB и надеюсь никогда не использовать MySQL снова и для типов веб-сайтов, которые я создаю, очень возможно, что мне это не понадобится. Хотя я все еще пытаюсь выяснить, КОГДА я бы хотел использовать MySQL вместо MongoDB, а не когда я МОГУ (посмотрим правде в глаза, он хранит данные, поздравляю, я мог бы также написать тонну файлов XML, но это не очень хорошая идея) , но когда это будет выгодно использовать один или другой. А пока я собираюсь пойти поработать с MongoDB и у меня будет меньше головной боли.

Answer 5

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

1. Базы данных, данные которых лучше представлены с использованием иерархической (древовидной) модели. Это не распространено для баз данных веб-сайтов.
2. Базы данных с огромным объемом данных, такие как базы данных Facebook и Amazon. В этом случае требуется пожертвовать преимуществами реляционной модели.

Answer 6

Пока вам не нужны многообъектные транзакции, MongoDB может быть выгодной заменой RDMBS, особенно в контексте веб-приложения. Скорость, отсутствие схемы и моделирование документов - все это помогает в этой области.

Answer 7

AFAIK, базы данных документов не имеют JOIN. Это в значительной степени ограничитель для> 99% потребностей в управлении данными.

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