Gérer l’indexation dans Azure Cosmos DB for MongoDB

Azure Cosmos DB for MongoDB vous permet d’utiliser l’indexation pour accélérer les performances des requêtes. Cet article vous explique comment gérer et optimiser des index pour accélérer l’extraction de données et améliorer l’efficacité.

Indexation pour le serveur MongoDB versions 3.6 et ultérieures

Le serveur Azure Cosmos DB for MongoDB (versions 3.6 et ultérieures) indexe automatiquement le champ _id et la clé de partition (uniquement dans les collections partitionnées). L’API applique l’unicité du champ _id par clé de partition.

L’API pour MongoDB fonctionne différemment d’Azure Cosmos DB for NoSQL qui indexe tous les champs par défaut.

Modification de la stratégie d’indexation

Modifiez votre stratégie d’indexation dans l’Explorateur de données du Portail Azure. Ajoutez des index de champ unique et de caractères génériques à partir de l’éditeur de stratégie d’indexation dans l’Explorateur de données :

Types d’index

Champ unique

Créez un index sur n’importe quel champ unique. L’ordre de tri d’un index à champ unique n’a pas d’importance. Utilisez la commande suivante pour créer un index sur le champ name :

db.coll.createIndex({name:1})

Créez le même index de champ unique sur name dans le Portail Azure :

Une requête utilise plusieurs index de champ unique, le cas échéant. Créez jusqu’à 500 index de champ unique par collection.

Index composés (serveur MongoDB versions 3.6 et ultérieures)

Dans l’API pour MongoDB, utilisez des index composés avec des requêtes qui trient plusieurs champs en même temps. Pour les requêtes comportant plusieurs filtres qui n’ont pas besoin de tri, créez plusieurs index monochamp au lieu d’un index composé afin de réduire les coûts d’indexation.

Un index composé ou des index de champ unique pour chaque champ de l’index composé entraînent les mêmes performances pour le filtrage dans les requêtes.

Les index composés sur des champs imbriqués ne sont pas pris en charge par défaut en raison des limitations liées aux tableaux. Si un champ imbriqué n’a pas de tableau, l’index fonctionne comme prévu. Si un champ imbriqué comprend un tableau n’importe où sur le chemin d’accès, cette valeur est ignorée dans l’index.

Par exemple, un index composé comprenant people.dylan.age fonctionne dans ce cas, car il n’existe aucun tableau sur le chemin d’accès :

{
  "people": {
    "dylan": {
      "name": "Dylan",
      "age": "25"
    },
    "reed": {
      "name": "Reed",
      "age": "30"
    }
  }
}

Le même index composé ne fonctionne pas dans ce cas, car il existe un tableau dans le chemin d’accès :

{
  "people": [
    {
      "name": "Dylan",
      "age": "25"
    },
    {
      "name": "Reed",
      "age": "30"
    }
  ]
}

Activez cette fonctionnalité pour votre compte de base de données en activant la fonctionnalité « EnableUniqueCompoundNestedDocs ».

La commande suivante crée un index composé sur les champs name et age :

db.coll.createIndex({name:1,age:1})

Vous pouvez utiliser des index composés pour effectuer un tri efficace sur plusieurs champs à la fois, comme illustré dans l’exemple suivant :

db.coll.find().sort({name:1,age:1})

L’index composé précédent peut également être utilisé pour un tri efficace sur une requête avec l’ordre de tri inverse sur tous les champs. Voici un exemple :

db.coll.find().sort({name:-1,age:-1})

Toutefois, la séquence des chemins dans l’index composé doit correspondre exactement à la requête. Voici un exemple de requête qui nécessitera un index composé additionnel :

db.coll.find().sort({age:1,name:1})

Index multiclés

Azure Cosmos DB crée des index à plusieurs clés pour indexer le contenu dans des tableaux. Si vous indexez un champ avec une valeur de tableau, Azure Cosmos DB indexe automatiquement chaque élément dans le tableau.

Index géospatiaux

De nombreux opérateurs géospatiaux tirent profit des index géospatiaux. Azure Cosmos DB for MongoDB prend en charge les index 2dsphere. L’API ne prend pas encore en charge les index 2d.

Voici un exemple de création d’index géospatial sur le champ location :

db.coll.createIndex({ location : "2dsphere" })

Indices de texte

Azure Cosmos DB for MongoDB ne prend pas en charge les index de texte. Pour les requêtes de recherche de texte sur des chaînes, utilisez l’intégration de Recherche Azure AI à Azure Cosmos DB.

Index génériques

