ApsaraDB for MongoDB:Problèmes de performance liés à un nombre excessif de bases de données et de collections

Supprimer les collections inutiles

Identifiez les collections de la base de données pouvant être supprimées, telles que celles qui ont expiré ou qui ne sont plus utilisées. Utilisez la commande dropCollection pour les supprimer. Pour plus d'informations, reportez-vous à dropCollection().

Utilisez les commandes suivantes pour consulter les informations relatives aux bases de données et aux collections :

• Exécutez la commande suivante pour afficher le nombre de collections dans une base de données.

  db.getSiblingDB(<dbName>).getCollectionNames().length

• Exécutez la commande suivante pour afficher les informations détaillées d'une base de données, y compris le nombre de collections, d'index et de documents, ainsi que la taille totale des données.

  // View statistics for a specific database.
  db.getSiblingDB(<dbName>).stats()

• Exécutez la commande suivante pour afficher les informations détaillées d'une collection spécifique.

  // View statistics for a specific collection.
  db.getSiblingDB(<dbName>).<collectionName>.stats()

Supprimer les index inutiles

La réduction du nombre d'index diminue également le nombre de fichiers sur disque et les structures dhandle correspondantes maintenues par le moteur de stockage WiredTiger, ce qui permet d'atténuer ce problème.

Respectez les principes de base suivants pour l'optimisation des index :

• Évitez les index inutilisés

  Si une requête n'accède jamais à un champ spécifique, tout index sur ce champ ne sera pas utilisé. Ces index sont considérés comme inutilisés et peuvent être supprimés.

• Suivez les règles de préfixe d'index

  Par exemple, si vous disposez à la fois des index {a:1} et {a:1,b:1}, le premier index constitue un préfixe redondant du second et peut être supprimé.

• Prenez en compte l'ordre des champs d'index pour les requêtes d'égalité

  Pour les correspondances d'égalité, l'ordre des champs dans un index composite n'a pas d'importance. Par exemple, pour les requêtes sur les champs a et b, les index {a:1,b:1} et {b:1,a:1} sont fonctionnellement équivalents. Vous pouvez supprimer celui qui est le moins fréquemment utilisé.

• Appliquez la règle ESR pour les requêtes de plage

  Pour construire un index composite optimal pour vos requêtes, organisez les champs dans l'ordre Equality, Sort, Range (Égalité, Tri, Plage). Pour plus d'informations, reportez-vous à The ESR (Equality, Sort, Range) Rule.

• Examinez les index avec un faible taux d'utilisation

  Un index avec un faible taux d'utilisation chevauche souvent un index plus efficace. Analysez tous les modèles de requête pertinents pour déterminer si vous pouvez le supprimer en toute sécurité.

Vous pouvez utiliser l'étape d'agrégation $indexStats de MongoDB pour afficher les statistiques de tous les index d'une collection. Assurez-vous de disposer des autorisations nécessaires avant d'exécuter la commande suivante.

// View index statistics for a specific collection.
db.getSiblingDB(<dbName>).<collectionName>.aggregate({"$indexStats":{}})

La commande renvoie une sortie similaire à l'exemple suivant.

{
   "name" : "item_1_quantity_1",
   "key" : { "item" : 1, "quantity" : 1 },
   "host" : "examplehost.local:27018",
   "accesses" : {
      "ops" : NumberLong(1),
      "since" : ISODate("2020-02-10T21:11:23.059Z")
   }
}

Le tableau suivant décrit les paramètres des informations renvoyées.

Si vous constatez qu'un index présente un très faible taux d'utilisation, par exemple si accesses.ops est égal à 1, il s'agit probablement d'un index redondant ou inutilisé que vous pouvez envisager de supprimer. Si votre instance MongoDB est en version 4.4 ou ultérieure, vous pouvez utiliser la commande hideIndex pour masquer l'index avant de le supprimer. Cela vous permet de confirmer l'absence d'impact négatif sur votre application pendant une certaine période, réduisant ainsi le risque lié à la suppression de l'index.

