Stratégies d’indexation dans Azure Cosmos DB

Article
09/26/2024

S’APPLIQUE À : NoSQL

Dans Azure Cosmos DB, chaque conteneur est doté d’une stratégie d’indexation qui détermine la façon dont les éléments du conteneur doivent être indexés. La stratégie d’indexation par défaut pour les conteneurs nouvellement créés indexe chaque propriété de chaque élément et applique des index de plage pour les chaînes ou les nombres. Vous obtenez ainsi un bon niveau de performance des requêtes sans avoir à réfléchir dès le départ à l’indexation ni à la gestion des index.

Dans certaines situations, vous souhaiterez peut-être remplacer ce comportement automatique pour mieux répondre à vos besoins. Vous pouvez personnaliser la stratégie d’indexation d’un conteneur en définissant son mode d’indexation et inclure ou exclure des chemins de la propriété.

Notes

La méthode de mise à jour des stratégies d’indexation décrite dans cet article s’applique uniquement à l’API Azure Cosmos DB for NoSQL. Découvrez l’indexation dans API Azure Cosmos DB pour MongoDB.

Mode d'indexation

Azure Cosmos DB prend en charge deux modes d’indexation :

Cohérent : L’index est mis à jour de manière synchrone quand vous créez, mettez à jour ou supprimez des éléments. Cela signifie que la cohérence de vos requêtes de lecture sera la cohérence configurée pour le compte.
Aucun : L’indexation est désactivée sur le conteneur. Ce mode est courant lorsqu’un conteneur est exclusivement utilisé comme magasin clé-valeur sans que des index secondaires soient nécessaires. Vous pouvez également l’utiliser pour améliorer les performances des opérations en bloc. Une fois les opérations en bloc effectuées, vous pouvez définir le mode d’indexation Consistent (Cohérent), puis le superviser à l’aide de IndexTransformationProgress jusqu’à la fin du processus.

Notes

Azure Cosmos DB prend également en charge un mode d’indexation différée. L’indexation différée effectue des mises à jour de l’index à un niveau de priorité nettement inférieur quand le moteur ne fait aucun autre travail. Cela peut entraîner des résultats de requête incohérents ou incomplets. Si vous prévoyez d’interroger un conteneur Azure Cosmos DB, vous ne devez pas sélectionner l’indexation différée. Les nouveaux conteneurs ne peuvent pas sélectionner l’indexation différée. Vous pouvez demander une exemption en contactant cosmosdbindexing@microsoft.com (sauf si vous utilisez un compte Azure Cosmos DB en mode serverless, qui ne prend pas en charge l’indexation différée).

Par défaut, la stratégie d’indexation a la valeur automatic. Ce résultat est obtenu en affectant à la propriété automatic de la stratégie d’indexation la valeur true. L’affectation de true à cette propriété permet à Azure Cosmos DB d’indexer automatiquement les éléments au fur et à mesure de leur rédaction.

Taille d'index

Dans Azure Cosmos DB, la consommation totale du stockage correspond à la somme de la taille des données et de la taille de l’index. Voici quelques-unes des fonctionnalités de la taille d’index :

La taille d’index dépend de la stratégie d’indexation. Si toutes les propriétés sont indexées, la taille d’index peut être supérieure à la taille des données.
Lorsque des données sont supprimées, les index sont compactés de manière quasi continue. Toutefois, pour les petites suppressions de données, vous risquez de ne pas observer de diminution immédiate de la taille d’index.
La taille de l’index peut croître temporairement quand les partitions physiques sont divisées. L’espace d’index est libéré après la division de la partition.

Inclusion et exclusion de chemins de propriété

Une stratégie d’indexation personnalisée peut spécifier des chemins de propriétés qui sont explicitement inclus dans l’indexation ou en sont exclus. En optimisant le nombre de chemins d’accès qui sont indexés, vous pouvez réduire considérablement la latence et les frais de chargement des opérations d’écriture. Ces chemins sont définis à l’aide de la méthode décrite dans la section de vue d’ensemble de l’indexation avec les ajouts suivants :

