Stratégies d’indexation dans Azure Cosmos DBIndexing policies in Azure Cosmos DB

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.In Azure Cosmos DB, every container has an indexing policy that dictates how the container's items should be indexed. La stratégie d’indexation par défaut pour les conteneurs nouvellement créés indexe toutes les propriétés de chaque élément, mettant en œuvre des index de plage pour les chaînes ou les nombres et des index spatiaux pour les objets GeoJSON de type Point.The default indexing policy for newly created containers indexes every property of every item, enforcing range indexes for any string or number, and spatial indexes for any GeoJSON object of type Point. Ceci vous permet d’obtenir des performances de requête élevées sans avoir à réfléchir à l’indexation et à la gestion des index dès le départ.This allows you to get high query performance without having to think about indexing and index management upfront.

Dans certaines situations, vous souhaiterez peut-être remplacer ce comportement automatique pour mieux répondre à vos besoins.In some situations, you may want to override this automatic behavior to better suit your requirements. 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é.You can customize a container's indexing policy by setting its indexing mode, and include or exclude property paths.

Notes

La méthode de mise à jour des stratégies d’indexation décrite dans cet article s’applique uniquement à l’API SQL (principale) de la base de données SQL Azure Cosmos.The method of updating indexing policies described in this article only applies to Azure Cosmos DB's SQL (Core) API.

Mode d'indexationIndexing mode

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

  • Cohérent : L’index est mis à jour de manière synchrone quand vous créez, mettez à jour ou supprimez des éléments.Consistent: The index is updated synchronously as you create, update or delete items. Cela signifie que la cohérence de vos requêtes de lecture sera la cohérence configurée pour le compte.This means that the consistency of your read queries will be the consistency configured for the account.
  • Aucun : L’indexation est désactivée sur le conteneur.None: Indexing is disabled on the container. C’est courant lorsqu’un conteneur est exclusivement utilisé comme magasin clé-valeur sans que des index secondaires soient nécessaires.This is commonly used when a container is used as a pure key-value store without the need for secondary indexes. Vous pouvez également l’utiliser pour améliorer les performances des opérations en bloc.It can also be used to improve the performance of bulk operations. 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.After the bulk operations are complete, the index mode can be set to Consistent and then monitored using the IndexTransformationProgress until complete.

Notes

Cosmos DB prend également en charge un mode d’indexation différé.Cosmos DB also supports a Lazy indexing mode. 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.Lazy indexing performs updates to the index at a much lower priority level when the engine is not doing any other work. Cela peut entraîner des résultats de requête incohérents ou incomplets.This can result in inconsistent or incomplete query results. De plus, l’utilisation de l’indexation différée à la place de « None » (aucune indexation) pour les opérations en bloc ne présente aucun avantage, car tout changement du mode d’indexation entraîne la suppression et la recréation de l’index.Additionally, using Lazy indexing in place of 'None' for bulk operations also provides no benefit as any change to the Index Mode will cause the index to be dropped and recreated. Pour toutes ces raisons, nous déconseillons aux clients de l’utiliser.For these reasons we recommend against customers using it. Pour améliorer le niveau de performance des opérations en bloc, affectez au mode d’indexation la valeur None, puis retournez au mode Consistent et supervisez la propriété IndexTransformationProgress sur le conteneur jusqu’à la fin du processus.To improve performance for bulk operations, set index mode to None, then return to Consistent mode and monitor the IndexTransformationProgress property on the container until complete.

Par défaut, la stratégie d’indexation a la valeur automatic.By default, indexing policy is set to automatic. Ce résultat est obtenu en affectant à la propriété automatic de la stratégie d’indexation la valeur true.It's achieved by setting the automatic property in the indexing policy to true. L’affectation de true à cette propriété permet à Azure CosmosDB d’indexer automatiquement les documents au fur et à mesure de leur rédaction.Setting this property to true allows Azure CosmosDB to automatically index documents as they are written.

