MongoDB - одна коллекция с использованием индексов

Question

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

Для примера:

Допустит, я занимаюсь разработкой менеджера контактов и у меня есть два типа контакты «лица» и «бизнес». Моя первоначальная мысль заключалась в том, чтобы создать коллекцию, называемую людьми, и вторую коллекцию, называемую бизнесом. Но это было потому, что я использовал для разработки в sql, где да, это было бы уместно, так как столбцы были бы разными для каждой таблицы. Чем больше я начал думать о гибкости документа dbs, тем больше я начал думать: «Мне действительно нужны две коллекции для этого?» Если я просто добавлю поле в каждый документ, называемый «тип контакта» и указав на него, действительно ли мне нужны две коллекции? Поскольку поля/столбцы в каждом документе не обязательно должны быть одинаковыми для всех (например, в sql), каждый документ может иметь свои собственные поля, если у меня есть поле типа документа и индекс в этом поле.

Итак, я принял эту концепцию и начал думать, если мне нужна только одна коллекция для «индивидуумов» и «предприятий», тогда мне даже нужна отдельная коллекция для «Пользователи» или «История контактов» или любые другие данные , Теоретически я не мог построить целое решение в коллекции и просто иметь поле в каждом документе, в котором указаны «тип» и индекс на нем, такие как «Пользователи», «Индивидуальный контакт», «Бизнес-контакты», «История контактов» »и т. д., и если это документ, относящийся к другому документу, я могу индексировать его в поле« родительский ключ/чужой »...

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

Мой вопрос: Является ли это распространенным методом использования разработчиками mongodb? Почему или почему нет? Каковы недостатки, если они есть? Если это широко используемый метод, пожалуйста, также дайте какие-либо положительные результаты для использования этого метода. Спасибо.

Answer 1

MongoDB и NoSQL в целом относятся к де-нормализации данных и сокращению объединений. Это противоречит нормальному мышлению SQL.

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

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

Answer 2

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

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

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

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

Некоторая информация от 10gen о проектировании схемы: http://www.mongodb.org/display/DOCS/Schema+Design

EDIT

Кроме того, Монго имеет ограниченную поддержку транзакций - в виде атомных агрегатов. Когда вы вставляете объект в mongo, весь объект либо вставлен, либо не вставлен. Таким образом, вы являетесь доменом приложения, который требует согласованности между определенными объектами, вы, вероятно, хотите сохранить их в одном документе/коллекции.

Например, рассмотрим приложение, которое требует, чтобы User всегда имеет Name объект (содержащий FirstName, LastName и MiddleInitial). Если User был каким-то образом вставлен без соответствующего Name, данные считаются поврежденными. В СУБД вы должны обернуть транзакцию вокруг операций для вставки User и Name. В Монго мы убеждаемся, что Name находится в том же документе (агрегат) как User для достижения такого же эффекта.

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

Если вы привыкли думать в РСУБД, вы, вероятно, думаете, что все ваши данные всегда должны быть последовательными. Правда в том, что это, вероятно, не совсем так. Эта концепция применения атомных агрегатов к домену была широко распространена сообществом DDD в последнее время. Когда вы внимательно изучаете свой домен, как это делают ваши бизнес-пользователи, границы консистенции должны стать четкими.