120 коллекций mongodb против единой коллекции - какая из них эффективнее?

Я новичок в mongodb, и я столкнулся с дилеммой относительно моего проекта схемы БД:

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

Теперь я знаю, что многие такие вопросы заданы, но я считаю, что мое дело отличается по двум причинам:

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

Итак, мой вопрос: может ли 120 коллекций улучшить производительность запросов? Является ли это полезной оптимизацией в моем случае?

Или я должен просто пойти для одиночной коллекции + sharding?

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

Спасибо заранее!

------- Изменить:

Спасибо за отличные ответы.

На самом деле 120 коллекций - это только собственный лимит, он не очень оптимален:

Данные в сборниках связаны с веб-издателями. Их могут быть миллионы (любой веб-сайт может присоединиться).

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

Итак, я придумал идею фиксированного количества коллекций, чтобы как-то распределить данные. Например: коллекция "A_XX" проведет XX связанные с платформой данные для издателей, чьи имена начинаются с "A".. и т.д. Мы будем поддерживать только некоторые из этих платформ, поэтому 120 коллекций должны быть более чем достаточно.

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

Что вы думаете об этом? Есть ли лучшее решение?

Извините за то, что я не был достаточно конкретным в моем первоначальном вопросе.

Заранее спасибо

ОТВЕТЫ

Ответ 1

Одиночная сборка

Отредактированная версия вопроса делает реальное требование более ясным: у вас есть коллекция, которая может потенциально сильно расти и вам нужен подход к разделению данных. Лимит искусственного сбора - ваша собственная планируемая схема разбиения.

В этом случае, я думаю, вам лучше использовать одну коллекцию и воспользоваться функцией MongoDB auto-sharding для распространения данных и нагрузку на несколько серверов по мере необходимости. Несколько коллекций по-прежнему являются действительным подходом, но излишне усложняют ваш код приложения и развертывание по сравнению с использованием основных функций MongoDB. Предполагая, что вы выберите хороший ключ осколка, ваши данные будут автоматически сбалансированы по вашим осколкам.

Вы не можете сразу окунуться; вы можете отложить решение до тех пор, пока не увидите, что ваша рабочая нагрузка требует большего количества шкалы писем (но знание опции там, когда вам это нужно). У вас есть другие варианты, прежде чем принимать решение об обструкции, например, модернизировать ваши серверы (в частности, диски и память), чтобы лучше поддерживать вашу рабочую нагрузку. И наоборот, вы не хотите ждать, пока ваша система будет раздавлена ​​рабочей нагрузкой до того, как она появится, поэтому вам обязательно нужно следить за ростом. Я бы предложил использовать бесплатную службу мониторинга MongoDB (MMS), предоставленную 10gen.

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

Несколько баз данных значительно повысят административные издержки и, вероятно, будут чрезмерны и, возможно, вредны для вашего использования. Хранение выделяется на уровне базы данных, поэтому 120 баз данных будут потреблять гораздо больше места, чем одна база данных с 120 коллекциями.

Исправлено количество коллекций (исходный ответ)

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

ПРИМЕЧАНИЕ. Приведенные ниже соображения по дизайну все еще применяются, но поскольку вопрос был обновлен, чтобы уточнить, что несколько коллекций являются попыткой схемы разбиения, то одинарная коллекция будет более простой.

Мотивы для использования отдельных коллекций:

  • Ваши документы для одной большой коллекции, вероятно, должны включать некоторые признаки подтипа коллекции, которые могут потребоваться добавить к нескольким индексам и могут значительно увеличить размеры индекса. С отдельными коллекциями подтип уже неявчен в пространстве имен коллекции.

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

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

  • В настоящее время MongoDB 2.4 (и 2.2) имеет гранулярность блокировки записи на уровне базы данных. На практике это не оказалось проблемой для подавляющего большинства случаев использования, однако несколько коллекций позволят вам легче перемещать коллекции высокой активности в отдельные базы данных, если это необходимо.

  • В дополнение к предыдущему пункту.. если у вас есть данные в отдельных сборниках, они смогут использовать преимущества будущих улучшений в блокировке на уровне коллекции (см. SERVER-1240 в отслеживателе проблем MongoDB Jira).

Ответ 2

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

Так что да, вы могли бы пойти на 120 коллекций легко, однако вы на самом деле ничего не получите из-за: https://jira.mongodb.org/browse/SERVER-1240, не являющегося (в ближайшее время).

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

По моему личному мнению, использование единой коллекции проще во всем.