// players collection
{
  "_id": "ObjectId(123)",
  "first_name": "John",
  "last_name": "Doe",
  "coins": 11,
  "stars": 2
}

Consolider les données de plusieurs collections

Consolidez les données de plusieurs collections dans une seule collection afin de réduire le nombre total de collections.

Par exemple, une base de données nommée temperatures stocke les données de température provenant de capteurs. Un capteur fonctionne de 10 h 00 à 22 h 00, en lisant et en stockant les données de température toutes les demi-heures. Il stocke les données de température de chaque jour dans une collection distincte nommée d'après la date.

Les extraits suivants montrent des données partielles de deux collections, temperatures.march-09-2020 et temperatures.march-10-2020.

• Collection temperatures.march-09-2020

  {
    "_id": 1,
    "timestamp": "2020-03-09T010:00:00Z",
    "temperature": 29
  }
  {
    "_id": 2,
    "timestamp": "2020-03-09T010:30:00Z",
    "temperature": 30
  }
  ...
  {
    "_id": 25,
    "timestamp": "2020-03-09T022:00:00Z",
    "temperature": 26
  }

• Collection temperatures.march-10-2020

  {
    "_id": 1,
    "timestamp": "2020-03-10T010:00:00Z",
    "temperature": 30
  }
  {
    "_id": 2,
    "timestamp": "2020-03-10T010:30:00Z",
    "temperature": 32
  }
  ...
  {
    "_id": 25,
    "timestamp": "2020-03-10T022:00:00Z",
    "temperature": 28
  }
  

Au fil du temps, le nombre de collections dans la base de données augmente. Étant donné que MongoDB n'impose pas de limite stricte au nombre de collections et que ce modèle ne dispose pas d'une politique claire de cycle de vie des données, le nombre de collections et leurs index correspondants augmentent indéfiniment.

Outre le problème du nombre toujours croissant de collections, ce modèle de données rend difficile l'exécution de requêtes s'étendant sur plusieurs jours. Pour interroger des données sur plusieurs jours afin d'analyser les tendances de température à long terme, vous devrez utiliser des requêtes $lookup, qui sont moins performantes que les requêtes au sein d'une seule collection.

Un meilleur modèle de données consiste à stocker toutes les lectures de température dans une seule collection, les données de chaque jour étant stockées dans un seul document. Cette approche est un exemple du modèle Bucket (Bucket Pattern). L'exemple suivant montre le modèle optimisé.

// temperatures.readings
{
  "_id": ISODate("2020-03-09"),
  "readings": [
    {
      "timestamp": "2020-03-09T010:00:00Z",
      "temperature": 29
    },
    {
      "timestamp": "2020-03-09T010:30:00Z",
      "temperature": 30
    },
    ...
    {
      "timestamp": "2020-03-09T022:00:00Z",
      "temperature": 26
    }
  ]
}
{
  "_id": ISODate("2020-03-10"),
  "readings": [
    {
      "timestamp": "2020-03-10T010:00:00Z",
      "temperature": 30
    },
    {
      "timestamp": "2020-03-10T010:30:00Z",
      "temperature": 32
    },
    ...
    {
      "timestamp": "2020-03-10T022:00:00Z",
      "temperature": 28
    }
  ]
}

Le modèle optimisé consomme beaucoup moins de ressources que le modèle original. Vous n'avez plus besoin de créer des index basés sur l'heure de la journée et l'index _id par défaut de la collection facilite les requêtes par date. Cela résout également le problème du nombre illimité de collections.

Diviser l'instance

Si vous ne pouvez pas réduire le nombre total de bases de données et de collections au sein d'une seule instance MongoDB, envisagez une division logique de l'instance de base de données, accompagnée des modifications correspondantes dans votre application.

Vous pouvez aborder cette situation selon deux scénarios :

Migrer vers un cluster fragmenté avec des tags de shard

