Существуют ли какие-либо инструменты для оценки размера индекса в MongoDB?

Я ищу инструмент, чтобы получить достойную оценку того, насколько большим будет индекс MongoDB, на основе нескольких сигналов, таких как:

  • Сколько документов в моей коллекции
  • Размер проиндексированного поля (полей)
  • Размер _id, который я использую, если не ObjectId
  • Гео/негео

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

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

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


person jpredham    schedule 22.12.2011    source источник
comment
Возможно, стоит совместить ваш инструмент (чтобы временно заполнить пробел) с запросом на встроенный инструмент от команды MongoDB.   -  person Derek Litz    schedule 23.12.2011
comment
Вы действительно написали инструмент для этого?   -  person Stennie    schedule 23.08.2012
comment
Я сделал, однако результаты были менее чем удовлетворительными. При тестировании с реальными данными с существующими индексами для сравнения мой инструмент предсказал, что размеры индексов будут чуть меньше, чем в два раза, по сравнению с фактическими размерами. Я выясняю, является ли это ошибкой в ​​моем коде или формула просто очень грубая. Обновлю здесь, когда узнаю больше.   -  person jpredham    schedule 31.08.2012
comment
@Stennie Стенни, возможно, я возвращаю старую тему. Но есть ли официальный всеобъемлющий способ определить это?   -  person Naman    schedule 04.02.2021
comment
Ответ @ Naman Tyler от 2011 года описывает исходный механизм хранения MMAP около MongoDB 2.0, но эта формула определенно не применима к современным версиям MongoDB. WiredTiger, механизм хранения по умолчанию в MongoDB 3.2+, использует сжатие префикса индекса, поэтому размеры индекса будут варьироваться в зависимости от распределения значений ключа. Существует также множество типов индексов и параметров, которые могут повлиять на размер. Лучшим подходом для разумной оценки будет использование эмпирической оценки с репрезентативными тестовыми данными для вашего прогнозируемого роста, поэтому я бы поставил ваши голоса за ответ Остати от 2014 года.   -  person Stennie    schedule 05.02.2021
comment
@Stennie, спасибо за участие ... фактическая коллекция для моего варианта использования может содержать 500million документов и выше. Как вы думаете, сколько данных мне будет достаточно, чтобы вывести корреляцию с точки зрения фактических размеров индекса, которые я мог бы получить? например будет ли мне достаточно 1000 документов, чтобы создать тот же индекс в рабочей среде, а затем выполнить математику, умножив размер на 500,000?   -  person Naman    schedule 07.02.2021
comment
@Naman 1000 индексированных значений слишком малы, чтобы их можно было использовать для экстраполяции отношения для любых более крупных групп населения. В зависимости от проиндексированных значений и распределения (которое влияет на сжатие префикса), размер файла небольших индексов, вероятно, будет преобладать в распределении блоков (например, 16 КБ), которые не являются значительными для индексов разумного размера. Я бы использовал более крупные значения, такие как 100 000, 500 000, 1 м, чтобы экстраполировать тенденцию, но есть и другие факторы (например, рабочая нагрузка), которые будут влиять на соотношение с течением времени.   -  person Stennie    schedule 13.02.2021
comment
@Naman Я подозреваю, что вас беспокоит то, как индексы повлияют на ваш рабочий набор, за которым мы можем следить в соответствующем обсуждении, которое вы начали на форумах сообщества MongoDB: Оценить правильный объем cacheSize для wiredTiger по индексу дополнение.   -  person Stennie    schedule 13.02.2021
comment
@ Стенни Правда. Это то, что меня сейчас беспокоит. Более чем счастлив поделиться более подробной информацией там. Спасибо за ваши ответы здесь, я понимаю, что выборка должна быть сделана на значительном числе и что выполнение на меньшем размере данных будет намного точнее. Я попытался сопоставить это как приближение, чтобы определить размер на данный момент. Вопрос на форуме, продолжение впереди.   -  person Naman    schedule 13.02.2021


Ответы (4)


Я только что разговаривал с некоторыми инженерами 10gen, и у меня нет инструмента, но вы можете сделать обратный расчет, основанный на этой формуле:

2 * [ n * ( 18 bytes overhead + avg size of indexed field + 5 or so bytes of conversion fudge factor ) ]

Где n — количество имеющихся у вас документов.

