Я что-то упускаю из базы данных документов?

Question

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

Допустим, вы реализуете приложение магазина и хотите хранить в базе данных продукты, которые имеют единственную уникальную категорию. В реляционных базах данных это может быть достигнуто за счет наличия двух таблиц, продукта и таблицы категорий, а таблица продуктов будет иметь поле (называемое, возможно, "category_id"), которое будет ссылаться на строку в таблице категорий, содержащую правильную запись категории. Это имеет несколько преимуществ, в том числе неповторение данных.

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

Однако в базах документов это не так. Вы полностью денормализуетесь, то есть в документе «products» вы фактически получите значение, содержащее фактическую строку категории, что приведет к большому количеству повторений данных, а ошибки гораздо сложнее исправить. Если подумать об этом больше, разве это не означает, что выполнение запросов типа «дай мне все продукты этой категории» может привести к результату, который не имеет целостности.

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

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

Answer 1

Вы полностью денормализуетесь, то есть в документе "products" у вас действительно будет значение, содержащее фактическую строку категории, что приведет к большому количеству повторений данных [...]

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

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

[...] и ошибки гораздо сложнее исправить.

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

Одним из преимуществ базы данных документов является то, что она без схемы .Вы можете свободно определять содержимое документа всегда;вы не привязаны к заранее определенному набору таблиц и столбцов, как с базой данных SQL.

Реальный пример

Если вы строите CMS поверх базы данных SQLу вас будет либо отдельная таблица для каждого типа контента CMS, либо отдельная таблица с общими столбцами, в которой вы будете хранить все типы контента.С отдельными таблицами у вас будет много таблиц. Просто подумайте обо всех таблицах объединения, которые вам понадобятся для таких вещей, как теги и комментарии для каждого типа контента .С одной общей таблицей ваше приложение отвечает за правильное управление всеми данными.Кроме того, необработанные данные в вашей базе данных трудно обновлять и совершенно бессмысленно вне приложения CMS.

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

Совет

Как видите, решения как на SQL, так и на NoSQL имеют свои преимущества инедостатки.Как Дэвид уже указывал , каждый тип имеет свое применение.Я рекомендую вам проанализировать ваши требования и создать две модели данных: одну для решения SQL и одну для базы данных документов.Затем выберите наиболее подходящее решение с учетом масштабируемости.

Answer 2

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

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

Посмотрите варианты использования на веб-сайте MongoDB: http://www.mongodb.org/display/DOCS/Use+Cases

Answer 3

Документ дБ дает ощущение свободы при запуске. Вам больше не нужно писать сценарии создания таблиц и изменения таблиц. Вы просто встраиваете детали в основные «записи».

Но через некоторое время вы понимаете, что вы заперты по-другому. Становится все труднее объединять или агрегировать данные так, как вы не думали, что это было необходимо при хранении данных. Интеллектуальный анализ данных / бизнес-аналитика (поиск неизвестного) становится сложнее.

Это означает, что также сложнее проверить, правильно ли ваше приложение сохранило данные в БД.

Например, у вас есть две коллекции с примерно 10000 «записями». Теперь вы хотите узнать, какие идентификаторы присутствуют в «таблице» A, а какие нет в «таблице» B.

Тривиально с SQL, намного сложнее с MongoDB.

Но мне нравится MongoDB !!

Answer 4

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

Пример:

{'@rid': 10: 3, '@class': 'Customer', '@ver': 3,'name': 'Jay', 'фамилия': 'Шахтер', 'изобретен': ['Amiga']}

В этом примере поля "имя" и "фамилия" являются обязательными (путем определения их в схеме), но поле «изобретено» было создано только для этого документа.Все ваше приложение не должно знать об этом, но вы можете выполнять запросы к нему:

ВЫБРАТЬ ИЗ ПОТРЕБИТЕЛЯ, ГДЕ ИЗОБРЕТЕНО НЕ НУЛЬ

Оно вернет толькодокументы с полем "изобретено".