Si toutes vos collections se trouvent dans une seule base de données et que vous souhaitez les gérer comme une seule instance logique, envisagez de migrer vos données vers une architecture de cluster fragmenté et d'utiliser des tags de shard pour la gestion. La méthode de gestion par tags de shard est légèrement plus complexe et nécessite des étapes opérationnelles supplémentaires (utilisation de sh.addShardTag et de sh.addTagRange). Cependant, une seule instance MongoDB gère toujours toutes les collections, ce qui nécessite des modifications minimales dans votre application. Vous devez simplement remplacer la chaîne de connexion par celle de la nouvelle instance de cluster fragmenté.

Par exemple, si votre instance comporte 100 000 collections actives, vous pouvez acheter une nouvelle instance de cluster fragmenté à 10 shards. Suivez le processus ci-dessous pour configurer l'instance et migrer les données, ce qui donnera 10 000 collections actives par shard. La procédure est la suivante :

1. Achetez une nouvelle instance de cluster fragmenté. Cet exemple utilise une instance à 2 shards. Pour obtenir des instructions sur la création d'un cluster fragmenté, reportez-vous à Créer une instance de cluster fragmenté.

2. Connectez-vous au nœud mongos de l'instance de cluster fragmenté. Pour plus d'informations, reportez-vous à Se connecter à une instance de cluster fragmenté ApsaraDB for MongoDB à l'aide du shell mongo.

3. Exécutez les commandes suivantes pour ajouter un tag de shard à chaque shard.

   sh.addShardTag("d-xxxxxxxxx1", "shard_tag1")
   sh.addShardTag("d-xxxxxxxxx2", "shard_tag2")

   Remarque

   • Avant d'exécuter ces commandes, assurez-vous que le compte que vous utilisez dispose des autorisations requises.

   • DMS (Data Management) ne prend pas actuellement en charge la commande sh.addShardTag. Nous vous recommandons de vous connecter à l'instance avec le shell mongo ou mongosh pour exécuter ces commandes.

4. Préconfigurez les règles de distribution de plage basées sur les tags pour toutes les collections fragmentées.

   use <dbName>
   sh.enableSharding("<dbName>")
   sh.addTagRange("<dbName>.test", {"_id":MinKey}, {"_id":MaxKey}, "shard_tag1")
   sh.addTagRange("<dbName>.test1", {"_id":MinKey}, {"_id":MaxKey}, "shard_tag2")

   Cet exemple utilise _id comme clé de fragmentation. Choisissez une clé de fragmentation adaptée à votre charge de travail et assurez-vous que toutes les opérations de requête incluent le champ de clé de fragmentation. La clé de fragmentation doit être cohérente avec le champ utilisé à l'étape suivante. Vous devez également utiliser les limites [MinKey,MaxKey] pour garantir que toutes les données d'une seule collection résident sur un seul shard.

5. Exécutez l'opération shardCollection pour toutes les collections à migrer.

   sh.shardCollection("<dbName>.test", {"_id":1})
   sh.shardCollection("<dbName>.test1", {"_id":1})

6. Exécutez la commande sh.status() pour confirmer que les règles sont effectives.

   zhongli.test
           shard key: { "_id" : 1 }
           unique: false
           balancing: true
           chunks:
                   d-xxx	1
           { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : d-xxx Timestamp(1, 0)
            tag: shard_tag1  { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } }
   zhongli.test1
           shard key: { "_id" : 1 }
           unique: false
           balancing: true
           chunks:
                   d-xxx	1
           { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : d-xxx Timestamp(1, 0)
            tag: shard_tag2  { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } }

7. Migrer des données d'une instance de jeu de réplicas vers une instance de cluster fragmenté.

   Remarque

   Étant donné que vous avez déjà pré-fragmenté les collections sur l'instance de destination, toutes les informations sur les bases de données et les collections existent déjà. Par conséquent, vous devez définir le Processing Mode of Conflicting Tables sur Ignore Errors and Proceed dans votre tâche DTS.

8. Après avoir vérifié la cohérence des données, configurez vos applications pour accéder à la nouvelle instance de cluster fragmenté.

