ограничения количества коллекций в базах данных
может ли кто-нибудь сказать, есть ли какие-либо практические ограничения для количества коллекций в mongodb? Они пишут здесь http://www.mongodb.org/display/DOCS/Using+в+большой+номер+в+коллекции:
Как правило, наличие большого количества коллекций не имеет значительных исполнения наказания, и результаты очень хорошие показатели.
но по какой-то причине mongodb установил предел 24000 для количества пространств имен в базе данных, похоже, что он может быть увеличенным, но я задаюсь вопросом, почему он имеет некоторый предел в конфигурации по умолчанию, если наличие многих коллекций в базе данных не вызывает никакого штрафа за производительность?
означает ли это, что это жизнеспособное решение иметь практически неограниченное количество коллекций в одной базе данных, например, иметь одну коллекцию данных одной учетной записи в базе данных для приложения multitenant, имея, например, сотни тысяч коллекций в базе данных? Если это жизнеспособное решение чтобы иметь очень большое количество коллекций для базы данных для каждого арендатора, каковы преимущества этого, например, по сравнению с наличием документов каждого арендатора в одной коллекции? Большое спасибо за ваши ответы.
6 ответов
этот ответ опоздал, однако другие ответы кажутся немного...слабые с точки зрения надежности и фактической информации, поэтому я попытаюсь исправить это немного.
но по какой-то причине 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 предназначен для, считается (довольно часто) плохой практикой для крупномасштабных веб-сайтов; как такие коллекции 12K обычно считаются чем-то, что люди никогда не будут и никогда не должны выяснять.
немного истории:
каждый раз, когда mongo создает базу данных, он создает пространство имен (db.ns) файл для него. Файл пространства имен (или коллекций, как вы можете его назвать) содержит метаданные о коллекции. По умолчанию размер файла пространства имен составляет 16 МБ, хотя его можно увеличить вручную. Метаданные для каждой коллекции составляют 648 байт + некоторые служебные байты. Разделите это на 16 МБ, и вы получите примерно 24000 пространств имен для каждой базы данных. Вы можете начать mongo указание большего файла пространства имен, что позволит создавать больше коллекций для каждой базы данных.
идея любой конфигурации по умолчанию заключается в том, чтобы не беспокоить пользователя каждой деталью (и настраиваемой ручкой) и выбрать тот, который обычно работает для большинства людей. Кроме того, жизнеспособность идет рука об руку с лучшими/хорошими практиками дизайна. Как сказал Крис, рассмотрите форму ваших данных и примите соответствующее решение.
Больше Никаких Ограничений!
Как указано в других ответах - это определяется размером файла пространства имен. Это было ранее проблемой, потому что у него было ограничение по умолчанию 16mb и максимум 2gb. Однако с выпуском MongoDB 3.0 и движка хранения WiredTiger, похоже, что этот предел был удален. WiredTiger кажется лучше почти во всех отношениях, поэтому я не вижу причин для кого-либо использовать старый двигатель, за исключением причин поддержки наследия. От сайт:
для механизма хранения MMAPv1 файлы пространства имен могут быть не больше 2047 мегабайт.
по умолчанию файлы пространства имен составляют 16 мегабайт. Вы можете настроить размер с помощью опции nsSize.
двигатель хранения WiredTiger не подлежит этому ограничению.
Как упоминают другие, размер пространства имен по умолчанию составляет 16 МБ, и вы можете получить около 24000 записей пространства имен. На самом деле мой 64-битный экземпляр в Ubuntu превысил 23684, используя файл пространства имен по умолчанию 16MB.
одна важная вещь, которая не упоминается в FAQ, заключается в том, что индексы также используют слоты пространства имен.
вы можете подсчитать записи пространства имен с помощью:
db.system.namespaces.count()
и также интересно на самом деле взглянуть на то, что находится в там:
db.system.namespaces.find()
Установите свой предел выше, чем вы думаете, что вам нужно, потому что после создания базы данных файл пространства имен не может быть расширен (насколько я понимаю - если есть способ, пожалуйста, скажите мне!!!).
практически, я никогда не сталкивался с максимумом. Но я определенно никогда не выходил за пределы 24 000 коллекций. Я почти уверен, что никогда не попадал больше 200, кроме как когда я тестировал производительность. Я должен признать, я думаю, что это звучит как ужасный хаос, иметь столько коллекций в одной базе данных, а не группировать как данные в своих собственных коллекциях.
учитывать форму ваших данных и бизнес-правил. Если ваши данные должны быть заложены таким образом, вы должны иметь данные, разделенные на разные логические группы для вашего многопользовательского приложения, тогда вам, вероятно, следует рассмотреть другие хранилища данных. Потому что, хотя Монго велик, тот факт, что они вообще ограничивают количество коллекций, говорит мне, что они знают, что есть какой-то теоретический предел, где достигается производительность.
Возможно, вам следует рассмотреть хранилище, которое будет соответствовать форме данных? РИАК, например, имеет неограниченное количество " ведер "(без теоретический максимум), который вы можете иметь в своем приложении. Одно ведро на учетную запись вполне выполнимо, но вы жертвуете некоторой запрашиваемостью, идя в этом направлении.
в противном случае вы можете захотеть следовать более реляционной модели группировки, как с like. На мой взгляд, Mongo ощущается как промежуточная точка между реляционными базами данных и хранилищами ключей. Это означает, что его легче концептуализировать, исходя из мира реляционных баз данных.
там, кажется, огромные накладные расходы на поддержание коллекций. Я только что сократил базу данных, в которой было около 1.5 mio документов в 11000 коллекциях, до одного с таким же количеством документов примерно в 300 коллекциях; это уменьшило размер базы данных с 8 ГБ до 1 ГБ. Я не знаком с внутренней работой MongoDB, поэтому это может быть очевидно, но я подумал, что стоит отметить в этом контексте.