Indexing policy in Azure Cosmos DB (Политики индексации в Azure Cosmos DB)

ОБЛАСТЬ ПРИМЕНЕНИЯ: NoSQL

В Azure Cosmos DB каждый контейнер имеет политику индексирования, определяющую, как должны индексироваться элементы контейнера. Политика индексирования по умолчанию, задаваемая для только что созданных контейнеров, индексирует каждое свойство каждого элемента и применяет диапазонные индексы для любых строк или чисел. Это позволяет получить оптимальную производительность запросов без необходимости заблаговременно заботиться об индексировании и управлении индексами.

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

Режим индексирования

База данных Azure Cosmos DB поддерживает два режима индексирования:

• Согласованный: индекс обновляется синхронно при создании, обновлении или удалении элементов. Это означает, что согласованность запросов чтения будет настроена для учетной записи.
• Нет. Индексирование в контейнере отключено. Этот режим обычно используется, если контейнер используется в качестве чистого хранилища значений ключей без необходимости в дополнительных индексах. Его также можно использовать для повышения производительности групповых операций. После выполнения групповых операций в режиме индексирования можно установить значение "Согласованность", а затем отслеживать его с помощью параметра IndexTransformationProgress до завершения.

По умолчанию политика индексирования устанавливается в значение automatic. Это осуществляется путем установки в политике индексирования для свойства automatic значения true. Задание этого свойства позволяет true Azure Cosmos DB автоматически индексировать элементы по мере записи.

Размер индексов

В базе данных Azure Cosmos DB общий использованный объем хранилища зависит от размера данных и размера индекса. Ниже приведены некоторые функции размера индекса:

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

Включение и исключение путей к свойствам

В пользовательской политике индексации могут указываться пути к свойствам, которые явно включены в индексирование или исключены из него. Оптимизируя количество индексируемых путей, можно значительно сократить задержку и расходы ЕЗ операций записи. Эти пути определяются методом, описанным в разделе "Общие сведения об индексировании", со следующими дополнениями:

