Configurations de calcul et de stockage pour les clusters vCore Azure Cosmos DB for MongoDB
S’APPLIQUE À : 
MongoDB vCore
Les ressources de calcul sont fournies en tant que vCores, représentant le processeur logique du matériel sous-jacent. La taille de stockage pour l’approvisionnement fait référence à la capacité disponible pour les partitions de votre cluster. Le stockage est utilisé pour les fichiers de base de données, les fichiers temporaires, les journaux d’activité de transaction, et les journaux d’activité du serveur de base de données. Vous pouvez sélectionner les paramètres de calcul et de stockage indépendamment. Les valeurs de calcul et de stockage sélectionnées s’appliquent à chaque partition du cluster.
Calcul dans un vCore Azure Cosmos DB for MongoDB
La quantité totale de mémoire RAM dans une seule partition est basée sur le nombre de vCores sélectionné.
| Niveau de cluster | vCores | Une partition, Gio RAM |
|---|---|---|
| M25 | 2 (Burstable) | 8 |
| M30 | 2 | 8 |
| M40 | 4 | 16 |
| M50 | 8 | 32 |
| M60 | 16 | 64 |
| M80 | 32 | 128 |
| M200 | 64 | 256 |
Stockage dans un vCore Azure Cosmos DB for MongoDB
La quantité totale de stockage que vous approvisionnez définit également la capacité d’E/S disponible sur chaque partition du cluster.
| Taille de stockage, Gio | Nombre maximal d’E/S par seconde |
|---|---|
| 32 | 3500† |
| 64 | 3500† |
| 128 | 3500† |
| 256 | 3500† |
| 512 | 3500† |
| 1 024 | 5 000 |
| 2 048 | 7 500 |
| 4 095 | 7 500 |
| 8 192 | 16 000 |
| 16 384 | 18 000 |
| 32 767 | 20 000 |
† IOPS maximal avec bursting de disque libre. Le stockage inclus jusqu’à 512 Gio est fourni avec le bursting de disque libre activé.
IOPS maximal pour votre configuration de calcul ou de stockage
Chaque configuration de calcul a une limite d’IOPS qui dépend du nombre de vCores. Veillez à sélectionner la configuration de calcul de votre cluster pour utiliser pleinement les IOPS dans le stockage sélectionné.
| Taille de stockage | IOPS de stockage, jusqu’à | Niveau de calcul minimal | Nombre minimal de vCores |
|---|---|---|---|
| Jusqu’à 0,5 Tio | 3500† | M30 | 2 vCores |
| 1 Tio | 5 000 | M40 | 4 vCores |
| 2 Tio | 7 500 | M50 | 8 vCores |
| 4 Tio | 7 500 | M50 | 8 vCores |
| 8 Tio | 16 000 | M60 | 16 vCores |
| 16 Tio | 18 000 | M60 | 16 vCores |
| 32 Tio | 20 000 | M60 | 16 vCores |
† IOPS maximal avec bursting de disque libre. Le stockage inclus jusqu’à 512 Gio est fourni avec le bursting de disque libre activé.
Par exemple, si vous avez besoin de 8 Tio de stockage par partition ou plus, veillez à sélectionner 16 vCores ou plus pour la configuration de calcul du nœud. Cette sélection vous permettrait d’optimiser l’utilisation d’IOPS fournie par le stockage sélectionné.
Considérations relatives au calcul et au stockage
Considérations relatives à l’ensemble de travail et à la mémoire
Dans un vCore Azure Cosmos DB for MongoDB, le jeu de travail fait référence à la partie de vos données fréquemment consultée et utilisée par vos applications. Il inclut à la fois les données et les index qui sont régulièrement lus ou écrits pendant les opérations classiques de l’application. Le concept d’ensemble de travail est important pour l’optimisation des performances, car MongoDB, comme de nombreuses bases de données, fonctionne au mieux lorsque la RAM peut contenir le jeu de travail.
Pour définir et comprendre le jeu de travail de votre base de données MongoDB, tenez compte des composants suivants :
- Données fréquemment consultées : ces données incluent des documents que votre application lit ou met à jour régulièrement.
- Index : les index utilisés dans les opérations de requête font également partie du jeu de travail, car ils doivent être chargés en mémoire pour garantir un accès rapide.
- Modèles d’utilisation des applications : l’analyse des modèles d’utilisation de votre application peut vous aider à identifier les parties de vos données les plus fréquemment consultées.
En conservant le jeu de travail en RAM, vous pouvez réduire les opérations d’E/S de disque plus lentes, ce qui améliore les performances de votre base de données MongoDB. Si vous constatez que votre jeu de travail dépasse la RAM disponible, vous pouvez envisager d’optimiser votre modèle de données, d’ajouter davantage de RAM ou d’utiliser le partitionnement pour distribuer les données sur plusieurs nœuds.
Choix d’une configuration optimale pour une charge de travail
La détermination de la configuration de calcul et de stockage appropriée pour votre charge de travail vCore Azure Cosmos DB for MongoDB implique l’évaluation de plusieurs facteurs liés aux exigences et aux modèles d’utilisation de votre application. Les principales étapes et considérations à prendre en compte pour déterminer la configuration optimale comprennent :
Comprendre votre charge de travail
- Volume de données : estimez la taille totale de vos données, y compris les index.
- Taux de lecture/écriture : déterminez le rapport entre les opérations de lecture et les opérations d’écriture.
- Modèles de requête : analysez les types de requêtes que votre application effectue. Par exemple, des lectures simples, des agrégations complexes.
- Concurrence : évaluez le nombre d’opérations simultanées que votre base de données doit traiter.
Surveiller les performances actuelles
- Utilisation des ressources : utilisez des outils de surveillance pour suivre l’utilisation du processeur, de la mémoire, des E/S de disque et du réseau avant de déplacer votre charge de travail vers Azure et des métriques de surveillance une fois que vous commencez à exécuter votre charge de travail MongoDB sur un cluster vCore Azure Cosmos DB for MongoDB.
- Métriques de performances : surveillez les métriques de performances clés telles que la latence, le débit et les ratios de correspondance dans le cache.
- Goulots d’étranglement : identifiez les goulots d’étranglement de performances existants, tels que l’utilisation élevée du processeur, la sollicitation de la mémoire ou les E/S de disque lentes.
Estimer les besoins en ressources
- Mémoire : assurez-vous que la RAM puisse contenir votre jeu de travail (données et index fréquemment consultés). Si la taille de votre jeu de travail dépasse la mémoire disponible, envisagez d’ajouter davantage de RAM ou d’optimiser votre modèle de données.
- Processeur : choisissez une configuration de processeur qui peut gérer vos exigences de charge de requête et de concurrence. Les charges de travail nécessitant beaucoup de processeur peuvent nécessiter davantage de cœurs. Utilisez la métrique « Pourcentage de processeur » avec l’agrégation « Max » sur votre cluster vCore Azure Cosmos DB for MongoDB pour voir les modèles d’utilisation de calcul historiques.
- IOPS de stockage : sélectionnez le stockage avec suffisamment d’IOPS pour gérer vos opérations de lecture et d’écriture. Utilisez la métrique « IOPS » avec l’agrégation « Max » sur votre cluster pour voir l’utilisation historique des IOPS de stockage.
- Réseau : assurez-vous de disposer d’une bande passante réseau adéquate pour gérer le transfert de données entre votre application et la base de données, en particulier pour les configurations distribuées. Assurez-vous que vous avez configuré l’hôte pour votre application MongoDB pour prendre en charge les technologies de performances réseau accélérées telles que SR-IOV.
Mettre à l’échelle correctement
- Mise à l’échelle verticale : mettez à l’échelle le calcul et la RAM et effectuez un scale-up du stockage.
- Calcul : augmentez le nombre de vCores ou la RAM sur un cluster si votre charge de travail nécessite une augmentation temporaire ou dépasse souvent les 70 % de l’utilisation du processeur pendant des périodes prolongées.
- Vérifiez que vous disposez d’une conservation des données appropriée dans votre base de données vCore Azure Cosmos DB for MongoDB. La rétention vous permet d’éviter l’utilisation inutile du stockage. Surveillez l’utilisation du stockage en définissant des alertes sur les métriques « Pourcentage de stockage » et/ou « Stockage utilisé » avec l’agrégation « Max ». Envisagez d’augmenter le stockage à mesure que la taille de votre charge de travail dépasse 70 % de l’utilisation.
- Mise à l’échelle horizontale : envisagez d’utiliser plusieurs partitions pour votre cluster afin de distribuer vos données sur plusieurs nœuds vCores Azure Cosmos DB for MongoDB pour des gains de performances et une meilleure gestion de la capacité à mesure que votre charge de travail augmente. Cela est particulièrement utile pour les jeux de données volumineux (plus de 2 à 4 Tio) et les applications à débit élevé.
- Mise à l’échelle verticale : mettez à l’échelle le calcul et la RAM et effectuez un scale-up du stockage.
Tester et itérer
- Benchmarking : effectuez une mesure pour les requêtes les plus fréquemment utilisées avec différentes configurations afin de déterminer l’impact sur les performances. Utilisez les métriques de processeur/RAM et d’IOPS et le benchmarking au niveau de l’application.
- Test de charge : effectuez des tests de charge pour simuler des charges de travail de production et valider les performances de votre configuration choisie.
- Surveillance continue : surveillez en continu votre déploiement vCore Azure Cosmos DB for MongoDB et ajustez les ressources selon les besoins en fonction de la modification des charges de travail et des modèles d’utilisation.
En évaluant systématiquement ces facteurs et en surveillant et en ajustant en continu votre configuration, vous pouvez vous assurer que votre déploiement MongoDB est bien optimisé pour votre charge de travail spécifique.
Considérations relatives au stockage
Le choix de la taille de stockage appropriée pour votre charge de travail implique plusieurs considérations pour garantir des performances et une scalabilité optimales. Voici les considérations relatives à la taille de stockage dans un vCore Azure Cosmos DB for MongoDB :
Taille estimée des données :
- Calculez la taille attendue de vos données vCore Azure Cosmos DB for MongoDB. Réfléchissez à ce qui suit :
- Taille actuelle des données : si vous migrez à partir d’une base de données existante.
- Taux de croissance : estimez la quantité de données ajoutée au fil du temps.
- Taille et structure des documents : comprenez votre schéma de données et les tailles de vos documents, car ils affectent l’efficacité du stockage.
- Calculez la taille attendue de vos données vCore Azure Cosmos DB for MongoDB. Réfléchissez à ce qui suit :
Facteur dans les index :
- Un vCore Azure Cosmos DB for MongoDB utilise des index pour effectuer des requêtes efficaces. Les index consomment de l’espace disque supplémentaire.
- Estimez la taille des index en fonction des éléments suivants :
- Nombre d’index.
- Taille des champs indexés.
Considérations relatives aux performances :
- Les performances du disque ont un impact sur les opérations de base de données, en particulier pour les charges de travail où la RAM ne peut pas contenir leur jeu de travail. Réfléchissez à ce qui suit :
- Débit d’E/S : IOPS, ou opérations d’entrée/sortie par seconde, correspond au nombre de requêtes envoyées aux disques de stockage en une seconde. La plus grande taille de stockage est fournie avec plus d’IOPS. Assurez-vous d’un débit adéquat pour les opérations de lecture/écriture. Utilisez la métrique « IOPS » avec l’agrégation « Max » pour surveiller les IOPS utilisées sur votre cluster.
- Latence : la latence est le temps nécessaire à une application pour recevoir une requête unique, l’envoyer aux disques de stockage et transmettre la réponse au client. La latence est une mesure critique des performances d’une application qui s’ajoute à celle des IOPS et du débit. La latence est largement définie par le type de stockage utilisé et la configuration du stockage. Dans un service managé comme Azure Cosmos DB for MongoDB, le stockage rapide tel que les disques SSD Premium est utilisé avec des paramètres optimisés pour réduire la latence.
- Les performances du disque ont un impact sur les opérations de base de données, en particulier pour les charges de travail où la RAM ne peut pas contenir leur jeu de travail. Réfléchissez à ce qui suit :
Croissance et scalabilité futures :
- Planifiez la croissance des données et les besoins de scalabilité à venir.
- Allouez davantage d’espace disque au-delà des besoins actuels pour prendre en charge la croissance sans extensions de stockage fréquentes.
Exemple de calcul :
- Supposons que la taille de vos données initiales soit de 500 Gio.
- Avec les index, elle peut atteindre 700 Gio.
- Si vous prévoyez de doubler les données en deux ans, prévoyez 1,4 Tio (700 Gio * 2).
- Ajoutez une mémoire tampon pour la surcharge, la croissance et les besoins opérationnels.
- Vous voudrez peut-être commencer avec 1 Tio de stockage aujourd’hui et mettre à l’échelle à 2 Tio une fois sa taille supérieure à 800 Gio.
La décision sur la taille de stockage combine l’estimation des besoins actuels et futurs de données, la prise en compte de l’indexation et de la compression, et la garantie de performances et de scalabilité adéquates. La surveillance et l’ajustement réguliers en fonction de l’utilisation réelle et des tendances de croissance sont également essentiels pour maintenir des performances MongoDB optimales.