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

Один Запачкал Коллекции

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

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

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

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

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

фиксированное количество коллекций (оригинал ответ)

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

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

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

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

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

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

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

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