Utilisez des index de caractères génériques pour prendre en charge les requêtes sur des champs inconnus. Imaginez une collection qui contient des données concernant les familles.

Voici une partie d’un exemple de document dans cette collection :

"children": [
  {
    "firstName": "Henriette Thaulow",
    "grade": "5"
  }
]

Voici un autre exemple avec un ensemble différent de propriétés dans children :

"children": [
  {
    "familyName": "Merriam",
    "givenName": "Jesse",
    "pets": [
      { "givenName": "Goofy" },
      { "givenName": "Shadow" }
    ]
  },
  {
    "familyName": "Merriam",
    "givenName": "John",
  }
]

Les documents de cette collection peuvent avoir plusieurs propriétés différentes. Pour indexer toutes les données du tableau children, créez des index distincts pour chaque propriété ou créez un index de caractères génériques pour l’ensemble du tableau children.

Créer un index générique

Utilisez la commande suivante pour créer un index de caractères génériques sur toutes les propriétés dans children :

db.coll.createIndex({"children.$**" : 1})

• Contrairement à MongoDB, les index génériques peuvent prendre en charge plusieurs champs dans les prédicats de requête. Il n’existe aucune différence dans les performances des requêtes si vous utilisez un seul index de caractères génériques au lieu de créer un index distinct pour chaque propriété.

Créez les types d’index suivants en utilisant une syntaxe de caractères génériques :

• Champ unique
• Géospatial

Indexation de toutes les propriétés

Créez un index de caractères génériques sur tous les champs avec la commande suivante :

db.coll.createIndex( { "$**" : 1 } )

Créez des index de caractères génériques en tirant parti de l’Explorateur de données dans le Portail Azure :

Les documents avec de nombreux champs peuvent avoir des frais élevés d’unité de requête (RU) pour les écritures et les mises à jour. Si vous avez une charge de travail nécessitant beaucoup d’écritures, utilisez des chemins d’accès indexés individuellement au lieu de caractères génériques.

Limites

Les index génériques ne prennent en charge aucun des types ou propriétés d’index suivants :

• Composé

• TTL

• Unique

• Contrairement à MongoDB, dans Azure Cosmos DB for MongoDB, vous ne pouvez pas utiliser d’index de caractères génériques pour :

• Création d’un index joker incluant plusieurs champs spécifiques

  db.coll.createIndex(
    { "$**" : 1 },
    { "wildcardProjection " :
      {
        "children.givenName" : 1,
        "children.grade" : 1
      }
    }
  )
  

• Création d’un index générique excluant plusieurs champs spécifiques

  db.coll.createIndex(
    { "$**" : 1 },
    { "wildcardProjection" :
      {
        "children.givenName" : 0,
        "children.grade" : 0
      }
    }
  )
  

En guise d’alternative, créez plusieurs index de caractères génériques.

Propriétés d’index

Les opérations suivantes sont courantes pour les comptes utilisant le protocole filaire version 4.0 et les versions antérieures. Découvrez plus d’informations sur les index pris en charge et les propriétés indexées.

Index uniques

Les index uniques permettent de s’assurer que deux documents ou plus n’ont pas la même valeur pour les champs indexés.

Exécutez la commande suivante pour créer un index unique sur le champ student_id :

db.coll.createIndex( { "student_id" : 1 }, {unique:true} )

{
  "_t" : "CreateIndexesResponse",
  "ok" : 1,
  "createdCollectionAutomatically" : false,
  "numIndexesBefore" : 1,
  "numIndexesAfter" : 4
}

Pour les collections shardées, fournissez la clé de partition (partition) pour créer un index unique. Tous les index uniques d’une collection shardée sont des index composés et l’un des champs est la clé de partition. La clé de partition doit correspondre au premier champ de la définition d’index.

Exécutez les commandes suivantes pour créer une collection shardée nommée coll (avec university comme clé de partition) et un index unique sur les champs et student_id les university :

db.runCommand({shardCollection: db.coll._fullName, key: { university: "hashed"}});
{
  "_t" : "ShardCollectionResponse",
  "ok" : 1,
  "collectionsharded" : "test.coll"
}

db.coll.createIndex( { "university" : 1, "student_id" : 1 }, {unique:true});
{
  "_t" : "CreateIndexesResponse",
  "ok" : 1,
  "createdCollectionAutomatically" : false,
  "numIndexesBefore" : 3,
  "numIndexesAfter" : 4
}

Si vous omettez la clause "university":1 dans l’exemple précédent, le message d’erreur suivant s’affiche :

cannot create unique index over {student_id : 1.0} with shard key pattern { university : 1.0 }

Limites

