Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Les ressources de calcul Azure DocumentDB sont fournies en tant que vCores, qui représentent 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 des transactions et les journaux 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 Azure DocumentDB
La quantité totale de RAM dans une seule partition est basée sur le nombre sélectionné de vCores.
| Niveau de cluster | vCores | Une partition, Gio RAM |
|---|---|---|
| M10 | 1 (Burstable) | 2 |
| M20 | 2 (Burstable) | 4 |
| M25 | 2 (Burstable) | 8 |
| M30 | 2 | 8 |
| M40 | 4 | 16 |
| M50 | 8 | 32 |
| M60 | 16 | 64 |
| M80 | 32 | 128 |
| M200 | 64 | 256 |
Stockage dans Azure DocumentDB
La quantité totale de stockage que vous affectez définit également la capacité d’E/S disponible pour chaque partition du cluster.
| Taille de stockage, Gio | Nombre maximal d’E/S par seconde |
|---|---|
| 32 | 3,500† |
| 64 | 3,500† |
| 128 | 3,500† |
| 256 | 3,500† |
| 512 | 3,500† |
| 1,024 | 5 000 |
| 2 048 | 7 500 |
| 4,095 | 7 500 |
| 8,192 | 16 000 |
| 16 384 | 18 000 |
| 32 767 | 20 000 |
† Opérations d’entrée/sortie par seconde (IOPS) maximales avec bursting de disque gratuit. Le stockage inclus jusqu’à 512 Gio est fourni avec le bursting de disque libre activé.
Optimiser les IOPS pour votre configuration de calcul et 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 E/S par seconde dans le stockage sélectionné.
| Taille de stockage | IOPS de stockage, jusqu’à | Niveau de calcul minimal | Nombre minimal de vCores |
|---|---|---|---|
| Jusqu’à 0,5 Tio | 3,500† | 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 des IOPS fournies par le stockage sélectionné.
Considérations relatives au calcul et au stockage
Lors de la configuration de votre cluster Azure DocumentDB, il est important de comprendre comment les choix de calcul et de stockage affectent les performances, le coût et l’extensibilité de votre charge de travail spécifique.
Considérations relatives à l’ensemble de travail et à la mémoire
Dans Azure DocumentDB, le jeu de travail fait référence à la partie de vos données fréquemment consultées et utilisées 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’un ensemble de travail est important pour l’optimisation des performances, car MongoDB, comme de nombreuses bases de données, fonctionne le mieux lorsque le jeu de travail s’adapte à la RAM.
Pour définir et comprendre votre jeu de travail de 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 accessibles.
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 votre jeu de travail dépasse la RAM disponible, envisagez d’optimiser votre modèle de données, d’ajouter davantage de RAM à votre cluster ou d’utiliser le partitionnement pour distribuer des données sur plusieurs nœuds.
Choisir 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 Azure DocumentDB 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 sont les suivantes :
Comprendre votre charge de travail
- Volume de données : estimer la taille totale de vos données, y compris les index.
- Taux de lecture/écriture : déterminez le ratio des opérations de lecture avec des 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 dont votre base de données a besoin pour gérer.
Surveiller les performances actuelles
- Utilisation des ressources : utilisez des outils de supervision pour suivre l’utilisation du processeur, de la mémoire, des E/S de disque et du réseau avant de migrer votre charge de travail vers Azure. Après avoir déployé votre charge de travail MongoDB sur un cluster Azure DocumentDB, poursuivez la surveillance à l’aide des métriques de supervision Azure.
- Métriques de performances : surveillez les métriques de performances clés telles que la latence, le débit et les ratios d’accès au cache.
- Goulots d’étranglement : identifiez les goulots d’étranglement de performances existants, tels que l’utilisation élevée du processeur, la pression de la mémoire ou les E/S de disque lentes.
Estimer les besoins en ressources
- Mémoire : assurez-vous que votre jeu de travail (données et index fréquemment consultés) s’intègre à la RAM. Si la taille de votre ensemble de travail dépasse la mémoire RAM disponible, envisagez d’ajouter plus 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 intensives en processeur peuvent nécessiter davantage de cœurs. Pour consulter l’historique des modèles d’utilisation des ressources de calcul, utilisez la métrique « Pourcentage du processeur » avec l’agrégation « Max » sur votre cluster Azure DocumentDB.
- 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 qu'une bande passante réseau suffisante est disponible 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 mise en réseau accélérées telles que SR-IOV.
Mettre à l’échelle correctement
-
Mise à l’échelle verticale : ajuste la puissance de calcul et la mémoire vive (RAM) à la hausse et à la baisse, et augmente le stockage.
- Calcul : augmentez le vCore/RAM sur un cluster si votre charge de travail nécessite une augmentation temporaire ou dépasse souvent plus de 70% d’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 Azure DocumentDB. 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 % d'utilisation.
- Mise à l’échelle horizontale : envisagez d’utiliser plusieurs partitions pour votre cluster afin de distribuer vos données sur plusieurs nœuds Azure DocumentDB pour des gains de performances et une meilleure gestion de la capacité à mesure que votre charge de travail augmente. Cette mise à l’échelle 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 : ajuste la puissance de calcul et la mémoire vive (RAM) à la hausse et à la baisse, et augmente le stockage.
Tester et itérer
- Benchmark : effectuez une mesure pour les requêtes les plus fréquemment utilisées avec différentes configurations pour déterminer l’effet sur les performances. Utilisez les métriques UC/RAM et IOPS et l’évaluation 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 Azure DocumentDB 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 Azure DocumentDB :
Estimer la taille des données :
- Calculez la taille attendue de vos données Azure DocumentDB. Tenez-compte des éléments suivants :
- Taille actuelle des données : Si vous migrez à partir d’une base de données existante.
- Taux de croissance: Estimer la quantité de données ajoutées au fil du temps.
- Taille et structure du document : Comprendre vos tailles de schéma et de document de données, car elles affectent l’efficacité du stockage.
- Calculez la taille attendue de vos données Azure DocumentDB. Tenez-compte des éléments suivants :
Facteur dans les index :
- Azure DocumentDB utilise des index pour l’interrogation efficace. Les index consomment de l’espace disque supplémentaire.
- Estimer la taille des index en fonction des points 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. Tenez-compte des éléments suivants :
- Débit d’E/S : Les E/S par seconde ou opérations d’entrée/sortie sont le nombre de requêtes envoyées aux disques de stockage en une seconde. La plus grande taille de stockage est associée à 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 seule requête, l’envoyer aux disques de stockage et envoyer la réponse au client. La latence est une mesure critique des performances d’une application en plus des IOPS et du débit. Le type de stockage utilisé et de configuration du stockage définit en grande partie la latence. Dans un service managé comme Azure DocumentDB, 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. Tenez-compte des éléments suivants :
Croissance et scalabilité futures :
- Planifiez en tenant compte de la croissance future des données et des besoins en évolutivité.
- 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, cela 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 pouvez commencer par un stockage de 1 TiB aujourd’hui et le faire évoluer à 2 TiB lorsque sa taille dépasse 800 GiB.
La décision sur la taille de stockage implique une combinaison d’estimation des besoins actuels et futurs de données, en tenant compte de l’indexation et de la compression, et de garantir des performances et une scalabilité adéquates. La surveillance et l’ajustement réguliers en fonction des tendances réelles d’utilisation et de croissance sont également essentielles pour maintenir des performances MongoDB optimales.
Qu’est-ce que le calcul burstable ?
Le niveau burstable offre une solution intelligente adaptée aux petites charges de travail de base de données. En fournissant des performances minimales du processeur pendant les périodes d’inactivité, ces clusters optimisent l’utilisation des ressources. Toutefois, le véritable éclat réside dans leur capacité à augmenter de manière transparente la puissance du processeur en réponse à une augmentation du trafic ou des demandes de charge de travail. Cette adaptabilité offre des performances optimales en cas de besoin, tout en offrant des économies substantielles.
En réduisant le point de prix initial du service, le niveau de cluster burstable d’Azure DocumentDB vise à faciliter l’intégration et l’exploration des utilisateurs d’Azure DocumentDB à des prix réduits. Cette démocratisation de l’accès permet aux entreprises de toutes tailles d’exploiter la puissance d’Azure DocumentDB sans se ruiner. Que vous soyez une start-up, une petite entreprise ou une grande entreprise, ce niveau ouvre de nouvelles possibilités pour une scalabilité rentable.
L’approvisionnement d’un niveau burstable est aussi simple que l’approvisionnement des niveaux réguliers ; vous devez uniquement choisir « M10 », « M20 » ou « M25 » dans l’option de niveau cluster. Voici un guide de démarrage rapide qui fournit des instructions pas à pas sur la configuration d’un cluster Azure DocumentDB .