Пределы количества коллекций в базах данных

Можно ли сказать, есть ли какие-либо практические ограничения для количества коллекций в mongodb? Они пишут здесь http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections:

Как правило, наличие большого количества коллекций не имеет значительных производительности и очень хорошей производительности.

Но по какой-то причине mongodb устанавливает ограничение 24000 для количества пространств имен в базе данных, похоже, что это может быть увеличено, но мне интересно, почему у него есть предел в конфигурации по умолчанию, если наличие большого количества коллекций в базе данных не вызывает любое нарушение производительности?

Означает ли это, что это жизнеспособное решение иметь практически неограниченное количество коллекций в одной базе данных, например, иметь один набор данных одной учетной записи в базе данных для многоуровневого приложения, например, сотни тысяч коллекций в база данных? Если это жизнеспособное решение имеет очень большое количество коллекций для базы данных для evey tenent, какие выгоды от него, например, имеют документы каждого арендатора в одной коллекции? Большое вам спасибо за ответы.

Ответ 1

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

Но по какой-то причине mongodb устанавливает ограничение 24000 для количества пространств имен в базе данных,

Это просто настройка по умолчанию. Да, есть настройка по умолчанию.

На странице пределов он говорит, что ограничение 24000 является лимитом (http://docs.mongodb.org/manual/reference/limits/#Number%20of%20Namespaces), как будто нет возможности расширить это, но есть.

Однако существует максимальный предел того, насколько велик файл пространства имен (http://docs.mongodb.org/manual/reference/limits/#Size%20of%20Namespace%20File), который составляет 2 ГБ. Это дает вам примерно 3 миллиона пространств имен для игры в большинстве случаев, что довольно впечатляет, и я не уверен, что многие люди быстро ударят по этому пределу.

Вы можете изменить значение по умолчанию, чтобы выйти выше 16 МБ, используя параметр nssize либо в конфигурации (http://docs.mongodb.org/manual/reference/configuration-options/#nssize), либо во время выполнения манипулируя командой, используемой для запуска MongoDB (http://docs.mongodb.org/manual/reference/mongod/#cmdoption-mongod--nssize).

Нет никакой реальной причины, почему MongoDB по умолчанию использует 16MB для своей nssize, насколько я знаю, я никогда не слышал о девизе "не беспокоить пользователя с каждой отдельной деталью", поэтому я не покупаю этот.

Я думаю, на мой взгляд, главная причина, по которой MongoDB скрывает это, потому что, хотя в документации указано:

Отдельные коллекции очень важны для пакетной обработки с высокой пропускной способностью.

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

Ответ 2

Немного фона:

Каждый раз, когда mongo создает базу данных, он создает для него файл пространства имен (db.ns). В пространстве имен (или в коллекции, которое вы хотите назвать) есть метаданные о коллекции. По умолчанию файл пространства имен имеет размер 16 МБ, хотя вы можете увеличить размер вручную. Метаданные для каждой коллекции составляют 648 байтов + некоторые служебные байты. Разделите это на 16 МБ, и вы получите приблизительно 24000 пространств имен на базу данных. Вы можете запустить mongo, указав большой файл пространства имен, и это позволит вам создавать больше коллекций для каждой базы данных.

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

Ответ 3

Больше ограничений!

Как указывали другие ответы - это определяется размером файла пространства имен. Раньше это было проблемой, потому что у нее был предел по умолчанию 16 МБ и максимальный 2 ГБ. Однако с выпуском MongoDB 3.0 и механизма хранения WiredTiger, похоже, этот предел был удален. WiredTiger кажется лучше почти всеми способами, поэтому я не вижу причин, по которым кто-либо может использовать старый движок, кроме устаревших причин поддержки. На сайте:

Для механизма хранения MMAPv1 файлы пространства имен могут быть не больше 2047 мегабайт.

По умолчанию файлы пространства имен составляют 16 мегабайт. Вы можете настроить размер с помощью параметра nsSize.

Механизм хранения WiredTiger не подпадает под это ограничение.

http://docs.mongodb.org/manual/reference/limits/

Ответ 4

Как отмечают другие, размер пространства имен по умолчанию составляет 16 МБ, и вы можете получить около 24000 записей пространства имен. Фактически мой 64-разрядный экземпляр в Ubuntu превысил 23684, используя файл пространства имен по умолчанию 16 МБ.

Одна важная вещь, которая не упоминается в FAQ, заключается в том, что индексы также используют слоты пространства имен.

Вы можете подсчитать записи пространства имен с помощью:

db.system.namespaces.count()

И это также интересно посмотреть на то, что там:

db.system.namespaces.find()

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

Ответ 5

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

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

Возможно, вам стоит рассмотреть хранилище, которое будет соответствовать форме данных? Например, у Riak есть неограниченное количество "ведер" (без теоретического максимума), которые вы можете получить в своем приложении. Одно ведро на счет отлично справляется, но вы жертвуете некоторой вероятностью, идя в этом направлении.

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

Ответ 6

Похоже, что для поддержания коллекций существуют огромные накладные расходы. Я только что уменьшил базу данных, в которой было около 1.5 миллионов документов в 11000 коллекциях, с одним и тем же количеством документов в около 300 коллекций; это уменьшило размер базы данных с 8 ГБ до 1 ГБ. Я не знаком с внутренней работой MongoDB, поэтому это может быть очевидным, но я думаю, что в этом контексте стоит отметить.