MongoDB может иметь документы, которые включают массивы других документов. Это решает многие случаи, когда у вас будут отношения в реляционных базах данных.
Когда счет-фактура имеет несколько позиций, вы не должны помещать эти позиции в отдельную коллекцию. Вы бы вставили их как массив.
Это заставляет меня задаться вопросом о реальных примерах из жизни: когда использовать NoSQL, а когда нет?
Существует множество различных баз данных NoSQL, каждая из которых разработана с учетом разных сценариев использования. Но вы отметили этот вопрос как MongoDB, поэтому я предполагаю, что вы имеете в виду, в частности, MongoDB.
MongoDB имеет два основных преимущества перед реляционными базами данных.
Во-первых, хорошо масштабируется.
Когда база данных слишком медленная или слишком большая, вы можете легко добавить дополнительные серверы, создав кластер или набор реплик из нескольких сегментов. Это не так хорошо работает с большинством реляционных баз данных.
Во-вторых, он позволяет использовать разнородные данные.
Представьте себе, например, базу данных продуктов в магазине компьютерной техники. Какими свойствами обладают товары? У всех товаров есть цена и продавец. Но у процессоров есть тактовая частота, у жестких дисков и микросхем оперативной памяти есть емкость (и эти возможности несопоставимы), у мониторов есть разрешение и так далее. Как бы вы спроектировали это в реляционной базе данных? Вы должны либо создать очень длинную таблицу productID-свойство-значение, либо создать очень широкую и разреженную таблицу продуктов со всеми свойствами, которые вы можете себе представить, но большинство из них NULL для большинства продуктов. Оба решения не совсем элегантны. Но MongoDB может решить эту проблему намного лучше, потому что он позволяет каждому документу в коллекции иметь различный набор свойств.
Чего он не может?
Поскольку это довольно новая технология, о ней не так много литературы. Программная экосистема вокруг него тоже не очень хороша. Инструменты, которые вы можете получить для реляционных баз данных, часто бывают гораздо более блестящими.
Есть также некоторые варианты использования, для которых MongoDB не подходит.
- MongoDB не выполняет СОЕДИНЕНИЙ. Когда ваши данные очень реляционны и денормализация будет контрпродуктивной, это может быть плохим выбором для вашего продукта. Но вы можете взглянуть на графические базы данных, такие как Neo4j, которые больше ориентированы на отношения, чем на реляционные базы данных. Обновление 2016: MongoDB 3.2 теперь имеет элементарную поддержку JOIN с этап агрегирования $ lookup, но он по-прежнему очень ограничен в функциональности по сравнению с реляционными и графическими базами данных.
- MongoDB не выполняет транзакции. По крайней мере, не сложные транзакции. Определенные действия, которые влияют только на один документ, гарантированно являются атомарными, но как только вы затрагиваете более одного документа, вы не можете гарантировать, что никакой другой запрос не произойдет между ними и не обнаружит несогласованное состояние.
- MongoDB плохо подходит для создания специальных отчетов. Его возможности для интеллектуального анализа данных сильно ограничены. Довольно новые функции агрегирования помогают, и MapReduce может также решить некоторые удивительно сложные проблемы, когда вы научитесь использовать его с умом, но SQL обычно имеет лучшие инструменты для подобных вещей.
Путем денормализации данных вы сможете решить все те же проблемы, что и реляционные базы данных ... Но есть правила о том, как нормализовать данные с помощью реляционных баз данных. Есть ли правила, которые можно использовать, чтобы помочь им денормализовать данные для использования решения NoSQL?
Реляционные базы данных существуют около 40 лет. Их теория - хорошо изученная тема в компьютерных науках. Есть целые библиотеки книг, написанных о стоящей за ними теории. К настоящему времени есть готовое решение для каждого мыслимого случая.
Но с другой стороны, базы данных NoSQL - это довольно новая технология. Мы все еще ищем лучшие практики. Наиболее частый совет: «Используйте свою голову. Подумайте, какие запросы выполняются чаще всего, и оптимизируйте для них схему данных».
Есть ли примеры того, когда вы можете рассмотреть возможность использования решения NoSQL параллельно с реляционной базой данных?
По возможности я бы не советовал использовать в одном продукте две разные технологии баз данных:
- Любой, кто обслуживает и поддерживает продукт, должен быть знаком с обеими технологиями.
- Устранение неполадок становится намного сложнее
- Системным администраторам необходимо поддерживать и обновлять дополнительную базу данных.
- У вас есть дополнительная точка отказа, которая может привести к простою
Я бы рекомендовал смешивать технологии баз данных только тогда, когда выполнение ваших требований становится не просто трудным, но и физически невозможным. В противном случае сделайте свой выбор и оставайтесь с ним.
person
Philipp
schedule
21.10.2013
