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

Question

Кто-нибудь может сказать, есть ли практические ограничения на количество коллекций в mongodb?Они пишут здесь https://docs.mongodb.com/manual/core/data-model-operations/#large-number-of-collections:

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

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

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

Answer 1

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

Но по какой-то причине mongodb setограничение 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 реализует 16 МБпо умолчанию для nssize, насколько мне известно, я никогда не слышал о девизе «не беспокоить пользователя каждой мелочью», поэтому я его не покупаю.

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

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

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

Answer 2

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

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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

db.system.namespaces.count()

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

db.system.namespaces.find()

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

Answer 5

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

Answer 6

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

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

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

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