Partager via

Optimiser les performances d’écriture dans Azure Cosmos DB for MongoDB

  • Article

S’APPLIQUE À : MongoDB

L’optimisation des performances en écriture vous aide à tirer le meilleur parti de la mise à l’échelle illimitée d’Azure Cosmos DB for MongoDB . Contrairement à d’autres services MongoDB gérés, l’API pour MongoDB partitionne automatiquement et de manière transparente vos collections pour vous (lors de l’utilisation de collections partitionnées) pour une mise à l’échelle infinie.

La façon dont vous écrivez des données doit prendre cela en compte par la parallélisation et en répartissant les données entre les partitions pour tirer le meilleur parti de vos bases de données et collections. Cet article explique les meilleures pratiques pour optimiser les performances d’écriture.

Répartissez la charge entre vos partitions

Lors de l’écriture de données dans une API partitionnée pour une collection MongoDB, vos données sont fractionnées (partitionnées) en tranches minuscules et elles sont écrites dans chaque partition en fonction de la valeur de votre champ de clé de partition. Vous pouvez considérer chaque secteur comme une petite partie d’une machine virtuelle qui stocke uniquement les documents contenant une valeur de clé de partition unique.

Si votre application écrit une grande quantité de données dans une seule partition, cela ne sera pas efficace, car l’application dépasserait le débit d’une seule partition au lieu de répartir la charge sur l’ensemble de vos partitions. Votre charge d’écriture sera uniformément répartie sur votre collection en écrivant en parallèle avec de nombreux documents avec des valeurs de clé de partition uniques.

Il peut s’agir, par exemple, d’une application de catalogue de produits partitionnée dans le champ catégorie. Au lieu d’écrire dans une catégorie (partition) à la fois, il est préférable d’écrire dans toutes les catégories simultanément pour atteindre le débit d’écriture maximal.

Réduire le nombre d’index

L'indexation est une fonctionnalité intéressante qui réduit considérablement le temps nécessaire à l’interrogation de vos données. Pour une expérience de requête plus flexible, l’API pour MongoDB active un index de caractères génériques sur vos données par défaut pour faire des requêtes sur tous les champs éblouissants rapidement. Toutefois, tous les index, qui incluent des index génériques, introduisent une charge supplémentaire lors de l’écriture de données, car les écritures modifient la collection et les index.

Le fait de réduire le nombre d’index aux index dont vous avez besoin pour prendre en charge vos requêtes rend vos écritures plus rapides et moins coûteuses. En règle générale, nous vous recommandons de :

  • Tout champ sur lequel vous filtrez doit avoir un index de champ unique correspondant. Cette option permet également de filtrer plusieurs champs.
  • Tout groupe de champs sur lequel vous triez doit avoir un index composite pour ce groupe.

Défini sur false dans les pilotes MongoDB

Par défaut, les pilotes MongoDB attribuent à l’option ordered la valeur true lors de l’écriture de données, qui écrit chaque document dans l’ordre un par un. Cette option réduit les performances d’écriture puisque chaque demande d’écriture doit attendre la fin de l’opération précédente. Lors de l’écriture de données, affectez la valeur false à cette option pour améliorer les performances.

db.collection.insertMany(
   [ <doc1> , <doc2>, ... ],
   {
      ordered: false
   }
)

Réglage de la taille de lot optimale et du nombre de threads

La parallélisation des opérations d’écriture sur de nombreux threads/processus est essentielle à la mise à l’échelle des écritures. L’API pour MongoDB accepte les écritures par lots allant jusqu’à 1 000 documents pour chaque processus/thread.

Si vous écrivez plus de 1 000 documents à la fois par processus/thread, les fonctions clientes telles que insertMany() doivent être limitées à environ 1 000 documents. Dans le cas contraire, le client attendra la validation de chaque lot avant de passer au traitement suivant. Dans certains cas, le fractionnement des lots avec moins ou moins de 1 000 documents est plus rapide.

Étapes suivantes