Créez des index uniques alors que la collection est vide.

Les comptes Azure Cosmos DB pour MongoDB avec sauvegarde continue ne prennent pas en charge la création d’un index unique pour une collection existante. Pour ce compte, les index uniques doivent être créés en même temps que la collection, et cela doit être effectué uniquement à l’aide des commandes d’extension pour la création de collections.

db.runCommand({customAction:"CreateCollection", collection:"coll", shardKey:"student_id", indexes:[
{key: { "student_id" : 1}, name:"student_id_1", unique: true}
]});

Les index uniques sur les champs imbriqués ne sont pas pris en charge par défaut en raison de limitations avec des tableaux. Si votre champ imbriqué n’a pas de tableau, l’index fonctionne comme prévu. Si votre champ imbriqué a un tableau n’importe où sur le chemin d’accès, cette valeur est ignorée dans l’index unique et l’unicité n’est pas conservée pour cette valeur.

Par exemple, un index unique sur people.tom.age fonctionne dans ce cas, car il n’existe aucun tableau sur le chemin d’accès :

{
  "people": {
    "tom": {
      "age": "25"
    },
    "mark": {
      "age": "30"
    }
  }
}

Mais ne fonctionne pas dans ce cas, car il existe un tableau dans le chemin d’accès :

{
  "people": {
    "tom": [
      {
        "age": "25"
      }
    ],
    "mark": [
      {
        "age": "30"
      }
    ]
  }
}

Vous pouvez activer cette fonctionnalité pour votre compte de base de données en activant la fonctionnalité « EnableUniqueCompoundNestedDocs ».

Index TTL

Pour permettre à des documents d’expirer dans une collection, créez un index de durée de vie (TTL). Un index TTL est un index sur le champ _ts avec une valeur expireAfterSeconds.

Exemple :

db.coll.createIndex({"_ts":1}, {expireAfterSeconds: 10})

La commande précédente supprime tous les documents de la collection db.coll qui ont été modifiés il y a plus de 10 secondes.

Suivre la progression de l’index

La version 3.6+ d’Azure Cosmos DB for MongoDB prend en charge la commande currentOp() pour suivre la progression de l’index sur une instance de base de données. Cette commande retourne un document contenant des informations sur les opérations en cours sur une instance de base de données. Utilisez la commande currentOp pour suivre toutes les opérations en cours dans l’instance MongoDB native. Dans Azure Cosmos DB for MongoDB, cette commande suit uniquement l’opération d’index.

Voici quelques exemples d’utilisation de la commande currentOp pour suivre la progression de l’index :

• Obtenez la progression de l’index pour une collection :

  db.currentOp({"command.createIndexes": <collectionName>, "command.$db": <databaseName>})
  

• Obtenez la progression de l’index de toutes les collections d’une base de données :

  db.currentOp({"command.$db": <databaseName>})
  

• Obtenez la progression de l’index de toutes les bases de données et collections dans un compte Azure Cosmos DB :

  db.currentOp({"command.createIndexes": { $exists : true } })
  

Exemples de sortie de la progression d’index

Les informations sur la progression de l’index indiquent le pourcentage de progression de l’opération d’index actuelle. Voici des exemples du format de document de sortie pour diverses étapes de progression de l’index :

• Une opération d’index sur une collection « foo » et une base de données « bar » de 60 pour cent comporte le document de sortie suivant. Le champ Inprog[0].progress.total affiche 100 comme pourcentage d’achèvement cible.

  {
    "inprog": [
      {
        ...
        "command": {
          "createIndexes": foo
          "indexes": [],
          "$db": bar
        },
        "msg": "Index Build (background) Index Build (background): 60 %",
        "progress": {
          "done": 60,
          "total": 100
        },
        ...
      }
    ],
    "ok": 1
  }
  

• Si une opération d’index vient de démarrer sur une collection « foo » et une base de données « bar », le document de sortie peut afficher une progression de 0 % jusqu’à ce qu’il atteigne un niveau mesurable.

  {
    "inprog": [
      {
        ...
        "command": {
          "createIndexes": foo
          "indexes": [],
          "$db": bar
        },
        "msg": "Index Build (background) Index Build (background): 0 %",
        "progress": {
          "done": 0,
          "total": 100
        },
        ...
      }
    ],
    "ok": 1
  }
  

• Une fois l’opération d’index terminée, le document de sortie affiche des opérations inprog vides.

  {
    "inprog" : [],
    "ok" : 1
  }
  

Mises à jour d’index en arrière-plan

