Есть документ-ориентированных баз данных для реляционных баз данных?
в последнее время я немного работаю с MongoDB и я должен сказать, что мне очень нравится. Однако это совершенно другой тип базы данных, тогда я использую. Я заметил, что это определенно лучше для определенных типов данных, однако для сильно нормализованных баз данных это может быть не лучший выбор.
Мне кажется, однако, что он может полностью заменить практически любую реляционную базу данных, которую вы можете иметь, и в большинстве случаев работать лучше, что уму непостижимо. Это заставляет меня задать несколько вопросов:--3-->
- разрабатываются ли базы данных, ориентированные на документы, для следующего поколения баз данных и в основном полностью заменяют реляционные базы данных?
- возможно ли, что проекты будут лучше использовать как ориентированную на документ базу данных, так и реляционную базу данных бок о бок для различных данных, которые лучше подходят для одного или другого?
- если не подразумеваются базы данных, ориентированные на документы чтобы заменить реляционные базы данных, у кого-нибудь есть пример структуры базы данных, которая была бы абсолютно лучше в реляционной базе данных (или наоборот)?
7 ответов
разработаны ли базы данных, ориентированные на документы, для следующего поколения баз данных и в основном полностью заменяют реляционные базы данных?
нет. Базы данных, ориентированные на документы (например, MongoDB), очень хороши в типе задач, которые мы обычно видим на современных веб-сайтах (быстрый поиск отдельных элементов или небольших наборов элементов).
но они делают некоторые большие компромиссы с реляционными системами. Без таких вещей, как кислотное соответствие, они не сможет заменить некоторые РСУБД. И если вы посмотрите на такие системы, как MongoDB, отсутствие кислотного соответствия является большой причиной того, что это так быстро.
возможно ли, что проектам было бы лучше использовать как ориентированную на документ базу данных, так и реляционную базу данных бок о бок для различных данных, которые лучше подходят для одного или другого?
да. На самом деле, я запускаю очень большой производственный веб-сайт, который использует оба. Система была запущена в MySQL, но мы перенесли часть его в MongoDB, b/c нам нужно хранилище ключей, и MySQL просто не очень хорош в поиске одного элемента в записях 150M.
Если ориентированные на документы базы данных не предназначены для замены реляционных баз данных, то есть ли у кого-нибудь есть пример структуры базы данных, которая была бы абсолютно лучше в реляционной базе данных (или наоборот)?
базы данных, ориентированные на документы большие храня данные которые легко содержится в" ключ-значение "и простые, линейные отношения" родитель-ребенок". Простые примеры здесь такие вещи, как блоги и Вики.
однако, реляционных баз данных все еще имеют сильную ногу на таких вещах, как отчетность, которая, как правило, "основана на наборе".
честно говоря, я вижу мир, где большинство данных "обрабатывается" документально-ориентированной базой данных, но где отчетность выполняется в реляционной базе данных, которая обновляется заданиями map-reduce.
Это действительно вопрос пригодности для цели.
Если вы хотите иметь возможность объединить некоторые таблицы вместе и вернуть отфильтрованный набор результатов, вы можете сделать это только с реляционной базой данных. Если вы хотите иметь умопомрачительную производительность и иметь невероятные объемы данных, именно тогда колонка-семейство или документ-ориентированные базы данных приходят в свои собственные.
Это классический компромисс. Реляционные базы данных предлагают вам целый набор функций, который поставляется с стоимость исполнения. Если вы не можете присоединиться, индексировать, сканировать или выполнять весь другой список функций, вы удаляете необходимость просмотра всех данных, что дает вам производительность и распространение, необходимые для хруста серьезных данных.
кроме того, я рекомендую вам следить за блогами Ayende Rahien по этой теме.
@Sohnee на месте. Я мог бы добавить, что реляционные базы данных
- отлично подходит для поиска информации в неожиданные сочетания, даже если это иногда приводит к плохой идеей обширных отчетов о срочных производственных систем, а не на отдельном хранилище данных.
- зрелая технология где вы можете легко найти штат и хорошо испытанные решения к любому количеству проблем (включая ограничения реляционного модель,а также несовершенная реализация, которая является SQL).
спросите себя, что вы хотите сделать, и что качества важны для вас. Вы можете делать все, что связано с программированием в сценариях shell. А ты хочешь?
Я продолжаю задавать тот же вопрос, что и привело меня сюда. Я использую MySQL и MongoDB (не в тандеме в настоящее время, хотя это идея). Я должен честно сказать, что я очень рад никогда больше не прикасаться к MySQL. Конечно, есть" кислотное " соответствие, но вы когда-нибудь сталкивались с необходимостью ремонта ваших таблиц с MySQL? У вас когда-нибудь была поврежденная база данных? Случается. У вас когда-нибудь были какие-либо другие проблемы с MySQL? Какие-то проблемы с замками или мертвые замки? Есть проблемы с кластеризацией? Как легко было его настроить и настроить?
MongoDB...Включаешь - и готово....Тогда это автошардинг. Это невероятно просто и невероятно быстро. Так что подумай об этом. Твое время.
нет, у них нет соединений, но это совершенно неверное утверждение, чтобы сказать, что он скидывает более 99% потребностей в управлении данными. Я часто получаю оппозицию, когда пытаюсь объяснить MongoDB, люди даже хихикают. Давай посмотрим правде в глаза. Люди не хотят учиться чему-то новому и думают: что они знают все, что им нужно. Конечно, вы можете уйти, используя MySQL всю оставшуюся жизнь и построить свои веб-сайты. Это работает, мы знаем, что это работает. Мы также знаем, что он терпит неудачу. Если бы это было не так, вы бы никогда не задали вопрос, и мы, вероятно, не увидели бы так много баз данных, ориентированных на документы. Мы знаем, что да, он масштабируется, но это боль в тылу, чтобы масштабировать его.
также давайте исключим трафик и масштабирование из изображения. Уберите установку. Теперь давайте сосредоточимся на использовании. Каков ваш опыт, когда использование MySQL? Насколько Вы хороши в архитектуре MySQL и создании эффективных запросов? Сколько времени вы тратите на просмотр запросов с EXPLAIN? Сколько времени вы тратите на создание схем? ... Я говорю, верни это время назад. Лучше потратить в другом месте.
Это мои два цента. Я действительно люблю MongoDB и надеюсь никогда больше не использовать MySQL, и для типа веб-сайтов, которые я создаю, очень возможно, что мне это не понадобится. Хотя я все еще пытаюсь выяснить, когда я хотел бы использовать MySQL над MongoDB, не когда я могу (давайте посмотрим правде в глаза, он хранит данные, поздравляю, я мог бы написать тонну XML-файлов, но это не очень хорошая идея), но когда было бы полезно использовать тот или другой. А пока, я пойду делать свою работу с MongoDB и иметь меньше головной боли.
пока вам не нужны транзакции с несколькими объектами, MongoDB может быть выгодной заменой для RDMBS, особенно в контексте веб-приложения. Скорость, schemalessness и моделирования документ все полезные этого домена.
на мой взгляд, документоориентированные базы данных хороши только для
- базы данных, данные которых лучше представлены с использованием иерархической (древовидной) модели. Это не характерно для баз данных веб-сайтов.
- базы данных с огромным количеством данных, таких как базы данных Facebook и Amazon. В этом случае необходимо пожертвовать преимуществами реляционной модели.
AFAIK, базы данных документов не имеют соединения. Это в значительной степени шоу-стопор для > 99% потребностей в управлении данными.
Как указывает Мэтью Флашен в комментариях, даже на рабочем столе, базы данных, такие как SQLite, вводят семантику SQL в области, которые традиционно использовали форматы файлов или XML.