un chemin menant à une valeur scalaire (chaîne ou nombre) se termine par /?
les éléments tirés d’un tableau sont traités ensemble par le biais de la notation /[] (au lieu de /0, /1 etc.)
le générique /* peut être utilisé pour correspondre à tous les éléments situés sous le nœud

En reprenant le même exemple :

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

le chemin du employees de headquarters est /headquarters/employees/?
le chemin country de locations est /locations/[]/country/?
le chemin de tout ce qui se trouve sous headquarters est /headquarters/*

Par exemple, nous pourrions inclure le chemin d’accès /headquarters/employees/?. Ce chemin d’accès permet de s’assurer que la propriété employees est indexée, mais sans indexer de JSON imbriqué supplémentaire au sein de cette propriété.

Stratégie inclure/exclure

Toute stratégie d’indexation doit inclure le chemin racine /* comme chemin inclus ou exclu.

Inclure le chemin racine pour exclure sélectivement des chemins qui n’ont pas besoin d’être indexés. C’est l’approche recommandée, car elle permet à Azure Cosmos DB d’indexer proactivement toute nouvelle propriété qui peut être ajoutée à votre modèle.
Exclure le chemin racine pour inclure sélectivement des chemins devant être indexés. Le chemin de propriété de clé de partition n’est pas indexé par défaut avec la stratégie d’exclusion et doit être explicitement inclus si nécessaire.
Pour les chemins avec des caractères normaux qui incluent : des caractères alphanumériques et _ (caractère de soulignement), vous n’êtes pas obligé d’échapper la chaîne de chemin entourée de guillemets doubles (par exemple, "/path/?"). Pour les chemins avec d’autres caractères spéciaux, vous devez avoir les caractères d’échappement que sont les guillemets doubles autour de la chaîne de chemin (par exemple "/"path-abc"/?"). Si vous prévoyez des caractères spéciaux dans votre chemin, vous pouvez échapper chaque chemin pour des raisons de sécurité. Du point de vue fonctionnel, que vous échappiez tous les chemins ou seulement ceux qui comportent des caractères spéciaux ne fait aucune différence.
La propriété système _etag est exclue de l’indexation par défaut, sauf si l’etag est ajouté au chemin inclus pour l’indexation.
Si le mode d’indexation est défini sur cohérent, les propriétés système id et _ts sont automatiquement indexées.
Si un chemin d’accès explicitement indexé n’existe pas dans un élément, une valeur est ajoutée à l’index pour indiquer que le chemin n’est pas défini.

Tous les chemins d’accès explicitement inclus auront des valeurs ajoutées à l’index pour chaque élément du conteneur, même si le chemin d’accès n’est pas défini pour un élément donné.

Consultez cette section pour obtenir des exemples de stratégie d’indexation pour l’inclusion et l’exclusion de chemins d’accès.

Priorité de l’inclusion ou de l’exclusion

Si les chemins inclus et les chemins exclus présentent un conflit, le chemin plus précis est prioritaire.

Voici un exemple :

Chemin inclus : /food/ingredients/nutrition/*

Chemin exclu : /food/ingredients/*

Dans ce cas, le chemin inclus est prioritaire sur le chemin exclu, car il est plus précis. Sur la base de ces chemins, toutes les données du chemin food/ingredients ou imbriquées dans celui-ci sont exclues de l’index. Il en va différemment des données du chemin inclus /food/ingredients/nutrition/*, qui est indexé.

Voici quelques règles qui déterminent la priorité des chemins inclus et exclus dans Azure Cosmos DB :

Les chemins plus profonds sont plus précis que les chemins plus étroits. Par exemple, /a/b/? est plus précis que /a/?.
/? est plus précis que /*. Par exemple, /a/? étant plus précis que /a/*, /a/? est prioritaire.
Le chemin /* doit être un chemin inclus ou un chemin exclu.

Index vectoriels

Remarque

Vous devez vous inscrire à la fonctionnalité de préversion de l’index vectoriel NoSQL d’Azure Cosmos DB pour spécifier une stratégie d’indexation vectorielle.>

Les index vectoriels augmentent l’efficacité lors de l’exécution de recherches vectorielles à l’aide de la fonction système VectorDistance. Les recherches vectorielles ont une latence plus faible, un débit plus élevé et moins de consommation de RU lors de l’application d’un index vectoriel. Vous pouvez spécifier les types de stratégies d’index vectoriel suivants :

Type	Description	Dimensions maximales
`flat`	Stocke les vecteurs sur le même index que d’autres propriétés indexées.	505
`quantizedFlat`	Quantifie (compresse) les vecteurs avant le stockage sur l’index. Cela peut améliorer la latence et le débit au prix d’une précision légèrement moins grande.	4096
`diskANN`	Crée un index basé sur DiskANN pour une recherche approximative rapide et efficace.	4096

Quelques points à noter :

Les types d’index flat et quantizedFlat appliquent l’index d’Azure Cosmos DB pour stocker, puis lire chaque vecteur lors de l’exécution d’une recherche vectorielle. Les recherches vectorielles avec un index flat sont des recherches par force brute et produisent une exactitude ou un rappel de 100 %. Autrement dit, vous êtes sûr de trouver les vecteurs les plus similaires dans le jeu de données. Toutefois, il existe une limitation de dimensions 505 pour les vecteurs sur un index plat.
L’index quantizedFlat stocke les vecteurs quantifiés (compressés) sur l’index. Les recherches vectorielles avec un index quantizedFlat sont également des recherches par force brute, mais leur exactitude peut être légèrement inférieure à 100 %, car les vecteurs sont quantifiés avant l’ajout à l’index. Toutefois, les recherches vectorielles avec quantized flat doivent avoir une latence plus faible, un débit plus élevé et un coût de RU moins élevé que les recherches vectorielles sur un index flat. Il s’agit d’une bonne option pour les scénarios dans lesquels vous utilisez des filtres de requête pour limiter la recherche vectorielle à un ensemble relativement petit de vecteurs, et quand une exactitude extrêmement élevée est requise.
L’index diskANN est un index distinct défini spécifiquement pour les vecteurs appliquant DiskANN, la suite d’algorithmes d’indexation de vecteurs hautes performances développée par Microsoft Research. Les index DiskANN peuvent offrir une certaine latence, le débit le plus élevé et les requêtes de coût de RU plus faibles, tout en conservant une exactitude élevée. Toutefois, puisque DiskANN est un index du plus proche voisin approximatif (ANN), l’exactitude peut être inférieure à quantizedFlat ou flat.

Voici un exemple de stratégie d’indexation avec un index vectoriel :

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

Important

Une stratégie d’indexation vectorielle doit se trouver sur le chemin défini dans la stratégie vectorielle du conteneur. Découvrez-en davantage sur les stratégies de vecteur de conteneur. Les index vectoriels doivent également être définis au moment de la création du conteneur et ne peuvent pas être modifiés une fois créés. Dans une version ultérieure, les index vectoriels seront modifiables.

Important

Chemin vectoriel ajouté à la section « excludedPaths » de la stratégie d’indexation pour garantir un niveau de performance optimisé pour l’insertion. Ne pas ajouter le chemin vectoriel à « excludedPaths » entraîne une charge RU et une latence plus élevées pour les insertions vectorielles.

Index spatiaux

Lorsque vous définissez un chemin d’accès spatial dans la stratégie d’indexation, vous devez définir l’index type à appliquer à ce chemin d’accès. Les types possibles pour les index spatiaux sont les suivants :

Point
Polygone
MultiPolygon
LineString

Azure Cosmos DB, par défaut, ne crée pas d’index spatial. Si vous souhaitez utiliser des fonctions intégrées SQL spatiales, vous devez créer un index spatial sur les propriétés requises. Consultez cette section pour des exemples de stratégies d’indexation afin d’ajouter des index spatiaux.

Index composites

Les requêtes qui ont une clause ORDER BY avec deux ou plusieurs propriétés nécessitent un index composite. Vous pouvez également définir un index composite pour améliorer les performances de nombreuses requêtes d’égalité et de plage. Par défaut, aucun index composite n’est défini. Vous devez donc ajouter des index composites en fonction des besoins.

Contrairement aux chemins inclus ou exclus, vous ne pouvez pas créer un chemin avec le caractère générique /*. Chaque chemin composite se termine par un /? implicite que vous n’avez pas besoin de spécifier. Les chemins composites aboutissent à une valeur scalaire, qui est la seule valeur incluse dans l’index composite. Si un chemin d’accès dans un index composite n’existe pas dans un élément ou conduit à une valeur non scalaire, une valeur est ajoutée à l’index pour indiquer que le chemin d’accès n’est pas défini.

Lorsque vous définissez un index composite, vous spécifiez :

deux ou plusieurs chemins de propriété ; la séquence où les chemins de propriété sont des aspects définis ;
l’ordre (croissant ou décroissant).

Notes

Quand vous ajoutez un index composite, la requête utilise les index de plage existants jusqu’à ce que ce que l’ajout de ce nouvel index soit terminé. Ainsi, quand vous ajoutez un index composite, il se peut que vous ne perceviez pas immédiatement les améliorations de performances. Il est possible de suivre la progression de la transformation d’index avec un des kits de développement logiciel (SDK).

Requêtes ORDER BY sur plusieurs propriétés :

Les considérations suivantes sont utilisées lors de l’utilisation d’index composites pour les requêtes avec une clause ORDER BY comptant au moins deux propriétés :

Si les chemins des index composites ne correspondent pas à la séquence des propriétés dans la clause ORDER BY, l’index composite ne peut pas prendre en charge la requête.
L’ordre des chemins des index composites (croissant ou décroissant) doit également correspondre à order dans la clause ORDER BY.
L’index composite prend également en charge une clause ORDER BY dont l’ordre est inverse sur tous les chemins.

Prenons l’exemple suivant, où un index composite est défini sur des propriétés name, age et _ts :

Index composite	Exemple `ORDER BY` de requête	Pris en charge par l’index composite ?
`(name ASC, age ASC)`	`SELECT * FROM c ORDER BY c.name ASC, c.age asc`	`Yes`
`(name ASC, age ASC)`	`SELECT * FROM c ORDER BY c.age ASC, c.name asc`	`No`
`(name ASC, age ASC)`	`SELECT * FROM c ORDER BY c.name DESC, c.age DESC`	`Yes`
`(name ASC, age ASC)`	`SELECT * FROM c ORDER BY c.name ASC, c.age DESC`	`No`
`(name ASC, age ASC, timestamp ASC)`	`SELECT * FROM c ORDER BY c.name ASC, c.age ASC, timestamp ASC`	`Yes`
`(name ASC, age ASC, timestamp ASC)`	`SELECT * FROM c ORDER BY c.name ASC, c.age ASC`	`No`

Vous devez personnaliser votre stratégie d’indexation afin de pouvoir servir toutes les requêtes ORDER BY nécessaires.

Requêtes avec des filtres sur plusieurs propriétés

Si une requête a des filtres sur deux propriétés ou plus, il peut être utile de créer un index composite pour ces propriétés.

Par exemple, considérez la requête suivante qui a un filtre d’égalité et un filtre de plage :

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

Cette requête est plus efficace, prendrait moins de temps et consommerait moins de RU, si elle était en mesure d’appliquer un index composite sur (name ASC, age ASC).

Les requêtes avec plusieurs filtres de plage peuvent également être optimisées à l’aide d’un index composite. Toutefois, chaque index composite individuel ne peut optimiser qu’un seul filtre de plage. Les filtres de plage incluent >, <, <=, >= et !=. Le filtre de plage doit être défini en dernier dans l’index composite.

Considérez la requête suivante, qui comprend un filtre d’égalité et deux filtres de plage :

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

Cette requête est plus efficace avec un index composite sur (name ASC, age ASC) et (name ASC, _ts ASC). Toutefois, la requête n’utiliserait pas d’index composite sur (age ASC, name ASC), car les propriétés avec des filtres d’égalité doivent être définies en premier dans l’index composite. Deux index composites distincts sont requis au lieu d’un index composite unique sur (name ASC, age ASC, _ts ASC), car chaque index composite peut uniquement optimiser un seul filtre de plage.

Les considérations suivantes sont utilisées lors de la création d’index composites pour les requêtes avec des filtres sur plusieurs propriétés

Les expressions de filtre peuvent utiliser plusieurs index composites.
Les propriétés du filtre de la requête doivent correspondre à celles de l’index composite. Si une propriété se trouve dans l’index composite, mais qu’elle n’est pas incluse dans la requête en tant que filtre, la requête n’utilise pas l’index composite.
Si une requête a des propriétés supplémentaires dans le filtre qui n’ont pas été définies dans un index composite, une combinaison d’index composites et de plage est utilisée pour évaluer la requête. Cela nécessite moins de RU que l’utilisation exclusive d’index de plage.
Si une propriété a un filtre de plage (>, <, <=, >= ou !=), cette propriété doit être définie en dernier dans l’index composite. Si une requête a plusieurs filtres de plage, elle peut tirer parti de plusieurs index composites.
Lors de la création d’un index composite pour optimiser des requêtes avec plusieurs filtres, ORDER de l’index composite n’a aucun impact sur les résultats. Cette propriété est facultative.

Prenons les exemples suivants, où un index composite est défini sur des propriétés name, age et timestamp :

Index composite	Exemple de requête	Pris en charge par l’index composite ?
`(name ASC, age ASC)`	`SELECT * FROM c WHERE c.name = "John" AND c.age = 18`	`Yes`
`(name ASC, age ASC)`	`SELECT * FROM c WHERE c.name = "John" AND c.age > 18`	`Yes`
`(name ASC, age ASC)`	`SELECT COUNT(1) FROM c WHERE c.name = "John" AND c.age > 18`	`Yes`
`(name DESC, age ASC)`	`SELECT * FROM c WHERE c.name = "John" AND c.age > 18`	`Yes`
`(name ASC, age ASC)`	`SELECT * FROM c WHERE c.name != "John" AND c.age > 18`	`No`
`(name ASC, age ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.name = "John" AND c.age = 18 AND c.timestamp > 123049923`	`Yes`
`(name ASC, age ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.name = "John" AND c.age < 18 AND c.timestamp = 123049923`	`No`
`(name ASC, age ASC) and (name ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.name = "John" AND c.age < 18 AND c.timestamp > 123049923`	`Yes`

Requêtes avec un filtre et la clause ORDER BY

Si une requête filtre sur une ou plusieurs propriétés et possède des propriétés différentes dans la clause ORDER BY, il peut être utile d’ajouter les propriétés du filtre à la clause ORDER BY.

Par exemple, en ajoutant les propriétés du filtre à la clause ORDER BY, la requête suivante peut être réécrite pour appliquer un index composite :

Requête utilisant un index de plage :

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

Requête utilisant un index composite :

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

Vous pouvez généraliser les mêmes optimisations de requête pour toutes les requêtes ORDER BY avec des filtres, en gardant à l’esprit que les index composites individuels ne peuvent prendre en charge qu’un seul filtre de plage.

Requête utilisant un index de plage :

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

Requête utilisant un index composite :

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

En outre, vous pouvez utiliser des index composites pour optimiser les requêtes comportant des fonctions système et la clause ORDER BY :

Requête utilisant un index de plage :

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

Requête utilisant un index composite :

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

Les considérations suivantes s’appliquent lors de la création d’index composites pour optimiser une requête avec un filtre et une clause ORDER BY :

Si vous ne définissez pas d’index composite sur une requête avec un filtre sur une propriété et une clause ORDER BY distincte à l’aide d’une autre propriété, la requête réussit quand même. Toutefois, le coût RU de la requête peut être réduit à l’aide d’un index composite, en particulier si la propriété de la clause ORDER BY a une cardinalité élevée.
Si la requête filtre sur les propriétés, ces propriétés doivent être incluses en premier dans la clause ORDER BY.
Si la requête filtre plusieurs propriétés, les filtres d’égalité doivent être les premières propriétés de la clause ORDER BY.
Si la requête filtre sur plusieurs propriétés, vous pouvez utiliser au maximum un filtre de plage ou une fonction système par index composite. La propriété utilisée dans le filtre de plage ou la fonction système doit être définie en dernier dans l’index composite.
Toutes les considérations relatives à la création d’index composites pour les requêtes ORDER BY avec plusieurs propriétés, ainsi que les requêtes avec des filtres sur plusieurs propriétés, s’appliquent toujours.

Index composite	Exemple `ORDER BY` de requête	Pris en charge par l’index composite ?
`(name ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.name = "John" ORDER BY c.name ASC, c.timestamp ASC`	`Yes`
`(name ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.name = "John" AND c.timestamp > 1589840355 ORDER BY c.name ASC, c.timestamp ASC`	`Yes`
`(timestamp ASC, name ASC)`	`SELECT * FROM c WHERE c.timestamp > 1589840355 AND c.name = "John" ORDER BY c.timestamp ASC, c.name ASC`	`No`
`(name ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.name = "John" ORDER BY c.timestamp ASC, c.name ASC`	`No`
`(name ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.name = "John" ORDER BY c.timestamp ASC`	`No`
`(age ASC, name ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.age = 18 and c.name = "John" ORDER BY c.age ASC, c.name ASC,c.timestamp ASC`	`Yes`
`(age ASC, name ASC, timestamp ASC)`	`SELECT * FROM c WHERE c.age = 18 and c.name = "John" ORDER BY c.timestamp ASC`	`No`

Requêtes avec un filtre et un agrégat

Si une requête filtre une ou plusieurs propriétés et possède une fonction système d’agrégation, il peut être utile de créer un index composite pour les propriétés dans la fonction système de filtrage et d’agrégation. Cette optimisation s’applique aux fonctions système SUM et AVG.

Les considérations suivantes sont utilisées lors de la création d’index composites pour optimiser une fonction système de filtrage et d’agrégation.

Les index composites sont facultatifs lors de l’exécution de requêtes avec des agrégats. Toutefois, le coût RU de la requête peut être réduit à l’aide d’un index composite.
Si la requête filtre plusieurs propriétés, les filtres d’égalité doivent être les premières propriétés de l’index composite.
Vous pouvez avoir au maximum un filtre de plage par index composite, et il doit se trouver sur la propriété dans la fonction système d’agrégation.
La propriété dans la fonction système d’agrégation doit être définie en dernier dans l’index composite.
Le order (ASC ou DESC) n’a pas d’importance.

Index composite	Exemple de requête	Pris en charge par l’index composite ?
`(name ASC, timestamp ASC)`	`SELECT AVG(c.timestamp) FROM c WHERE c.name = "John"`	`Yes`
`(timestamp ASC, name ASC)`	`SELECT AVG(c.timestamp) FROM c WHERE c.name = "John"`	`No`
`(name ASC, timestamp ASC)`	`SELECT AVG(c.timestamp) FROM c WHERE c.name > "John"`	`No`
`(name ASC, age ASC, timestamp ASC)`	`SELECT AVG(c.timestamp) FROM c WHERE c.name = "John" AND c.age = 25`	`Yes`
`(age ASC, timestamp ASC)`	`SELECT AVG(c.timestamp) FROM c WHERE c.name = "John" AND c.age > 25`	`No`

Modification de la stratégie d’indexation

La stratégie d’indexation d’un conteneur peut être mise à jour à tout moment à l’aide du portail Azure ou de l’un des kit de développement logiciel (SDK) pris en charge. Une mise à jour de la stratégie d’indexation déclenche une transformation de l’ancien index vers le nouveau, qui est effectuée en ligne et localement (aucun espace de stockage supplémentaire n’est consommé pendant l’opération). L’ancienne stratégie d’indexation est transformée efficacement en nouvelle stratégie, sans incidence sur la disponibilité d’écriture ni de lecture, ni sur le débit approvisionné sur le conteneur. La transformation d’index est une opération asynchrone. Le temps nécessaire pour l’effectuer dépend du débit approvisionné, du nombre d’éléments et de leur taille. Si plusieurs mises à jour de stratégie d’indexation doivent être effectuées, il est recommandé de réaliser toutes les modifications en tant qu’opération unique, afin que la transformation d’index se termine le plus vite possible.

Important

La transformation d’index est une opération qui consomme des unités de requête.

Remarque

Vous pouvez suivre la progression de la transformation d’index sur le portail Azure ou à l’aide de l’un des SDK.

Il n’y a aucun impact sur la disponibilité des écritures lors des transformations d’index. La transformation d’index utilise vos unités de requête approvisionnées, mais à une priorité inférieure à celles de vos opérations CRUD ou de vos requêtes.

Il n’y a aucun impact sur la disponibilité de lecture lors de l’ajout de nouveaux chemins indexés. Les requêtes utilisent uniquement les nouveaux chemins indexés une fois la transformation d’un index terminée. En d’autres termes, lors de l’ajout de nouveaux chemins indexés, les requêtes qui tirent parti de ce chemin indexé présentent les mêmes performances avant et pendant la transformation d’index. Une fois la transformation d’index terminée, le moteur de requête commence à utiliser les nouveaux chemins indexés.

Lorsque vous supprimez des chemins indexés, vous devez regrouper toutes vos modifications dans une seule transformation de stratégie d’indexation. Si vous supprimez plusieurs index et que vous le faites dans une seule modification de stratégie d’indexation, le moteur de requête fournit des résultats cohérents et complets tout au long de la transformation d’index. Toutefois, si vous supprimez des index par le biais de plusieurs modifications de stratégie d’indexation, le moteur de requête ne fournit pas de résultats cohérents ou complets tant que toutes les transformations d’index ne sont pas terminées. La plupart des développeurs ne suppriment pas les index, puis essaient immédiatement de les interroger. Or, en pratique, cette situation est peu probable.

Lorsque vous supprimez un chemin indexé, le moteur de requête cesse immédiatement de l’utiliser et effectue une analyse complète à la place.

Remarque

Dans la mesure du possible, vous devez toujours essayer de regrouper plusieurs suppression d’indexation dans une seule modification de stratégie d’indexation.

Important

La suppression d’un index entre immédiatement en vigueur, tandis que l’ajout d’un nouvel index prend un certain temps, car il nécessite une transformation d’indexation. Lorsque vous remplacez un index par un autre (par exemple, en remplaçant un index de propriété unique par un index composite), veillez à ajouter d’abord le nouvel index, puis attendez que la transformation d’index se termine avant de supprimer l’index précédent de la stratégie d’indexation. Dans le cas contraire, cela affectera négativement votre capacité à interroger l’index précédent et peut interrompre toutes les charges de travail actives qui font référence à l’index précédent.

Stratégies d’indexation et TTL

L’utilisation de la fonctionnalité de durée de vie (TTL, Time-to-Live) nécessite l’indexation. Cela signifie que :

il n’est pas possible d’activer la fonctionnalité TTL sur un conteneur dans lequel le mode d’indexation est défini sur none ;
il n’est pas possible de définir le mode d’indexation sur Aucun sur un conteneur dans lequel TLL est activée.

Dans les scénarios où aucun chemin de propriété ne doit être indexé, mais où la fonctionnalité TTL est nécessaire, vous pouvez utiliser une stratégie d’indexation avec le mode d’indexation consistent, aucun chemin inclus et un seul chemin exclu (/*).

Partage via

Stratégies d’indexation dans Azure Cosmos DB

Mode d'indexation

Taille d'index

Inclusion et exclusion de chemins de propriété

Stratégie inclure/exclure

Priorité de l’inclusion ou de l’exclusion

Index vectoriels

Index spatiaux

Index composites

Requêtes ORDER BY sur plusieurs propriétés :

Requêtes avec des filtres sur plusieurs propriétés

Requêtes avec un filtre et la clause ORDER BY

Requêtes avec un filtre et un agrégat

Modification de la stratégie d’indexation

Stratégies d’indexation et TTL

Commentaires

Ressources supplémentaires

Partage via

Stratégies d’indexation dans Azure Cosmos DB

Mode d'indexation

Taille d'index

Inclusion et exclusion de chemins de propriété

Stratégie inclure/exclure

Priorité de l’inclusion ou de l’exclusion

Index vectoriels

Index spatiaux

Index composites

Requêtes ORDER BY sur plusieurs propriétés :

Requêtes avec des filtres sur plusieurs propriétés

Requêtes avec un filtre et la clause ORDER BY

Requêtes avec un filtre et un agrégat

Modification de la stratégie d’indexation

Stratégies d’indexation et TTL

Contenu connexe

Commentaires

Ressources supplémentaires