Azure SQL Database est l'offre de base de données en tant que service de Microsoft qui offre une énorme flexibilité. Il est conçu dans le cadre de l'environnement de plate-forme en tant que service qui offre aux clients une surveillance et une sécurité supplémentaires pour le produit.
Microsoft travaille continuellement à l'amélioration de ses produits et Azure SQL Database n'est pas différent. La plupart des nouvelles fonctionnalités que nous avons dans SQL Server ont été initialement lancées dans Azure SQL Database, y compris (mais sans s'y limiter) Always Encrypted, Dynamic Data Masking, Row Level Security et Query Store.
Niveau de tarification DTU
Lorsque Azure SQL Database a été lancé pour la première fois, il existait une seule option de tarification appelée « DTU » ou Database Transaction Units. (Andy Mallon, @AMtwo, explique les DTU dans "Qu'est-ce qu'une DTU ?") Le modèle DTU fournit trois niveaux de service :de base, standard et premium. Le niveau de base fournit jusqu'à 5 DTU avec un stockage standard. Le niveau standard prend en charge de 10 à 3 000 DTU avec un stockage standard et le niveau premium prend en charge de 125 à 4 000 DTU avec un stockage premium, ce qui est bien plus rapide que le stockage standard.
Niveau de tarification vCore
Quelques années après la sortie d'Azure SQL Database, Azure SQL Managed Instance était en préversion publique et les « vCores » (cœurs virtuels) ont été annoncés pour Azure SQL Database. Ceux-ci ont introduit les niveaux à usage général et critiques pour l'entreprise avec les processeurs Gen 4 et Gen 5. La génération 5 est désormais la principale option matérielle pour la plupart des régions depuis que la génération 4 est obsolète.
Gen 5 prend en charge aussi peu que 2 vCores et jusqu'à 80 vCores avec une RAM allouée à 5,1 Go par vCore. Le niveau à usage général fournit un stockage à distance avec un maximum d'IOPS de données allant de 640 pour une base de données à 2 vCore jusqu'à 25 600 pour une base de données à 80 vCore. Le niveau critique pour l'entreprise dispose d'un SSD local qui offre de bien meilleures performances d'E/S avec un maximum d'IOPS de données allant de 8 000 pour une base de données à 2 vCore jusqu'à 204 800 pour une base de données à 80 vCore. Les niveaux à usage général et critique pour l'entreprise ne dépassent pas 4 096 Go pour le stockage, ce qui est devenu une limitation pour de nombreux clients.
Base de données HyperScale
Pour résoudre la limite de 4 To d'Azure SQL Database, Microsoft a créé le niveau hyperscale. Hyperscale permet aux clients d'évoluer jusqu'à 100 To de taille de base de données en plus de fournir une évolutivité rapide pour les nœuds en lecture seule. Vous pouvez également facilement augmenter et réduire le modèle vCore. Les bases de données hyperscale sont provisionnées à l'aide de vCores. Avec Gen 5, une base de données Hyperscale peut utiliser entre 2 et 80 vCores et 500 à 204 800 IOPS. Hyperscale atteint des performances élevées à partir de chaque nœud de calcul doté de caches SSD, ce qui permet de minimiser les allers-retours sur le réseau pour récupérer les données. Il existe de nombreuses technologies impressionnantes impliquées dans Hyperscale dans la façon dont il est conçu pour utiliser des caches et des serveurs de pages basés sur SSD. Je vous recommande fortement de jeter un coup d'œil au diagramme qui décompose l'architecture et comment tout cela fonctionne dans cet article.
Base de données sans serveur
Une autre demande très courante de la part des clients était la possibilité d'augmenter et de réduire automatiquement leur base de données SQL Azure à mesure que les charges de travail augmentaient et diminuaient. Les clients ont traditionnellement la possibilité d'augmenter et de diminuer par programmation à l'aide de PowerShell, d'Azure Automation et d'autres méthodes. Microsoft a repris cette idée et a créé un nouveau niveau de calcul appelé Azure SQL Database sans serveur, qui est devenu généralement disponible en novembre 2019. Ils permettent au client de définir des nombres minimum et maximum de vCores. De cette façon, ils peuvent savoir qu'il existe toujours un niveau de calcul minimum disponible et ils peuvent toujours évoluer automatiquement vers un niveau de calcul désigné. Il est également possible de configurer un délai d'autopause. Ce paramètre vous permet de suspendre automatiquement la base de données après une durée spécifique d'inactivité de la base de données. Lorsqu'une base de données entre en phase d'autopause, les coûts de calcul passent à zéro et seuls les coûts de stockage sont encourus. Le coût global du sans serveur est la somme du coût de calcul et du coût de stockage. Lorsque l'utilisation du calcul se situe entre les limites minimale et maximale, le coût de calcul est basé sur les vCores et la mémoire utilisée. Si l'utilisation réelle est inférieure à la valeur minimale, le coût de calcul est basé sur le minimum de vCores et de mémoire minimum configuré.
Le niveau sans serveur a le potentiel de faire économiser beaucoup d'argent aux clients tout en leur donnant la possibilité de fournir une expérience utilisateur de base de données cohérente, la base de données pouvant évoluer en fonction de la demande.
Piscines élastiques
Azure SQL Database dispose d'un modèle de ressources partagées qui permet aux clients d'avoir une meilleure utilisation des ressources. Un client peut créer un pool élastique et déplacer des bases de données dans ce pool. Chaque base de données peut alors commencer à partager des ressources prédéfinies au sein de ce pool. Les pools élastiques peuvent être configurés à l'aide du modèle de tarification DTU ou du modèle vCore. Les clients déterminent la quantité de ressources dont le pool élastique a besoin pour gérer la charge de travail de toutes ses bases de données. Les limites de ressources peuvent être configurées par base de données afin qu'une base de données ne puisse pas consommer tout le pool. Les pools élastiques sont parfaits pour les clients qui doivent gérer un grand nombre de bases de données ou de scénarios mutualisés.
Nouvelle configuration matérielle pour le niveau de calcul provisionné
Les configurations matérielles Gen4/Gen5 sont considérées comme "mémoire et calcul équilibrés". Cela fonctionne bien pour de nombreuses charges de travail SQL Server, cependant, il y a eu des cas d'utilisation pour une latence CPU plus faible et une vitesse d'horloge plus élevée pour les charges de travail gourmandes en CPU et un besoin de mémoire plus élevée par vCore. Microsoft a une fois de plus livré et créé une configuration matérielle optimisée pour le calcul et la mémoire. Celles-ci sont actuellement en préversion et uniquement disponibles dans certaines régions.
Dans le niveau provisionné à usage général, vous pouvez sélectionner la série Fsv2 qui peut fournir plus de performances CPU par vCore que le matériel Gen 5. Dans l'ensemble, la taille de 72 vCore peut fournir plus de performances CPU que la 80 vCore Gen 5 en offrant une latence CPU plus faible et des vitesses d'horloge plus élevées. La série Fsv2 a moins de mémoire et de tempdb par vCore que Gen 5, il faudra donc en tenir compte.
Dans le niveau provisionné critique pour l'entreprise, vous pouvez accéder à la série M qui est optimisée en mémoire. La série M offre 29 Go par vCore contre 5,1 Go par vCore dans la configuration « équilibrer la mémoire et le calcul ». Avec la série M, vous pouvez faire évoluer vCore jusqu'à 128, ce qui fournirait jusqu'à 3,7 To de mémoire. Pour activer la série M, vous devez actuellement être dans un contrat Pay-As-You-Go ou Enterprise et ouvrir une demande de support. Même dans ce cas, la série M n'est actuellement disponible que dans les États-Unis de l'Est, l'Europe du Nord, l'Europe de l'Ouest et les États-Unis de l'Ouest 2, et peut également avoir une disponibilité limitée dans d'autres régions.
Conclusion
Azure SQL Database est une plate-forme de base de données riche en fonctionnalités qui offre un large éventail d'options de calcul et d'évolutivité. Les clients peuvent configurer le calcul pour une seule base de données ou un pool élastique à l'aide de DTU ou de vCores. Pour les bases de données avec un besoin de stockage important ou une évolutivité de lecture, Hyperscale peut être utilisé. Pour les clients ayant des exigences de charge de travail variables, le sans serveur peut être utilisé pour évoluer automatiquement à mesure que leurs demandes de charge de travail changent. La nouveauté d'Azure SQL Database est la fonctionnalité de préversion d'une configuration matérielle optimisée pour le calcul et la mémoire pour les clients qui ont besoin d'un processeur à faible latence ou ceux qui ont des besoins élevés en termes de mémoire et de processeur.
Pour en savoir plus sur les ressources Azure, consultez mes articles précédents :
- Options de réglage des performances de la base de données SQL Azure
- Considérations relatives aux performances d'Azure SQL Managed Instance
- Nouvelles tailles de niveau standard Azure SQL Database
- Combler le fossé Azure :instances gérées
- Migration de bases de données vers Azure SQL Database
