Я пропускаю что-то о Документных базах данных?
Я смотрел на повышение перемещения NoSql и сопроводительное повышение популярности документных баз данных как mongodb, ravendb, и других. В то время как существует довольно много вещей о них, что мне нравится, я чувствую, что не понимаю что-то важное.
Скажем, то, что Вы реализовываете приложение хранилища, и Вы хотите сохранить в продуктах базы данных, все из которых имеют единственную, уникальную категорию. В Реляционных базах данных это было бы выполнено при наличии двух таблиц, продукта и таблицы категории, и таблица product будет иметь поле (названный, возможно, "category_id"), который сослался бы на строку в таблице категории, содержащей корректную запись категории. Это обладает несколькими преимуществами, включая неповторение данных.
Это также означает, что при орфографической ошибке названия категории, например, Вы могли бы обновить таблицу категории, и затем это фиксируется, так как это - единственное место, что значение существует.
В документных базах данных, тем не менее, это не то, как это работает. Вы полностью денормализовываете, имея в виду в документе "продуктов", у Вас на самом деле было бы значение, содержащее фактическую строку категории, ведя к большому повторению данных, и ошибки намного более трудно исправить. При размышлении об этом больше, не делает этого, также означают, что выполнение запросов как "дает мне, все продукты с этой категорией" могут вести для заканчиваний, которые не имеют целостности.
Конечно, путь вокруг этого состоит в том, чтобы повторно реализовать целую "category_id" вещь в документной базе данных, но когда я добираюсь до той точки в своих взглядах, я понимаю, что должен просто остаться с реляционными базами данных вместо того, чтобы повторно реализовать их.
Это приводит меня полагать, что я упускаю некоторую ключевую суть о документных базах данных, которая приводит меня вниз этот неправильный путь. Таким образом, я хотел поместить его в переполнение стека, что я пропускаю?
4 ответа
Вы полностью денормализуете, что означает, что в документе «продукты» у вас будет значение, содержащее фактическую строку категории, что приведет к многократному повторению данных [...]
Верно денормализация означает сохранение дополнительных данных. Это также означает меньшее количество коллекций (таблиц в SQL), что приводит к меньшему количеству взаимосвязей между частями данных. Каждый отдельный документ может содержать информацию, которая в противном случае поступила бы из нескольких таблиц SQL.
Теперь, если ваша база данных распределена по нескольким серверам, более эффективно запрашивать один сервер, а не несколько серверов. С денормализованной структурой документных баз данных гораздо более вероятно, что вам потребуется всего лишь запросить один сервер, чтобы получить все необходимые данные . С базой данных SQL есть вероятность, что ваши связанные данные распределены по нескольким серверам, что делает запросы очень неэффективными.
[...] и ошибки исправить гораздо сложнее.
Также верно. Большинство решений NoSQL не гарантируют таких вещей, как ссылочная целостность, которые являются общими для баз данных SQL. В результате ваше приложение отвечает за поддержание отношений между данными. Однако, поскольку количество отношений в базе данных документов очень мало, это не так сложно, как может показаться.
Одним из преимуществ базы данных документов является то, что она не имеет схемы . Вы полностью свободны определять содержание документа в любое время; вы не привязаны к заранее определенному набору таблиц и столбцов, как с базой данных SQL.
Реальный пример
Если вы создаете CMS поверх базы данных SQL, у вас будет либо отдельная таблица для каждого типа контента CMS, либо одна таблица с общими столбцами, в которых вы храните все типы контента. С отдельными таблицами у вас будет много таблиц. Просто подумайте обо всех таблицах соединения, которые вам понадобятся для таких вещей, как теги и комментарии для каждого типа контента . В случае единой общей таблицы ваше приложение отвечает за правильное управление всеми данными. Кроме того, необработанные данные в вашей базе данных трудно обновлять и совершенно бессмысленны за пределами вашего приложения CMS.
С помощью базы данных документов вы можете хранить каждый тип контента CMS в одной коллекции, сохраняя при этом строго определенную структуру внутри каждого документа. Вы также можете хранить все теги и комментарии в документе, что делает извлечение данных очень эффективным . Эта эффективность и гибкость имеет свою цену: ваше приложение более ответственно за управление целостностью данных. С другой стороны, цена масштабирования с помощью базы данных документов намного меньше по сравнению с базой данных SQL.
Совет
Как видите, решения SQL и NoSQL имеют свои преимущества и недостатки. Как уже указывал Дэвид , каждый тип имеет свое применение.Я рекомендую вам проанализировать ваши требования и создать две модели данных, одну для решения SQL и одну для базы данных документов. Затем выберите наиболее подходящее решение, помня о масштабируемости.
Я бы сказал, что вещь номер один, которую вы упускаете из виду (по крайней мере, исходя из содержания сообщения) - это то, что базы данных документов не предназначены для замены реляционных баз данных. Пример, который вы приводите, на самом деле очень хорошо работает в реляционной базе данных. Вероятно, он должен оставаться там. Базы данных документов - это просто еще один инструмент для выполнения задач другим способом, они не подходят для каждой задачи.
Базы данных документов были созданы для решения проблемы, связанной с тем, что (если посмотреть на это с другой стороны), реляционные базы данных не являются лучшим способом решения каждой проблемы. Обе конструкции имеют свое применение, и ни одна из них по своей сути не лучше другой.
Взгляните на примеры использования на сайте MongoDB: http://www.mongodb.org/display/DOCS/Use+Cases
OrientDB, например, поддерживает бессхемный, полносхемный или смешанный режим. В некоторых контекстах вам нужны ограничения, валидация и т.д., но вам нужна гибкость для добавления полей, не затрагивая схему. Это и есть смешанный режим схемы.
Пример:
{ '@rid': 10:3, '@class': 'Customer', '@ver': 3, 'name': 'Jay', 'surname': 'Miner', 'invented': [ 'Amiga' ] }
В этом примере поля "имя" и "фамилия" являются обязательными (путем определения их в схеме), но поле "изобретено" было создано только для этого документа. Ваше приложение не должно знать об этом, но вы можете выполнять запросы к нему:
SELECT FROM Customer WHERE invented IS NOT NULL
Это вернет только документы с полем "invented".
Документ db дает ощущение свободы, когда вы начинаете работу. Вам больше не нужно писать скрипты create table и alter table. Вы просто вставляете детали в основные "записи".
Но через некоторое время вы понимаете, что вы заперты в другом. Становится не так просто объединять или агрегировать данные таким образом, который, по вашему мнению, не был необходим, когда вы хранили данные. Добыча данных/бизнес-аналитика (поиск неизвестного) становится сложнее.
Это означает, что также сложнее проверить, правильно ли ваше приложение сохранило данные в базе данных.
Например, у вас есть две коллекции, в каждой из которых примерно 10000 "записей". Теперь вы хотите узнать, какие идентификаторы присутствуют в "таблице" A, которых нет в "таблице" B.
Тривиально с SQL, гораздо сложнее с MongoDB.
Но мне нравится MongoDB!!!