Migrer vers un cluster fragmenté avec des zones

Cette méthode est similaire à l'utilisation des tags de shard, mais elle utilise la fonctionnalité Zones de MongoDB. Elle nécessite des étapes opérationnelles supplémentaires, notamment sh.addShardToZone() et sh.updateZoneKeyRange().

La procédure est la suivante :

1. Achetez une nouvelle instance de cluster fragmenté. Cet exemple utilise une instance à 2 shards. Pour obtenir des instructions sur la création d'un cluster fragmenté, reportez-vous à Créer une instance de cluster fragmenté.

2. Connectez-vous au nœud mongos de l'instance de cluster fragmenté. Pour plus d'informations, reportez-vous à Se connecter à une instance de cluster fragmenté ApsaraDB for MongoDB à l'aide du shell mongo.

3. Exécutez les commandes suivantes pour assigner chaque shard à une zone.

   sh.addShardToZone("d-xxxxxxxxx1", "ZoneA")
   sh.addShardToZone("d-xxxxxxxxx2", "ZoneB")

   Remarque

   • Avant d'exécuter ces commandes, assurez-vous que le compte que vous utilisez dispose des autorisations requises.

   • DMS ne prend pas actuellement en charge la commande sh.addShardToZone. Nous vous recommandons de vous connecter à l'instance avec le shell mongo ou mongosh pour exécuter ces commandes.

4. Préconfigurez les règles de distribution de plage basées sur les zones pour toutes les collections.

   use <dbName>
   sh.enableSharding("<dbName>")
   sh.updateZoneKeyRange("<dbName>.test", { "_id": MinKey }, { "_id": MaxKey }, "ZoneA")
   sh.updateZoneKeyRange("<dbName>.test1", { "_id": MinKey }, { "_id": MaxKey }, "ZoneB")

   Cet exemple utilise _id comme clé de fragmentation. Choisissez une clé de fragmentation adaptée à votre charge de travail et assurez-vous que toutes les opérations de requête incluent le champ de clé de fragmentation. La clé de fragmentation doit être cohérente avec le champ utilisé à l'étape suivante. Vous devez également utiliser les limites [MinKey,MaxKey] pour garantir que toutes les données d'une seule collection résident sur un seul shard.

5. Exécutez l'opération shardCollection pour toutes les collections à migrer.

   sh.shardCollection("<dbName>.test", { "_id": 1 })
   sh.shardCollection("<dbName>.test1", { "_id": 1 })

6. Exécutez la commande sh.status() pour afficher la distribution du sharding et confirmer que la configuration de zone est effective. La sortie d'exemple est la suivante :

   {  "_id" : "shardDistributionDB",  "primary" : "d-xxx24",  "partitioned" : false,  "version" : {  "uuid" : UUID("1dc635xxx"),  "lastMod" : 1 } }
           shardDistributionDB.test
                   shard key: { "_id" : "hashed" }
                   unique: false
                   balancing: true
                   chunks:
                           d-2ze9797089ef3704      1
                   { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : d-xxx04 Timestamp(1, 0)
                    tag: ZoneA  { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } }
           shardDistributionDB.test1
                   shard key: { "_id" : "hashed" }
                   unique: false
                   balancing: true
                   chunks:
                           d-2zed2e752c35af24      1
                   { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } } on : d-xxx24 Timestamp(1, 0)
                    tag: ZoneB  { "_id" : { "$minKey" : 1 } } -->> { "_id" : { "$maxKey" : 1 } }

7. Migrer des données d'une instance de jeu de réplicas vers une instance de cluster fragmenté.

   Remarque

   Étant donné que vous avez déjà pré-fragmenté les collections sur l'instance de destination, toutes les informations sur les bases de données et les collections existent déjà. Par conséquent, vous devez définir le Processing Mode of Conflicting Tables sur Ignore Errors and Proceed dans votre tâche DTS.

8. Après avoir vérifié la cohérence des données, configurez vos applications pour accéder à la nouvelle instance de cluster fragmenté.