• путь, ведущий к скалярному значению (строке или числу), заканчивается на /?
• к элементам массива обращение происходит с помощью нотации /[] (а не /0, /1 т. д.)
• для сопоставления с любыми элементами, расположенными ниже узла, можно использовать подстановочный знак /*

Снова выполните:

    {
        "locations": [
            { "country": "Germany", "city": "Berlin" },
            { "country": "France", "city": "Paris" }
        ],
        "headquarters": { "country": "Belgium", "employees": 250 },
        "exports": [
            { "city": "Moscow" },
            { "city": "Athens" }
        ]
    }

• headquarters — путь employees — /headquarters/employees/?

• locations — путь country — /locations/[]/country/?

• путь к любому элементу в разделе headquarters — /headquarters/*

Например, можно включить путь /headquarters/employees/?. Этот путь обеспечит индексирование свойства, но не будет индексировать employees дополнительный вложенный JSON в этом свойстве.

Стратегия включения / исключения

Любая политика индексирования должна включать корневой путь /*, который либо включается в индексирование, либо исключается из него.

• Включите корневой путь для выборочного исключения путей, которые не нужно индексировать. Этот подход рекомендуется, так как позволяет Azure Cosmos DB заранее индексировать любое новое свойство, которое может быть добавлено в модель.

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

• Для путей с обычными символами, включающими алфавитно-цифровые символы и символ _ (подчеркивание), вам не нужно экранировать строку пути двойными кавычками (например, "/Путь/?"). Для путей с другими специальными знаками необходимо экранировать строку пути, заключенную в двойные кавычки (например, "/"path-abc"/?"). Если в строке пути предполагается наличие специальных символов, можно экранировать каждый путь для безопасности. Функционально, это не имеет никакого значения, если вы бежите каждый путь или только те, которые имеют специальные символы.

• По умолчанию системное свойство _etag исключено из индексирования, если только etag не добавлен во включаемый путь для индексирования.

• Если режим индексирования установлен в значение Согласованность, системные свойства id и _ts будут индексироваться автоматически.

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

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

В этом разделе приведены примеры политики индексирования для включения и исключения путей.

Приоритет включения / исключения

Если включаемые и исключаемые пути конфликтуют, приоритет будет имеет более точный путь.

Приведем пример:

Включаемый путь: /food/ingredients/nutrition/*

Исключаемый путь: /food/ingredients/*

В этом случае включенный путь имеет приоритет над исключенным путем, так как это более точно. На основе этих путей все данные в пути food/ingredients или вложенные в них пути не будут индексироваться. Исключением могут быть данные внутри включаемого пути: /food/ingredients/nutrition/*, который будет индексироваться.

Ниже приведены некоторые правила для приоритета включаемых и исключаемых путей в Azure Cosmos DB.

• Более глубокие пути более точны, чем неглубокие пути. Например: /a/b/? более точен, чем /a/?.

• /? более точен, чем /*. Например, /a/? более точен, чем /a/*, поэтому /a/? имеет больший приоритет.

• Путь /* должен содержать либо включаемый путь, либо исключаемый путь.

Векторные индексы

Индексы векторов повышают эффективность при выполнении векторного поиска с помощью системной VectorDistance функции. Поиск векторов имеет более низкую задержку, более высокую пропускную способность и меньше потребления единиц запросов при применении векторного индекса. Можно указать следующие типы политик индексов векторов:

Несколько моментов, которые следует отметить:

• flat quantizedFlat Типы индексов применяют индекс Azure Cosmos DB для хранения и чтения каждого вектора при выполнении векторного поиска. Векторные поиски с индексом flat — это поиск подбора и создание 100% точности или отзыва. То есть гарантированно найти наиболее похожие векторы в наборе данных. Однако существует ограничение 505 измерений для векторов на неструктурированном индексе.

• Индекс quantizedFlat сохраняет векторы сжатыми (сжатыми) в индексе. Поиск векторов с quantizedFlat индексом также является поиском подбора, однако их точность может быть немного меньше 100 %, так как векторы квантуируются перед добавлением в индекс. Однако поиск векторов должен quantized flat иметь более низкую задержку, более высокую пропускную способность и более низкую стоимость ЕЗ, чем векторные поиски по индексу flat . Это хороший вариант для сценариев, в которых вы используете фильтры запросов для сужения векторного поиска до относительно небольшого набора векторов, и требуется высокая точность.

• Индекс diskANN — это отдельный индекс, определенный специально для векторов, применяющих DiskANN, набор алгоритмов индексирования векторов высокой производительности, разработанных Microsoft Research. Индексы DiskANN могут предложить некоторые из самых низких задержек, максимальной пропускной способности и наименьшей стоимости запросов ЕЗ, сохраняя высокую точность. Однако, так как DiskANN является приблизительным ближайшим индексом соседей (ANN), точность может быть ниже quantizedFlat или flat.

Ниже приведен пример политики индексирования с векторным индексом:

{
    "indexingMode": "consistent",
    "automatic": true,
    "includedPaths": [
        {
            "path": "/*"
        }
    ],
    "excludedPaths": [
        {
            "path": "/_etag/?",
        },
        {
            "path": "/vector/*"
        }
    ],
    "vectorIndexes": [
        {
            "path": "/vector",
            "type": "diskANN"
        }
    ]
}

Пространственные индексы

При определении пространственного пути в политике индексации необходимо определить, какой индекс type следует применить к этому пути. К пространственным индексам могут относиться следующие типы:

• Point

• Многоугольник

• MultiPolygon

• LineString

Azure Cosmos DB по умолчанию не создает пространственные индексы. Если необходимо использовать встроенные функции пространственного SQL, необходимо создать пространственный индекс для обязательных свойств. В этом разделе приведены примеры политики индексации для добавления пространственных индексов.

Составные индексы

Для запросов, имеющих предложение ORDER BY с двумя или более свойствами, требуется составной индекс. Кроме того, можно определить составной индекс, чтобы повысить производительность многих запросов на равенство и на диапазоны. По умолчанию составные индексы не определяются, поэтому при необходимости следует добавлять составные индексы.

В отличие от включаемых или исключаемых путей, невозможно создать путь с подстановочным знаком /*. Каждый составной путь имеет неявный элемент /? в конце пути, который не нужно указывать. Составные пути приводят к скалярным значениям, которое является единственным значением, включенным в составной индекс. Если путь в составном индексе не существует в элементе или приводит к некаларовом значению, то в индекс добавляется значение, указывающее, что путь не определен.

При определении составного индекса необходимо указать:

• Два или более пути свойств. Последовательность, в которой определяются пути к свойствам, имеет значение.

• Сортировка (по возрастанию или по убыванию).

Запросы ORDER BY (сортировка) по нескольким свойствам:

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

• Если пути составного индекса не соответствуют последовательности свойств в ORDER BY предложении, составной индекс не может поддерживать запрос.

• Сортировка путей составных индексов (по возрастанию или по убыванию) должна также совпадать с параметром order в предложении ORDER BY.

• Составной индекс также поддерживает предложение ORDER BY с противоположной сортировкой для всех путей.

Рассмотрим следующий пример, в котором составной индекс определяется для свойств Name, Age и _ts.

Необходимо настроить политику индексирования для обслуживания всех необходимых запросов ORDER BY.

запросы с фильтрами по нескольким свойствам.

Если запрос содержит фильтры по двум или нескольким свойствам, может оказаться полезным создать составной индекс для этих свойств.

Например, рассмотрим следующий запрос, имеющий фильтр равенства и диапазона:

SELECT *
FROM c
WHERE c.name = "John" AND c.age > 18

Этот запрос более эффективный, занимает меньше времени и потребляет меньше единиц запросов, если он может применить составной индекс к (name ASC, age ASC).

Запросы с несколькими фильтрами по диапазону также можно оптимизировать с помощью составного индекса. Однако каждый отдельный составной индекс может оптимизировать только один фильтр по диапазону. Фильтры диапазонов включают >, <, <=, >= и !=. Фильтр по диапазону должен определяться последним в составном индексе.

Рассмотрим следующий запрос с фильтром по равенству и двумя фильтрами по диапазону:

SELECT *
FROM c
WHERE c.name = "John" AND c.age > 18 AND c._ts > 1612212188

Этот запрос эффективнее с составным индексом и (name ASC, age ASC) (name ASC, _ts ASC). Однако запрос не будет использовать составной индекс, (age ASC, name ASC) так как свойства с фильтрами равенства должны быть определены сначала в составном индексе. В (name ASC, age ASC, _ts ASC) вместо одного составного индекса должны использоваться два отдельных составных индекса, так как каждый составной индекс может оптимизировать только один фильтр по диапазону.

При создании составных индексов для запросов с фильтрами по нескольким свойствам используются следующие рекомендации

• В выражениях фильтра могут использоваться несколько составных индексов.
• Свойства в фильтре запроса должны соответствовать свойствам в составном индексе. Если свойство находится в составном индексе, но не входит в запрос в качестве фильтра, запрос не будет использовать составной индекс.
• Если запрос имеет другие свойства в фильтре, который не определен в составном индексе, то для оценки запроса используются комбинации составных и диапазонных индексов. Для этого требуется меньше единиц запросов, чем исключительно с использованием индексов диапазона.
• Если свойство имеет фильтр по диапазону (>, <, <=, >= или !=), то это свойство должно определяться последним в составном индексе. Если запрос имеет несколько фильтров диапазона, он может воспользоваться несколькими составными индексами.
• При создании составного индекса для оптимизации запросов с несколькими фильтрами ORDER составной индекс не влияет на результаты. Это необязательное свойство.

Рассмотрим следующий пример, в котором составной индекс определяется по свойствам Name, Age и timestamp.

Запросы с фильтром и ORDER BY

Если запрос фильтрует один или несколько свойств и имеет различные свойства в предложении ORDER BY, может быть полезно добавить свойства в фильтр в ORDER BY предложение.

Например, добавив свойства в фильтр ORDER BY в предложение, можно переписать следующий запрос, чтобы применить составной индекс:

Запрос с использованием индекса по диапазону:

SELECT *
FROM c 
WHERE c.name = "John" 
ORDER BY c.timestamp

Запрос с использованием составного индекса:

SELECT * 
FROM c 
WHERE c.name = "John"
ORDER BY c.name, c.timestamp

Одни и те же оптимизации запросов могут быть обобщены для запросов ORDER BY с фильтрами, с учетом того, что отдельные составные индексы могут поддерживать только один фильтр по диапазону.

Запрос с использованием индекса по диапазону:

SELECT * 
FROM c 
WHERE c.name = "John" AND c.age = 18 AND c.timestamp > 1611947901 
ORDER BY c.timestamp

Запрос с использованием составного индекса:

SELECT * 
FROM c 
WHERE c.name = "John" AND c.age = 18 AND c.timestamp > 1611947901 
ORDER BY c.name, c.age, c.timestamp

Кроме того, можно использовать составные индексы для оптимизации запросов с помощью системных функций и директивы ORDER BY.

Запрос с использованием индекса по диапазону:

SELECT * 
FROM c 
WHERE c.firstName = "John" AND Contains(c.lastName, "Smith", true) 
ORDER BY c.lastName

Запрос с использованием составного индекса:

SELECT * 
FROM c 
WHERE c.firstName = "John" AND Contains(c.lastName, "Smith", true) 
ORDER BY c.firstName, c.lastName

При создании составных индексов для оптимизации запроса с помощью фильтра и предложения ORDER BY следует учитывать следующие моменты.

• Если вы не определяете составной индекс для запроса с фильтром по одному свойству и отдельному ORDER BY предложению с использованием другого свойства, запрос по-прежнему будет выполнен успешно. Однако стоимость единицы запроса может быть сокращена с помощью составного индекса, особенно если свойство в предложении ORDER BY имеет высокую кратность.
• Если запрос фильтрует свойства, эти свойства должны быть включены сначала в ORDER BY предложение.
• Если в запросе используется фильтр по нескольким свойствам, фильтры по равенству должны быть первыми свойствами в предложении ORDER BY.
• Если в запросе используется фильтр по нескольким свойствам, то для одного составного индекса можно использовать не более одного фильтра по диапазону или системной функции. Свойство, используемое в фильтре по диапазону или системной функции, должно определяться в составном индексе последним.
• Все рекомендации по созданию составных индексов для ORDER BY запросов с несколькими свойствами и запросами с фильтрами по нескольким свойствам по-прежнему применяются.

Запросы с фильтром и статистическим выражением

Если запрос фильтрует один или несколько свойств и имеет агрегатную системную функцию, может оказаться полезным создать составной индекс для свойств в функции фильтра и агрегатной системы. Эта оптимизация применяется к системным функциям Sum и AVG.

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

• Составные индексы необязательны при выполнении запросов со статистическими выражениями. Однако затраты на ЕЗ запроса часто могут быть сокращены с составным индексом.
• Если в запросе используется фильтр по нескольким свойствам, фильтры по равенству должны быть первыми свойствами составном индексе.
• Можно использовать не более одного фильтра по диапазону для каждого составного индекса, и фильтр должен находиться в свойстве в системной функции статистического выражения.
• Свойство в системной функции статистического выражения должно определяться последним в составном индексе.
• Значение order (ASC или DESC) не имеет значения.

Изменение политики индексирования

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

Во время преобразований индекса не влияет на доступность записи. В преобразовании индекса используется подготовленные ЕЗ, но с более низким приоритетом, чем операции CRUD или запросы.

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

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

При удалении индексированного пути подсистема запросов немедленно перестанет использовать его и выполнит полную проверку.

Политики индексирования и TTL

При использовании функции срока жизни (TTL) требуется индексирование. Это означает следующее.

• Невозможно активировать TTL в контейнере, в котором задан noneрежим индексирования .
• Невозможно задать для режима индексирования значение None в контейнере, где активируется TTL.

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

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

• Общие сведения об индексировании
• Управление политикой индексирования