Что такое индексы в Mongodb?

Question

[source2003]

Подскажите пожалуйста, что такое индексы в mongodb, что происходит, когда мы их объявляем, почему поиск с сортировкой после этого работает быстрее? Можно ли объявлять много индексов в коллекции?

Answer 1

[Евгений Вольф]

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

Тут про индексы PostgreSQL, но аналогичным же образом, индексы работают во всех БД, с которыми приходилось работать мне.

После того, как поймете общее назначение индексов, можно будет легко найти интересующую Вас информацию по конкретному типу индексов в конкретной БД.

что происходит, когда мы их объявляем

Происходит чтение коллекции и построения индекса. Обычно, в физическом виде, это файл (или несколько файлов) на жестком диске.

Можно ли объявлять много индексов в коллекции?

Можно, но чем больше индексов - тем больше данные будут занимать на диске.

В идеале, под индекс попадают те данные, с которыми Вы работаете непосредственно, например, "логин" пользователя в таблице/коллекции пользователей, т.к. именно по нему происходит поиск. Все остальные данные, за пределами индекса, например, имя_пользователя, пароль, его телефон и т.д. - просто прилагаются "до кучи", в виде не индексированных данных, т.к. по ним либо не осуществляется поиск, либо, осуществляется довольно редко.

Answer 2

[askhat]

Индексы в Монге — тоже что и вдругих БД — упорядоченное поле.

Почему по ним проще искать? Возьмите две колоды карт, в одной пусть карты идут масть к масти по порядку, а другую растасуйте. Возьмите секундомер и попросите двух друзей найти даму треф, каждый в своей колоде. Результатами поделитесь в комментариях.

Много индексов конечно вам никто не запретит, сначала даже кажется что это самое логичное. Но потом вы заметите, что при удалении/добавлении элементов в коллекции, надо перестраивать индексы, а это довольно ресурсоёмкая операция. Так что индексы нужны только там, где вы действительно часто ищете.

Comments

[source2003]

Почему нужно будет перестраивать индексы, для оптимизации скорости?
Как упорядочиваются поля? Документы в коллекции не меняются местами?

[askhat]

Имеется столбик:
Г
Д
Е
В
А

Имеется индекс:
А
В
Г
Д
Е

Вы решили добавить Б, теперь столбик выглядит так:
Г
Д
Е
В
А
Б <- новый элемент идёт в конец коллекции

Индекс в свою очередь становится таким:
А
Б <- новый элемент встаёт на своё место по порядку индексации
В
Г
Д
Е

[source2003]

Askhat Bikmetov: то есть индексы никак не влияют на расположение документов в БД? Индексы хранятся на жестком дисксе и занимают отдельное пространство? То есть, например, мы имеем коллекцию с документами {a: b}, поле a не индексировано и занимает эта коллекция на диске 100мб, то при создании индекса по полю a, на жестком диксе будет использовано еще 100мб?

[askhat]

Нет, ещё 100мб использовано не будет

[source2003]

Askhat Bikmetov: а индексы где тогда хранятся? Поля сортируются и где-то надо хранить отсортированные документы, в самой коллекции же ничего не меняется.

[askhat]

source2003: считайте коллекции и индексы, двумя разными представлениями одних тех же данных. В коллекции порядок тот который выбрали вы, например хронологический, а в индексе порядок по убыванию/возрастанию значения.

[lega]

Askhat Bikmetov:
> Нет, ещё 100мб использовано не будет

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

> а в индексе порядок по убыванию/возрастанию значения.

Индексы бывают разные, например hash table/инвертированый индекс и текстовый хранят не по порядку. И вообще там не порядок по убыванию а дерево.

Но цель одна - быстрый поиск значения/объекта.

[askhat]

lega:
1.
> и занимает эта коллекция на диске 100мб — @source2003
> Нет, ещё 100мб использовано не будет — @askhat
> The index stores the value of a specific field or set of fields, ordered by the value of the field. — https://docs.mongodb.com/manual/indexes
коллекция, индекс

2.
Для типа данных String, используется скалярный индекс — индес по порядку возрастания/убывания.
Для типа Text используется B-tree, вот только индексом это является с натяжкой — скорее специальная структура данных оптимизированная для поиска.
Hash Indexes используется как часть стратегии построения индексов для сегментированых (sharded) данных, что выходит далеко за рамки поставленного вопроса.

Я прав или я прав?

[lega]

Askhat Bikmetov:
> Я прав или я прав?

Вообще, все не верно.

Вы переведите выдраный кусок из доки, он добавляет подтверждения к моим словам.
Тут первые строки: https://docs.mongodb.com/v3.2/tutorial/ensure-inde...
- индекс читается с диска. Т.е. Индекс занимает место.

Так же одно и то же поле может использоваться в разных индексах, значит одно и то же поле будет храниться в самом документе и копии в каждом индексе. А если вы удалите все индексы то, значения остануться только в документе. Можете поэксперементировать на базе и посмотреть как измениться использование диска (индексами и данными, а не резервированное место).

> Для типа данных String,
> Для типа Text используется B-tree
Данные String и Text - это одно и тоже, https://docs.mongodb.com/v3.0/reference/bson-types...
В спецификации вообще нет типа данных text.

Есть индекс text, (текстовый индекс), основаный на инвертированном индексе.

> скалярный индекс
нету такого, там для остальных полей используется модификация от btree.

> Hash Indexes
из вашей же ссылки: MongoDB provides a hashed index type, which indexes the hash of the value of a field.

Это не хеш индекс, а хешированное значение положенное в обычный индекс. Монга не предоставляет хеш индекс как индекс для использования.
Сам же хеш индекс используется в 99% ПО.