Scalabilité dans Azure DocumentDB

Azure DocumentDB offre la possibilité de mettre à l’échelle des clusters à la fois verticalement et horizontalement. Bien que le niveau de cluster de calcul et le disque de stockage dépendent les uns des autres, l’extensibilité et le coût du calcul et du stockage sont découplés.

Mise à l’échelle verticale

La mise à l’échelle verticale offre les avantages suivants :

• Les équipes d’application peuvent ne pas toujours avoir un chemin clair pour partitionner logiquement leurs données. De plus, le partitionnement logique est défini par collection. Dans un jeu de données avec plusieurs collections non partitionnées, la modélisation des données pour partitionner les données peut rapidement devenir fastidieuse. L'augmentation du cluster peut contourner le besoin de partitionnement logique tout en répondant aux besoins croissants de l'application en matière de stockage et de calcul.
• La mise à l’échelle verticale ne nécessite pas de rééquilibrage des données. Le nombre de partitions physiques reste le même et seule la capacité du cluster est augmentée sans impact sur l’application.
• L’augmentation d’échelle (scaling-up) et la réduction d’échelle (scaling-down) sont des opérations qui ne nécessitent aucun temps d’arrêt et n’entraînent aucune interruption du service. Aucune modification de l'application n'est nécessaire et les opérations en régime permanent peuvent continuer sans perturbation.
• Les ressources de calcul peuvent également être réduites lors des périodes connues de faible activité. Une fois de plus, la réduction d'échelle évite la nécessité de rééquilibrer les données sur moins de partitions physiques et est une opération sans temps d'arrêt, sans interruption du service. Ici aussi, aucune modification de l’application n’est nécessaire après le scale-down du cluster.
• Plus important encore, le calcul et le stockage peuvent être mis à l’échelle indépendamment. Si davantage de cœurs et de mémoire sont nécessaires, la taille du disque peut être laissée telle quelle et le niveau du cluster peut être mis à l’échelle. De même, si davantage de stockage et d’E/S par seconde sont nécessaires, le niveau de cluster peut être laissé tel quel et la taille de stockage peut être mise à l’échelle indépendamment. Si nécessaire, le calcul et le stockage peuvent être mis à l’échelle indépendamment pour optimiser les exigences de chaque composant individuellement, sans les exigences d’élasticité des deux composants affectant l’autre.

Mise à l’échelle horizontale

À terme, l’application atteint un stade où la mise à l’échelle verticale ne suffit plus. Les besoins en charge de travail peuvent dépasser la capacité du niveau de cluster le plus important et il faut alors prévoir davantage d’unités de stockage. La mise à l’échelle horizontale dans Azure DocumentDB offre les avantages suivants :

• Les jeux de données partitionnés logiquement ne nécessitent pas d’intervention de l’utilisateur pour équilibrer les données entre les partitions physiques sous-jacentes. Le service mappe automatiquement les partitions logiques aux partitions physiques. Lorsque des nœuds sont ajoutés ou supprimés, les données sont automatiquement rééquilibrées en arrière-plan dans la base de données.
• Les requêtes sont automatiquement acheminées vers la partition physique appropriée qui possède la plage de hachage pour les données interrogées.
• Les clusters géo-distribués ont une configuration homogène à plusieurs nœuds. Ainsi, les mappages de partitions physiques sont cohérents entre les régions principales et réplicas d’un cluster.

Mise à l’échelle du calcul et du stockage

Les ressources de calcul et de mémoire influencent les opérations de lecture dans Azure DocumentDB plus que les IOPS de disque.

• Les opérations de lecture consultent d’abord le cache dans la couche de calcul et revenent au disque lorsque les données n’ont pas pu être récupérées à partir du cache. Pour les charges de travail avec un taux plus élevé d’opérations de lecture par seconde, le scale-up du niveau cluster pour obtenir plus de ressources processeur et mémoire entraîne un débit plus élevé.
• En plus du débit de lecture, les charges de travail avec un volume élevé de données par opération de lecture bénéficient également de la mise à l’échelle des ressources de calcul du cluster. Par exemple, les niveaux de cluster avec plus de mémoire facilitent les tailles de charge utile plus grandes par document et un plus grand nombre de documents plus petits par réponse.

Les IOPS de disque influencent les opérations d’écriture dans Azure DocumentDB plus que les capacités de processeur et de mémoire des ressources de calcul.

• Les opérations d’écriture conservent toujours les données sur le disque (en plus de conserver les données en mémoire pour optimiser les lectures). Les disques plus volumineux avec plus d’E/S par seconde offrent un débit d’écriture plus élevé, en particulier lors de l’exécution à grande échelle.
• Le service prend en charge jusqu’à 32 To de disques par partition, avec plus d’IOPS par partition pour bénéficier de charges de travail lourdes d’écriture, en particulier lors de l’exécution à grande échelle.

Charges de travail lourdes de stockage et disques volumineux

Aucune configuration minimale requise pour le stockage par niveau de cluster

Comme mentionné précédemment, les ressources de stockage et de calcul sont découplées pour la facturation et l’approvisionnement. Bien qu’ils fonctionnent comme une unité cohérente, ils peuvent être mis à l’échelle indépendamment. Le niveau de cluster M30 peut avoir 32 To de disques provisionnés. De même, le niveau de cluster M200 peut avoir 32 Go de disques provisionnés pour optimiser les coûts de stockage et de calcul.

Réduction du TCO avec des disques volumineux (32 To et au-delà)

En règle générale, les bases de données NoSQL limitent le stockage par partition physique à 4 To. Azure DocumentDB fournit jusqu’à 8 fois cette capacité avec 32 To de disques. Pour les charges de travail lourdes de stockage, une capacité de stockage de 4 To par partition physique nécessite une flotte massive de ressources de calcul pour maintenir les besoins de stockage de la charge de travail. Le calcul est plus coûteux que le stockage et un surprovisionnement en ressources de calcul en raison des limites de capacité dans un service peut gonfler les coûts rapidement.

Prenons en compte une charge de travail importante de stockage avec 200 To de données.

La réduction des exigences de calcul réduit fortement les disques plus volumineux. Bien que plus que le nombre minimal de partitions physiques puisse être nécessaire pour maintenir les exigences de débit de la charge de travail, même le doublement ou le triplage du nombre de partitions sont plus rentables qu’un cluster de 50 partitions avec des disques plus petits.

Ignorer la hiérarchisation du stockage avec des disques volumineux

Une réponse immédiate aux coûts de calcul dans les scénarios lourds de stockage consiste à « hiérarchiser » les données. Les données de la base de données transactionnelle sont limitées aux données « chaudes » les plus fréquemment consultées, tandis que le plus grand volume de données « froid » est détaché dans un magasin froid. Cela entraîne une complexité opérationnelle. Les performances sont également imprévisibles et dépendantes du niveau de données accessible. En outre, la disponibilité de l’ensemble du système dépend de la résilience des magasins de données chauds et froids combinés. Avec les disques volumineux dans le service, il n’est pas nécessaire de hiérarchiser le stockage, car le coût des charges de travail lourdes de stockage est réduit.

Étapes suivantes

• Découvrez comment mettre à l’échelle un cluster Azure DocumentDB
• Consultez les meilleures pratiques d’indexation