Подтвердить что ты не робот

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

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

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

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

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

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

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

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

Ответ 2

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

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

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

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

http://ayende.com/blog/

Ответ 3

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

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

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

Ответ 4

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

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

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

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

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

Ответ 5

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

Ответ 6

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

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

Ответ 7

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

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