Рекомендации по индексированию в Azure DocumentDB

Запрашиваемые поля всегда должны иметь индексы, созданные

Операции чтения на основе предикатов и агрегатов см. в индексе соответствующих фильтров. В отсутствие индексов ядро СУБД выполняет сканирование документов для получения соответствующих документов. Сканирование всегда является дорогостоящим и постепенно дороже, так как объем данных в коллекции растет. Для оптимальной производительности запросов индексы всегда должны создаваться для всех запрашиваемых полей.

Избегайте ненужных индексов и индексирования всех полей по умолчанию

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

Подсказка

Azure DocumentDB индексирует только поле _id по умолчанию. Все остальные поля по умолчанию не индексируются. Поля, которые необходимо индексировать, следует спланировать заранее, чтобы максимально повысить производительность запросов, и свести к минимуму влияние на запись из индексирования слишком большого количества полей.

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

Стратегия индексирования для эффективного приема данных

Для миграции больших рабочих нагрузок в Azure DocumentDB рекомендуется создать индексы после загрузки данных для эффективного выполнения. Это значительно снижает затраты на запись, сводит к минимуму потребление ресурсов и ускоряет прием данных. Обслуживание индексов во время массовой загрузки может замедлить вставки, так как каждую операцию записи необходимо обновить все применимые индексы.

Для нескольких индексов, созданных на основе исторических данных, выполняйте команды createIndex без блокировки для каждого поля.

Не всегда можно заранее планировать все шаблоны запросов, особенно по мере развития требований приложения. Изменение потребностей приложения неизбежно требует добавления полей в индекс в кластере с большим количеством исторических данных.

В таких сценариях каждая команда createIndex должна быть выдана асинхронно, не ожидая ответа от сервера.

Замечание

По умолчанию Azure DocumentDB реагирует на операцию createIndex только после того, как индекс полностью основан на исторических данных. В зависимости от размера кластера и объема обработанных данных на это может потребоваться время, и может показаться, что сервер не отвечает на команду createIndex.

Если команды createIndex выдаются через оболочку Mongo, используйте ctrl+C, чтобы прервать команду, чтобы прекратить ожидание ответа и выдать следующий набор операций.

Замечание

С помощью ctrl+ C для прерывания команды createIndex после ее выдачи не завершается операция сборки индекса на сервере. Она просто останавливает оболочку от ожидания ответа от сервера, а сервер асинхронно продолжает создавать индекс по существующим документам.

Создание составных индексов для запросов с предикатами в нескольких полях

Составные индексы должны использоваться в следующих сценариях:

• Запросы с фильтрами в нескольких полях
• Запросы с фильтрами в нескольких полях и с одним или несколькими полями, отсортированных по возрастанию или убыванию

Рассмотрим следующий документ в базе данных "cosmicworks" и коллекции "employee".

{
    "firstName": "Steve",
    "lastName": "Smith",
    "companyName": "Microsoft",
    "division": "Azure",
    "subDivision": "Data & AI",
    "timeInOrgInYears": 7
}

Рассмотрим следующий запрос, чтобы найти всех сотрудников с фамилией "Смит" с организацией более пяти лет:

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
}

Включение ключей больших индексов по умолчанию

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

Рассмотрим этот пример, чтобы включить большие ключи индекса в коллекции "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
})

Связанный контент

Ознакомьтесь с индексированием текста, что позволяет эффективно искать и запрашивать текстовые данные.

Следующий шаг

Создание веб-приложения Node.js