Inclusion et exclusion de chemins de propriétéIncluding and excluding property paths

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.A custom indexing policy can specify property paths that are explicitly included or excluded from indexing. En optimisant le nombre de chemins indexés, vous pouvez réduire la quantité de stockage utilisé par votre conteneur et améliorer la latence des opérations d’écriture.By optimizing the number of paths that are indexed, you can lower the amount of storage used by your container and improve the latency of write operations. 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 :These paths are defined following the method described in the indexing overview section with the following additions:

  • un chemin menant à une valeur scalaire (chaîne ou nombre) se termine par /?a path leading to a scalar value (string or number) ends with /?
  • les éléments tirés d’un tableau sont traités ensemble par le biais de la notation /[] (au lieu de /0, /1 etc.)elements from an array are addressed together through the /[] notation (instead of /0, /1 etc.)
  • le générique /* peut être utilisé pour correspondre à tous les éléments situés sous le nœudthe /* wildcard can be used to match any elements below the node

En reprenant le même exemple :Taking the same example again:

    {
        "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/?the headquarters's employees path is /headquarters/employees/?

  • le chemin country du de locations est /locations/[]/country/?the locations' country path is /locations/[]/country/?

  • le chemin de tout ce qui se trouve sous headquarters est /headquarters/*the path to anything under headquarters is /headquarters/*

Par exemple, nous pourrions inclure le chemin d’accès /headquarters/employees/?.For example, we could include the /headquarters/employees/? path. 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é.This path would ensure that we index the employees property but would not index additional nested JSON within this property.

Stratégie inclure/exclureInclude/exclude strategy

Toute stratégie d’indexation doit inclure le chemin racine /* comme chemin inclus ou exclu.Any indexing policy has to include the root path /* as either an included or an excluded path.

  • Inclure le chemin racine pour exclure sélectivement des chemins qui n’ont pas besoin d’être indexés.Include the root path to selectively exclude paths that don't need to be indexed. 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.This is the recommended approach as it lets Azure Cosmos DB proactively index any new property that may be added to your model.

  • Exclure le chemin racine pour inclure sélectivement des chemins devant être indexés.Exclude the root path to selectively include paths that need to be indexed.

  • 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 autour de guillemets doubles (par exemple, "/ path / ?").For paths with regular characters that include: alphanumeric characters and _ (underscore), you don’t have to escape the path string around double quotes (for example, "/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"/ ?").For paths with other special characters, you need to escape the path string around double quotes (for example, "/"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é.If you expect special characters in your path, you can escape every path for safety. Du point de vue fonctionnel, que vous échappiez chaque chemin ou uniquement ceux qui ont des caractères spéciaux ne fait aucune différence.Functionally it doesn’t make any difference if you escape every path Vs just the ones that have special characters.

  • 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.The system property "etag" is excluded from indexing by default, unless the etag is added to the included path for indexing.

Lorsque vous incluez et excluez des chemins d’accès, vous pouvez rencontrer les attributs suivants :When including and excluding paths, you may encounter the following attributes:

  • kind peut être range ou hash.kind can be either range or hash. La fonctionnalité d’index de plage fournit toutes les fonctionnalités d’un index de hachage. Nous vous recommandons donc d’utiliser un index de plage.Range index functionality provides all of the functionality of a hash index, so we recommend using a range index.

  • precision est un nombre est défini au niveau de l’index pour les chemins inclus.precision is a number defined at the index level for included paths. La valeur -1 indique la précision maximale.A value of -1 indicates maximum precision. Nous vous recommandons de toujours définir cette valeur sur -1.We recommend always setting this value to -1.

  • dataType peut être String ou Number.dataType can be either String or Number. Cela indique les types de propriétés JSON qui seront indexées.This indicates the types of JSON properties which will be indexed.

Lorsqu’elles ne sont pas spécifiées, ces propriétés ont les valeurs par défaut suivantes :When not specified, these properties will have the following default values:

Nom de la propriétéProperty Name Valeur par défautDefault Value
kind range
precision -1
dataType String et NumberString and Number

Consultez cette section pour obtenir des exemples de stratégie d’indexation pour l’inclusion et l’exclusion de chemins d’accès.See this section for indexing policy examples for including and excluding paths.

Index spatiauxSpatial indexes

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.When you define a spatial path in the indexing policy, you should define which index type should be applied to that path. Les types possibles pour les index spatiaux sont les suivants :Possible types for spatial indexes include:

  • PointPoint

  • PolygonPolygon

  • MultiPolygonMultiPolygon

  • LineStringLineString

Azure Cosmos DB, par défaut, ne crée pas d’index spatial.Azure Cosmos DB, by default, will not create any spatial indexes. Si vous souhaitez utiliser des fonctions intégrées SQL spatiales, vous devez créer un index spatial sur les propriétés requises.If you would like to use spatial SQL built-in functions, you should create a spatial index on the required properties. Consultez cette section pour des exemples de stratégies d’indexation afin d’ajouter des index spatiaux.See this section for indexing policy examples for adding spatial indexes.

Index compositesComposite indexes

Les requêtes qui ont une clause ORDER BY avec deux ou plusieurs propriétés nécessitent un index composite.Queries that have an ORDER BY clause with two or more properties require a composite index. Vous pouvez également définir un index composite pour améliorer les performances de nombreuses requêtes d’égalité et de plage.You can also define a composite index to improve the performance of many equality and range queries. Par défaut, aucun index composite n’est défini. Vous devez donc ajouter des index composites en fonction des besoins.By default, no composite indexes are defined so you should add composite indexes as needed.

Lorsque vous définissez un index composite, vous spécifiez :When defining a composite index, you specify:

  • deux ou plusieurs chemins de propriété ;Two or more property paths. la séquence où les chemins de propriété sont des aspects définis ;The sequence in which property paths are defined matters.

  • l’ordre (croissant ou décroissant).The order (ascending or descending).

Notes

Lors de l’ajout d’un index composite, comme avec d’autres types d’index, les requêtes peuvent retourner des résultats incohérents au fur et à mesure que l’index est mis à jour.When adding a composite index, as with other index types, queries may return inconsistent results as the index is being updated.

Requêtes ORDER BY sur plusieurs propriétés :ORDER BY queries on multiple properties:

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 :The following considerations are used when using composite indexes for queries with an ORDER BY clause with two or more properties:

  • 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.If the composite index paths do not match the sequence of the properties in the ORDER BY clause, then the composite index can't support the query.

  • L’ordre des chemins des index composites (croissant ou décroissant) doit également correspondre à order dans la clause ORDER BY.The order of composite index paths (ascending or descending) should also match the order in the ORDER BY clause.

  • L’index composite prend également en charge une clause ORDER BY dont l’ordre est inverse sur tous les chemins.The composite index also supports an ORDER BY clause with the opposite order on all paths.

Prenons l’exemple suivant, où un index composite est défini sur des propriétés name, age et _ts :Consider the following example where a composite index is defined on properties name, age, and _ts:

Index compositeComposite Index Exemple ORDER BY de requêteSample ORDER BY Query Pris en charge par l’index composite ?Supported by Composite Index?
(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.You should customize your indexing policy so you can serve all necessary ORDER BY queries.

Requêtes avec des filtres sur plusieurs propriétésQueries with filters on multiple properties

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.If a query has filters on two or more properties, it may be helpful to create a composite index for these properties.

Par exemple, considérez la requête suivante qui a un filtre d’égalité sur deux propriétés :For example, consider the following query which has an equality filter on two properties:

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

Cette requête serait plus efficace, prendrait moins de temps et consommerait moins de RU, si elle est en mesure de tirer parti d’un index composite sur (name ASC, age ASC).This query will be more efficient, taking less time and consuming fewer RU's, if it is able to leverage a composite index on (name ASC, age ASC).

Les requêtes avec des filtres de plage peuvent également être optimisées à l’aide d’un index composite.Queries with range filters can also be optimized with a composite index. Toutefois, la requête ne peut avoir qu’un seul filtre de plage.However, the query can only have a single range filter. Les filtres de plage incluent >, <, <=, >= et !=.Range filters include >, <, <=, >=, and !=. Le filtre de plage doit être défini en dernier dans l’index composite.The range filter should be defined last in the composite index.

Considérez la requête suivante avec des filtres d’égalité et de plage :Consider the following query with both equality and range filters:

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

Cette requête serait plus efficace avec un index composite sur (name ASC, age ASC).This query will be more efficient with a composite index on (name ASC, age ASC). Toutefois, la requête n’utiliserait pas d’index composite sur (name ASC, age ASC), car les filtres d’égalité doivent être définis en premier dans l’index composite.However, the query would not utilize a composite index on (age ASC, name ASC) because the equality filters must be defined first in the composite index.

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ésThe following considerations are used when creating composite indexes for queries with filters on multiple properties

  • Les propriétés du filtre de la requête doivent correspondre à celles de l’index composite.The properties in the query's filter should match those in composite index. 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.If a property is in the composite index but is not included in the query as a filter, the query will not utilize the composite index.
  • 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 sera utilisée pour évaluer la requête.If a query has additional properties in the filter that were not defined in a composite index, then a combination of composite and range indexes will be used to evaluate the query. Cela nécessite moins de RU que l’utilisation exclusive d’index de plage.This will require fewer RU's than exclusively using range indexes.
  • Si une propriété a un filtre de plage (>, <, <=, >= ou !=), cette propriété doit être définie en dernier dans l’index composite.If a property has a range filter (>, <, <=, >=, or !=), then this property should be defined last in the composite index. Si une requête a plusieurs filtres de plage, elle n’utilise pas l’index composite.If a query has more than one range filter, it will not utilize the composite index.
  • Lors de la création d’un index composite pour optimiser des requêtes avec plusieurs filtres, ORDER de l’index composite n’aura aucun impact sur les résultats.When creating a composite index to optimize queries with multiple filters, the ORDER of the composite index will have no impact on the results. Cette propriété est facultative.This property is optional.
  • Si vous ne définissez pas d’index composite pour une requête avec des filtres sur plusieurs propriétés, la requête réussit quand même.If you do not define a composite index for a query with filters on multiple properties, the query will still succeed. Toutefois, le coût RU de la requête peut être réduit à l’aide d’un index composite.However, the RU cost of the query can be reduced with a composite index.

Prenons les exemples suivants, où un index composite est défini sur des propriétés name, age et timestamp :Consider the following examples where a composite index is defined on properties name, age, and timestamp:

Index compositeComposite Index Exemple de requêteSample Query Pris en charge par l’index composite ?Supported by Composite Index?
(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 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

Requêtes avec un filtre et une clause ORDER BYQueries with a filter as well as an ORDER BY clause

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.If a query filters on one or more properties and has different properties in the ORDER BY clause, it may be helpful to add the properties in the filter to the ORDER BY clause.

Par exemple, en ajoutant les propriétés du filtre à la clause ORDER BY, la requête suivante peut être réécrite pour tirer parti d’un index composite :For example, by adding the properties in the filter to the ORDER BY clause, the following query could be rewritten to leverage a composite index:

Requête utilisant un index de plage :Query using range index:

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

Requête utilisant un index composite :Query using composite index:

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

Le même modèle et les mêmes optimisations de requête peuvent être généralisés pour les requêtes avec plusieurs filtres d’égalité :The same pattern and query optimizations can be generalized for queries with multiple equality filters:

Requête utilisant un index de plage :Query using range index:

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

Requête utilisant un index composite :Query using composite index:

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

Les considérations suivantes sont utilisées lors de la création d’index composites pour optimiser une requête avec un filtre et une clause ORDER BY :The following considerations are used when creating composite indexes to optimize a query with a filter and ORDER BY clause:

  • Si la requête filtre sur les propriétés, celles-ci doivent être incluses en premier dans la clause ORDER BY.If the query filters on properties, these should be included first in the ORDER BY clause.
  • 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.If you do not define a composite index on a query with a filter on one property and a separate ORDER BY clause using a different property, the query will still succeed. 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.However, the RU cost of the query can be reduced with a composite index, particularly if the property in the ORDER BY clause has a high cardinality.
  • 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.All considerations for creating composite indexes for ORDER BY queries with multiple properties as well as queries with filters on multiple properties still apply.
Index compositeComposite Index Exemple ORDER BY de requêteSample ORDER BY Query Pris en charge par l’index composite ?Supported by Composite Index?
(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" 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

Modification de la stratégie d’indexationModifying the indexing policy

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.A container's indexing policy can be updated at any time by using the Azure portal or one of the supported SDKs. 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).An update to the indexing policy triggers a transformation from the old index to the new one, which is performed online and in place (so no additional storage space is consumed during the operation). L’index de l’ancienne stratégie est transformé efficacement en nouvelle stratégie, sans affecter la disponibilité d’écriture ou le débit approvisionné sur le conteneur.The old policy's index is efficiently transformed to the new policy without affecting the write availability or the throughput provisioned on the container. 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.Index transformation is an asynchronous operation, and the time it takes to complete depends on the provisioned throughput, the number of items and their size.

Notes

Pendant la réindexation, il est possible que les requêtes ne retournent pas tous les résultats correspondants et elles ne retourneront pas d’erreurs.While re-indexing is in progress, queries may not return all the matching results, and will do so without returning any errors. Cela signifie que les résultats de la requête ne seront peut-être pas cohérentes avant la fin de la transformation de l’index.This means that query results may not be consistent until the index transformation is completed. Il est possible de suivre la progression de la transformation d’index avec un des kits de développement logiciel (SDK).It is possible to track the progress of index transformation by using one of the SDKs.

Si le mode d’indexation de la nouvelle stratégie est défini sur Cohérent, aucune autre modification de la stratégie d’indexation ne peut être appliquée pendant la transformation de l’index.If the new indexing policy's mode is set to Consistent, no other indexing policy change can be applied while the index transformation is in progress. Une transformation d’index en cours d’exécution peut être annulée en définissant le mode de la stratégie d’indexation sur Aucun (ce qui supprime immédiatement l’index).A running index transformation can be canceled by setting the indexing policy's mode to None (which will immediately drop the index).

Stratégies d’indexation et TTLIndexing policies and TTL

La fonctionnalité Time-to-Live (TTL) nécessite que l’indexation soit active sur le conteneur sur lequel elle est activée.The Time-to-Live (TTL) feature requires indexing to be active on the container it is turned on. Cela signifie que :This means that:

  • il n’est pas possible d’activer TTL sur un conteneur dans lequel le mode d’indexation est défini sur Aucun ;it is not possible to activate TTL on a container where the indexing mode is set to None,
  • il n’est pas possible de définir le mode d’indexation sur Aucun sur un conteneur dans lequel TLL est activée.it is not possible to set the indexing mode to None on a container where TTL is activated.

Pour les scénarios où aucun chemin de propriété ne doit être indexé, mais où TTL est requise, vous pouvez utiliser une stratégie d’indexation avec :For scenarios where no property path needs to be indexed, but TTL is required, you can use an indexing policy with:

  • un mode d’indexation défini sur Cohérent,an indexing mode set to Consistent, and
  • sans chemin d’accès inclus et avecno included path, and
  • /* comme seul chemin exclu./* as the only excluded path.

Étapes suivantesNext steps

Pour en savoir plus sur l’indexation, consultez les articles suivants :Read more about the indexing in the following articles: