Ориентированные на документ базы данных предназначены для замены реляционных баз данных?
Недавно я работал немного с MongoDB, и я должен сказать, что мне действительно нравится он. Однако это - совершенно другой тип базы данных затем, я используюсь. Я заметил, что это совершенно определенно лучше для определенных типов данных, однако для в большой степени нормализованных баз данных, это не мог бы быть лучший выбор.
Кажется мне однако, что это может полностью занять место примерно любой реляционной базы данных, которую Вы можете иметь и в большинстве случаев выполнить лучше, который является испугом ума. Это приводит меня задавать несколько вопросов:
- Ориентированные на документ базы данных разрабатывают, чтобы быть следующим поколением баз данных и в основном заменить реляционные базы данных полностью?
- Действительно ли возможно, что проекты были бы более обеспеченным использованием и ориентированная на документ база данных и реляционная база данных рядом для различных данных, которые лучше подходят для одного или другого?
- Если бы ориентированный на документ на базы данных не предназначены для замены реляционных баз данных, то у кого-либо есть пример структуры базы данных, которая абсолютно была бы более обеспечена в реляционной базе данных (или наоборот)?
6 ответов
Разработаны ли документно-ориентированные базы данных, чтобы стать следующим поколением баз данных и в основном полностью заменить реляционные базы данных?
Нет. Документно-ориентированные базы данных (например, MongoDB) очень хорошо справляются с задачами, которые мы обычно видим на современных веб-сайтах (быстрый поиск отдельных элементов или небольших наборов элементов).
Но они идут на большие уступки с реляционными системами. Без таких вещей, как соответствие ACID, они не смогут заменить определенные СУБД. И если вы посмотрите на такие системы, как MongoDB, отсутствие соответствия ACID - большая причина, по которой это так быстро.
Возможно ли, что в проектах было бы лучше использовать и документно-ориентированную базу данных, и реляционную базу данных бок о бок для различных данных, которые лучше подходят для одного или другого?
Да. Фактически, у меня есть очень большой производственный веб-сайт, который использует и то, и другое. Система была запущена в MySQL, но мы перенесли ее часть в MongoDB, т.к. нам нужно хранилище ключей и значений, а MySQL просто не очень хорош в поиске одного элемента из 150 миллионов записей.
Если документно-ориентированные базы данных не предназначены для замены реляционных баз данных, то есть ли у кого-нибудь пример структуры базы данных, которая, безусловно, была бы лучше в реляционной базе данных (или наоборот)?
Документно-ориентированные базы данных отлично подходят для хранения данных, которые легко содержатся в отношениях «ключ-значение» и простых линейных отношениях «родитель-потомок». Простыми примерами здесь являются блоги и вики.
Однако реляционные базы данных по-прежнему имеют сильную опору в таких вещах, как отчетность, которая, как правило, «основана на наборах».
Честно говоря, я вижу мир, в котором большая часть данных «обрабатывается» документно-ориентированной базой данных, но где отчеты создаются в реляционной базе данных, которая обновляется заданиями Map-reduce.
Это действительно вопрос соответствия назначению.
Если вы хотите иметь возможность объединить несколько таблиц и вернуть отфильтрованный набор результатов, вы можете сделать это только с реляционной базой данных. Если вам нужна потрясающая производительность и невероятные объемы данных, тогда вам на помощь придут базы данных, ориентированные на столбцы или документы.
Это классический компромисс. Реляционные базы данных предлагают вам целый набор функций, за что приходится платить за производительность. Если вы не смогли присоединиться, проиндексировать, просканировать или выполнить целый другой список функций, вы избавитесь от необходимости иметь представление обо ВСЕХ данных, что даст вам производительность и распределение, необходимые для обработки серьезных данных.
Также я рекомендую вам следить за блогами Айенде Рахиен по этой теме.
@Sohnee на высоте. Я мог бы добавить, что реляционные базы данных
- отлично подходят для извлечения информации в неожиданных комбинациях - даже если это иногда приводит к плохой идее создания обширных отчетов в оперативных производственных системах, а не в отдельном хранилище данных.
- - это зрелая технология, с помощью которой вы можете легко найти персонал и хорошо протестированные решения для любого количества проблем (включая ограничения реляционной модели, а также несовершенную реализацию SQL).
Спросите себя, чем вы хотите заниматься и какие качества важны для вас. Вы можете делать все, что связано с программированием, в сценариях оболочки. Ты хочешь?
Если вам не нужны многообъектные транзакции, MongoDB может быть подходящей заменой RDMBS, особенно в контексте веб-приложения. Скорость, отсутствие схем и моделирование документов - все это полезно в этой области.
AFAIK, базы данных документов не имеют JOIN. Это в значительной степени препятствие для> 99% потребностей в управлении данными.
Как отмечает Мэтью Флашен в комментариях, даже на рабочем столе такие базы данных, как SQLite, вводят семантику SQL в области, которые традиционно использовали собственные форматы файлов или XML.
Я продолжаю задавать один и тот же вопрос, что и привело меня сюда. Я использую и MySQL, и MongoDB (в настоящее время не в тандеме, хотя это идея). Должен честно сказать, что я очень рад никогда больше не прикасаться к MySQL. Конечно, есть соответствие "ACID", но сталкивались ли вы когда-нибудь с необходимостью восстановления таблиц в MySQL? У вас когда-нибудь была поврежденная база данных? Такое случается. Были ли у вас другие проблемы с MySQL? Какие-нибудь споры о блокировках или мертвые блокировки? Какие-нибудь проблемы с кластеризацией? Насколько легко было устанавливать и настраивать?
MongoDB... Вы включаете ее, и все готово.... Затем происходит автозагрузка. Это невероятно просто, и это также невероятно быстро. Так что подумайте об этом. Ваше время.
Нет, у них нет JOINов, но говорить о том, что они исключают более 99% потребностей в управлении данными - совершенно неверное утверждение. Я часто получаю возражения, когда пытаюсь объяснить MongoDB, люди даже усмехаются. Давайте посмотрим правде в глаза. Люди не хотят изучать новые вещи и думают, что то, что они знают, - это все, что им нужно. Конечно, вы можете всю жизнь обходиться MySQL и создавать свои веб-сайты. Это работает, мы знаем, что это работает. Мы также знаем, что это не работает. Если бы это было не так, вы бы никогда не задавали этот вопрос, и мы бы, вероятно, не увидели так много документо-ориентированных баз данных. Мы знаем, что да, она масштабируется, но масштабировать ее - та еще морока.
Также давайте исключим из картины трафик и масштабирование. Уберем настройку. Теперь давайте сосредоточимся на использовании. Каков ваш опыт использования MySQL? Насколько хорошо вы разбираетесь в архитектуре MySQL и составлении эффективных запросов? Сколько времени вы тратите на просмотр запросов с помощью EXPLAIN? Сколько времени вы тратите на создание диаграмм схем? ... Я говорю, верните это время назад. Его лучше потратить в другом месте".
Это мои два цента. Я действительно люблю MongoDB и надеюсь никогда больше не использовать MySQL, а для того типа веб-сайтов, которые я создаю, вполне возможно, что мне это и не понадобится. Хотя я все еще пытаюсь понять, КОГДА я захочу использовать MySQL вместо MongoDB, не когда я МОГУ (давайте посмотрим правде в глаза, он хранит данные, поздравляю, я могу написать тонну XML файлов, но это не очень хорошая идея), а когда будет ВЫГОДНЕЕ использовать один или другой. А пока я собираюсь делать свою работу с MongoDB и иметь меньше головной боли.