Накладные расходы и заполнение преобразования зависят от монго, но 2x происходит из-за того, что структура данных b-дерева заполнена примерно наполовину (но с выделением 100% пространства, которое потребуется для полного дерева) в худшем случае.

Я бы объяснил больше, но в данный момент я сам изучаю это. Эта презентация будет содержать более подробную информацию: http://www.10gen.com/presentations/mongosp-2011/mongodb-internals

person Tyler Brock    schedule 22.12.2011
comment
Тогда он может создать онлайн-калькулятор :-) - person Sergio Tulentsev; 23.12.2011
comment
Извините, нужно снова открыть этот вопрос. Вычисляя средний размер поля из репрезентативного числа документов и подставляя его в приведенное уравнение, я получаю размер индекса примерно в два раза больше фактического значения. Теория здесь имеет для меня смысл, но на практике, основываясь на том, что в любом случае сообщает оболочка mongo, это неверно. - person jpredham; 04.09.2012
comment
Сколько документов, достаточно ли большая выборка? Приведите пример. Фактический размер, очевидно, может варьироваться в зависимости от множества различных факторов. - person Tyler Brock; 05.09.2012
comment
Мне просто пришло в голову, что мы, вероятно, выделяем пространство для максимального размера индексируемого поля в сегменте индекса 4 КБ, даже если на практике вы используете примерно половину этого размера, поэтому фактический размер индекса примерно вдвое. - person Tyler Brock; 14.11.2012
comment
Привет, @TylerBrock, не могли бы вы рассказать мне, что означает avg size of indexed field? Если мой документ выглядит так { _id : 1, favoriteFood : "cheese" }, а я проиндексировал favoriteFood, будет ли средний размер проиндексированного поля равным 12, поскольку в нем 12 символов? - person Kevin Meredith; 03.10.2013
comment
Привет @Кевин. В вашем примере средний размер проиндексированного поля будет ближе к 6 байтам, так как поле будет сыром, а запись индекса будет выглядеть как сыр -> ‹местоположение на диске›. - person Tyler Brock; 03.10.2013

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

db.collection.stats()

Подробнее здесь: http://docs.mongodb.org/manual/reference/method/db.collection.stats/#db.collection.stats

person Minh Nguyen    schedule 09.05.2013

Другой способ подсчета — добавить около 1000 документов в каждую коллекцию, другими словами, построить мелкомасштабную модель того, что вы собираетесь получить в продакшене, создать индексы или что у вас есть, и рассчитать окончательные цифры на основе db.collection.stats() средний.

Изменить (из комментарий):

Ответ Тайлера описывает оригинальный механизм хранения MMAP около MongoDB 2.0, но эта формула определенно не применима к современным версиям MongoDB. WiredTiger, механизм хранения по умолчанию в MongoDB 3.2+, использует сжатие префикса индекса, поэтому размеры индекса будут варьироваться в зависимости от распределения значений ключа. Существует также множество типов индексов и параметров, которые могут повлиять на размер. Лучшим подходом для разумной оценки будет использование эмпирической оценки с репрезентативными тестовыми данными для вашего прогнозируемого роста.

person Ostati    schedule 06.08.2014

Лучший вариант — протестировать в непроизводственной среде!

Вставьте 1000 документов и проверьте размеры указателя, вставьте 100000 документов и проверьте размеры указателя и так далее.

Простой способ проверить в цикле все размеры общего индекса коллекций:

  var y=0;db.adminCommand("listDatabases").databases.forEach(function(d){mdb=db.getSiblingDB(d.name);mdb.getCollectionNames().forEach(function(c){s=mdb[c].stats(1024*1024).totalIndexSize;y=y+s;print("db.Collection:"+d.name+"."+c+" totalIndexSize: "+s+" MB"); })});print("============================");print("Instance totalIndexSize: "+y+" MB");
person R2D2    schedule 04.02.2021
comment
безусловно, способ грубой силы, но не масштабируемый, когда я размышляю о добавлении одного или нескольких индексов в существующую базу данных, содержащую миллионы документов. кстати, я мог бы просто выполнить статистику, чтобы извлечь правильную информацию, как только я настроил бы те же самые документы на постановке. - person Naman; 05.02.2021
comment
Кроме того, при очень интенсивных обновлениях и удалениях выделенное пространство для документов и индексов может сильно различаться... - person R2D2; 07.02.2021