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

Question

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

Например:

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

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

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

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

Answer 1

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

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

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

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

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

EDIT

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

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

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

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

Answer 2

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

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

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