Les mises à jour d’index s’exécutent toujours en arrière-plan, quelle que soit la valeur que vous définissez pour la propriété d’index Arrière-plan. Étant donné que les mises à jour d’index utilisent des unités de requête (RU) à une priorité inférieure à d’autres actions de base de données, les modifications apportées à l’index n’entraînent pas de temps d’arrêt pour les écritures, les mises à jour ou les suppressions.

L’ajout d’un nouvel index n’affecte pas la disponibilité des lectures. Les requêtes utilisent de nouveaux index uniquement une fois la transformation d’index terminée. Pendant la transformation, le moteur de requête continue d’utiliser des index existants. Vous constatez donc des performances en lecture similaires avant de commencer la modification de l’indexation. L’ajout de nouveaux index n’entraîne pas de résultats de requête incomplets ou incohérents.

Si vous supprimez des index et exécutez immédiatement des requêtes filtrant sur ces index supprimés, les résultats peuvent être incohérents et incomplets jusqu’à ce que la transformation d’index se termine. Le moteur de requête ne fournit pas de résultats cohérents ou complets pour les requêtes qui filtrent sur les index nouvellement supprimés. La plupart des développeurs ne suppriment pas les index et les interrogent ensuite immédiatement. Cette situation est donc peu probable.

Commande reIndex

La commande reIndex recrée tous les index sur une collection. Dans de rares cas, l’exécution de la commande reIndex peut corriger les performances des requêtes ou d’autres problèmes d’index dans votre collection. Si vous rencontrez des problèmes d’indexation, essayez de recréer les index avec la commande reIndex.

Exécutez la commande reIndex en utilisant la syntaxe suivante :

db.runCommand({ reIndex: <collection> })

Utilisez la syntaxe suivante pour vérifier si l’exécution de la commande reIndex améliore les performances des requêtes dans votre collection :

db.runCommand({"customAction":"GetCollection",collection:<collection>, showIndexes:true})

Exemple de sortie :

{
  "database": "myDB",
  "collection": "myCollection",
  "provisionedThroughput": 400,
  "indexes": [
    {
      "v": 1,
      "key": {
        "_id": 1
      },
      "name": "_id_",
      "ns": "myDB.myCollection",
      "requiresReIndex": true
    },
    {
      "v": 1,
      "key": {
        "b.$**": 1
      },
      "name": "b.$**_1",
      "ns": "myDB.myCollection",
      "requiresReIndex": true
    }
  ],
  "ok": 1
}

Si reIndex améliore les performances des requêtes, requiresReIndex est vrai. Si reIndex n’améliore pas les performances des requêtes, cette propriété est omise.

Migrer des collections avec des index

Vous ne pouvez créer des index uniques que lorsque la collection n’a aucun document. Les outils de migration MongoDB populaires tentent de créer des index uniques après l’importation des données. Pour contourner ce problème, créez manuellement les collections correspondantes et les index uniques au lieu de laisser l’outil de migration essayer. Vous obtenez ce comportement pour mongorestore en utilisant l’indicateur --noIndexRestore dans la ligne de commande.

Indexation pour MongoDB version 3.2

Les valeurs par défaut et fonctionnalités d’indexation diffèrent pour les comptes Azure Cosmos DB qui utilisent la version 3.2 du protocole filaire MongoDB. Vérifiez la version de votre compte à l’adresse feature-support-36.md#protocol-support, puis effectuez une mise à niveau vers la version 3.6 sur upgrade-version.md.

Si vous utilisez la version 3.2, cette section met en évidence les principales différences des versions 3.6 et ultérieures.

Suppression des index par défaut (version 3.2)

Contrairement aux versions 3.6 et ultérieures, Azure Cosmos DB for MongoDB version 3.2 indexe chaque propriété par défaut. Utilisez la commande suivante afin de supprimer ces index par défaut pour une collection (coll) :

db.coll.dropIndexes()

{ "_t" : "DropIndexesResponse", "ok" : 1, "nIndexesWas" : 3 }

Une fois les index par défaut supprimés, ajoutez d’autres index comme vous le faites dans la version 3.6 ou versions ultérieures.

Index composés (version 3.2)

Les index composés référencent plusieurs champs d’un document. Pour créer un index composé, effectuez une mise à niveau vers la version 3.6 ou 4.0 sur upgrade-version.md.

Index génériques (version 3.2)

Pour créer un index de caractères génériques, effectuez une mise à niveau vers la version 4.0 ou 3.6 sur upgrade-version.md.

Étapes suivantes

• Indexation dans Azure Cosmos DB
• Faire expirer automatiquement des données avec la durée de vie dans Azure Cosmos DB