Рекомендации по индексированию в Azure Cosmos DB для виртуальных ядер MongoDB
Область применения: 
Виртуальные ядра MongoDB
Запрашиваемые поля всегда должны иметь индексы, созданные
Операции чтения на основе предикатов и агрегатов см. в индексе соответствующих фильтров. В отсутствие индексов ядро СУБД выполняет сканирование документов для получения соответствующих документов. Сканирование всегда является дорогостоящим и постепенно дороже, так как объем данных в коллекции растет. Для оптимальной производительности запросов индексы всегда должны создаваться для всех запрашиваемых полей.
Избегайте ненужных индексов и индексирования всех полей по умолчанию
Индексы должны создаваться только для запрашиваемых полей. Индексирование подстановочных знаков следует использовать только в том случае, если шаблоны запросов непредсказуемы, где любое поле в структуре документа может быть частью фильтров запросов.
Совет
Azure Cosmos DB для виртуального ядра MongoDB индексирует только поле _id по умолчанию. Все остальные поля по умолчанию не индексируются. Поля, которые необходимо индексировать, следует спланировать заранее, чтобы максимально повысить производительность запросов, и свести к минимуму влияние на запись из индексирования слишком большого количества полей.
При первом вставке нового документа или обновления или удаления существующего документа каждый из указанных полей в индексе также обновляется. Если политика индексирования содержит большое количество полей (или все поля в документе), дополнительные ресурсы используются сервером при обновлении соответствующих индексов. При выполнении в масштабе только запрашиваемые поля должны индексироваться, а все остальные поля, не используемые в предикаатах запросов, должны оставаться исключенными из индекса.
Создание необходимых индексов перед приемом данных
Для оптимальной производительности необходимо создать индексы перед загрузкой данных. Все записи, обновления и удаления документов будут синхронно обновлять соответствующие индексы. Если индексы создаются после приема данных, для индексирования исторических данных используются дополнительные ресурсы сервера. В зависимости от размера исторических данных эта операция занимает много времени и влияет на производительность чтения и записи устойчивого состояния.
Примечание.
Для сценариев, когда необходимо добавить изменения шаблонов чтения и индексы, следует включить фоновое индексирование, которое можно сделать с помощью запроса в службу поддержки.
Для нескольких индексов, созданных в исторических данных, проблема с неблокированием команд createIndex для каждого поля
Не всегда можно заранее планировать все шаблоны запросов, особенно по мере развития требований приложения. Изменение потребностей приложения неизбежно требует добавления полей в индекс в кластере с большим количеством исторических данных.
В таких сценариях каждая команда createIndex должна быть выдана асинхронно, не ожидая ответа от сервера.
Примечание.
По умолчанию виртуальные ядра Azure Cosmos DB для MongoDB реагируют на операцию createIndex только после того, как индекс полностью основан на исторических данных. В зависимости от размера кластера и объема приема данных может потребоваться время и отображаться, как будто сервер не отвечает на команду createIndex.
Если команды createIndex выдаются через оболочку Mongo, используйте ctrl+C, чтобы прервать команду, чтобы прекратить ожидание ответа и выдать следующий набор операций.
Примечание.
С помощью ctrl+ C для прерывания команды createIndex после ее выдачи не завершается операция сборки индекса на сервере. Она просто останавливает оболочку от ожидания ответа от сервера, а сервер асинхронно продолжает создавать индекс по существующим документам.
Создание составных индексов для запросов с предикатами в нескольких полях
Составные индексы должны использоваться в следующих сценариях:
- Запросы с фильтрами в нескольких полях
- Запросы с фильтрами в нескольких полях и с одним или несколькими полями, отсортированных по возрастанию или убыванию
Рассмотрим следующий документ в базе данных "космической работы" и коллекции "сотрудник"
{
"firstName": "Steve",
"lastName": "Smith",
"companyName": "Microsoft",
"division": "Azure",
"subDivision": "Data & AI",
"timeInOrgInYears": 7
}
Рассмотрим следующий запрос, чтобы найти всех сотрудников с фамилией "Смит" с организацией более 5 лет:
db.employee.find({"lastName": "Smith", "timeInOrgInYears": {"$gt": 5}})
Составной индекс как lastName, так и timeInOrgInYears оптимизирует этот запрос:
use cosmicworks;
db.employee.createIndex({"lastName" : 1, "timeInOrgInYears" : 1})
Отслеживание состояния операции createIndex
При добавлении индексов и индексировании исторических данных ход выполнения операции сборки индекса можно отслеживать с помощью db.currentOp().
Рассмотрим этот пример, чтобы отслеживать ход индексирования базы данных "космические работы".
use cosmicworks;
db.currentOp()
При выполнении операции createIndex ответ выглядит следующим образом:
{
"inprog": [
{
"shard": "defaultShard",
"active": true,
"type": "op",
"opid": "30000451493:1719209762286363",
"op_prefix": 30000451493,
"currentOpTime": "2024-06-24T06:16:02.000Z",
"secs_running": 0,
"command": { "aggregate": "" },
"op": "command",
"waitingForLock": false
},
{
"shard": "defaultShard",
"active": true,
"type": "op",
"opid": "30000451876:1719209638351743",
"op_prefix": 30000451876,
"currentOpTime": "2024-06-24T06:13:58.000Z",
"secs_running": 124,
"command": { "createIndexes": "" },
"op": "workerCommand",
"waitingForLock": false,
"progress": {},
"msg": ""
}
],
"ok": 1
}
Включение ключей больших индексов по умолчанию
Даже если документы не содержат ключей, имеющих большое количество символов или документы не содержат несколько уровней вложения, указывая большие ключи индекса, гарантирует, что эти сценарии рассматриваются.
Рассмотрим этот sampe, чтобы включить большие ключи индекса в коллекции "large_index_coll" в базе данных "cosmicworks".
use cosmicworks;
db.runCommand(
{
"createIndexes": "large_index_coll",
"indexes": [
{
"key": { "ikey": 1 },
"name": "ikey_1",
"enableLargeIndexKeys": true
}
]
})
Приоритетная сборка индекса над новыми операциями записи с помощью параметра блокировки
В сценариях, в которых необходимо создать индекс перед загрузкой данных, параметр блокировки должен использоваться для блокировки входящих записей до завершения сборки индекса.
Параметр { "blocking": true } особенно полезен в служебных службах миграции, где индексы создаются в пустых коллекциях до начала записи данных.
Рассмотрим пример параметра блокировки для создания индекса в коллекции employee в базе данных "cosmicworks":
use cosmicworks;
db.runCommand({
createIndexes: "employee",
indexes: [{"key":{"name":1}, "name":"name_1"}],
blocking: true
})
Связанный контент
Ознакомьтесь с индексированием текста, что позволяет эффективно искать и запрашивать текстовые данные.