Должны ли быть созданы индексы для небольших коллекций mongo определенного размера?

Question

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

User{ 
String name; 
String phoneNumber; 
String address; 
String dob; 
Integer noOfCars; 
} 

Из этих полей, я хотел бы назвать указательным и PHONENUMBER.

Создает ли индекс для таких небольших коллекций целесообразным? Не зависит ли это решение от размера сбора? Это зависит от количества индексов, которые я хочу создать?

Answer 1

Думаю, что вам нужно. Сохранение настойчивости вряд ли является проблемой. Также индекс небольшой коллекции также мал. Это также зависит от объема запросов. Если имеется большой объем запросов, то даже небольшое улучшение отдельных запросов будет совокупно с огромным увеличением производительности.

Answer 2

Это не имеет значения. Я просто попробовал это на выборке, содержащей 384 записи. Согласно explain(), сканирование индекса заняло 0 мс, в то время как сканирование коллекции первого заняло 2 мс - каждое последующее сканирование коллекции заняло 0 мс.

Это решение зависит от размера коллекции?

Да, идея индекса заключается в том, что он добавляет затраты на создание и обновление данных, которые амортизируются путем ускорения запросов. В частности, простой список имеет асимптотическую производительность вставки O (1) и время поиска O (N), тогда как B-Tree имеет O (log n) для обоих, то есть мы принимаем более медленные вставки, потому что мы предполагаем, что мы читаем более часто, чем мы пишем, или данные настолько велики, что даже несколько O (N) считываний будут влиять на производительность, т. е. если N >> log N.

Всего лишь несколько сотен элементов, все это не потому что разница между log n и n мала, а потому, что более сложный служебный ресурс сложного алгоритма (т. е. постоянный фактор, который скрыт через Landau-Notation, потому что он в значительной степени зависит от реализации) играет в той же лиге. То же самое относится и к вашему коду: нет смысла ставить 200 элементов в хэш-таблицу, итерация списка может быть даже быстрее, поскольку она позволяет избежать разветвления.

Если документы огромны, сканирование коллекции придется пресекать больше данных (вместо того, чтобы просто смотреть на индекс).

Answer 3

Создает ли индекс для таких небольших коллекций целесообразным?

Возможно, это мнение, поскольку коллекция настолько мала, и БД может иметь оптимизацию для таких небольших коллекций. Мое мнение было бы сделать это, но есть плюсы и минусы.

con: Повышенная сложность системы. Это похоже на больше LOC, у вас больше ошибок, которые могут возникнуть у вас.

pro: Будущее доказательство коллекции должно увеличить использование или увеличить размер коллекции.

Это решение зависит от размера коллекции?

Да, так оно и есть.И, запрещая любые оптимизации БД, которые могут возникать в такой небольшой коллекции, это также зависит от использования.

Зависит ли это от числа индексов, которые я хочу создать?

Другие индексы увеличивают время записи, но это необходимо будет протестировать для конкретной настройки. Ничто не сравнится с реальными испытаниями, поскольку в игре много факторов. Я знаю, что в предыдущих проектах мы использовали TokuMX для MongoDB и видели потрясающую запись perofrmance ... 2 минуты с Toko против 12 минут для обычного mongo при записи 500k записей с 19 индексами.