Azure SQL Database propose actuellement trois niveaux de service parmi lesquels choisir pour votre charge de travail. Ces niveaux se composent de Basic, Standard et Premium. Basic ne prend en charge qu'une seule taille de 5 DTU. Premium commence à 125 DTU et monte jusqu'à 4 000 DTU. Le niveau Premium est le niveau supérieur qui est conçu pour des charges de travail d'E/S plus élevées et offre une latence plus faible par E/S, et un ordre de grandeur plus d'IOPS par DTU, que dans le niveau Standard.
Avant août 2017, le niveau Standard ne prenait en charge que les tailles de DTU comprises entre 15 et 100 DTU. Actuellement disponibles en version préliminaire, de nouveaux niveaux de performances et des modules complémentaires de stockage offrent des avantages d'optimisation des prix pour les charges de travail gourmandes en CPU. Avec ceux-ci, le niveau Standard prend désormais en charge jusqu'à 3 000 DTU.
À ce stade, vous vous demandez peut-être ce qu'est exactement un DTU ? Une DTU est une unité de transaction de base de données et est un mélange de CPU, de mémoire et d'E/S de données et de journaux de transactions. (Andy Mallon, @AMtwo, a récemment abordé ce sujet dans "Qu'est-ce qu'un DTU ?") Vous pouvez atteindre votre limite de DTU en maximisant le CPU, la mémoire ou les E/S.
Auparavant, le niveau Standard n'offrait que 4 niveaux :15, 30, 50 et 100 DTU, avec une limite de taille de base de données de 250 Go, avec un disque standard. Si vous aviez une base de données supérieure à 250 Go, mais que vous n'aviez pas besoin de plus de 100 DTU pour le processeur, la mémoire ou les E/S, vous deviez payer un prix Premium uniquement pour la taille de la base de données. Avec les nouvelles modifications, vous pouvez désormais disposer d'une base de données allant jusqu'à 1 To au niveau Standard ; vous n'avez qu'à payer le stockage supplémentaire. Actuellement, le stockage est facturé à 0,085 $/Go pendant la préversion. Passer de la taille incluse de 250 Go à 1 To augmente de 774 Go pour un coût de 65,79 $ par mois.
Les nouvelles tailles DTU d'aperçu standard prennent en charge les options 200, 400, 800, 1 600 et 3 000 DTU. Si vous avez une charge de travail de base de données SQL Server qui est plus liée au CPU qu'aux E/S, ces options de niveau Standard ont le potentiel de vous faire économiser beaucoup d'argent; cependant, si votre charge de travail est liée aux E/S, le niveau Premium surpassera le niveau Standard.
J'ai décidé d'essayer deux charges de travail différentes pour voir à quel point les niveaux Standard et Premium sont différents les uns des autres. Je voulais créer un test simple et reproductible pour que d'autres puissent essayer de valider par eux-mêmes. Pour mon premier test, je voulais générer un mélange sain de CPU et d'E/S. J'espérais pousser plus de CPU que d'E/S et être en mesure de montrer que le niveau Standard étendu surpasserait un niveau Premium avec la même taille de DTU. Je n'ai pas exactement obtenu les résultats que j'espérais.
Pour configurer cette démo, j'ai créé une table avec trois colonnes GUID, inséré 1 million de lignes, puis mis à jour deux des trois colonnes avec de nouveaux ID. L'exemple de code est ci-dessous :
CREATE TABLE dbo.TestTable ( Table_id UNIQUEIDENTIFIER DEFAULT NEWID(), Customer_id UNIQUEIDENTIFIER DEFAULT NEWID(), Cust_Name VARCHAR(40) DEFAULT CAST(NEWID() AS VARCHAR(40)) ); SET NOCOUNT ON; GO INSERT INTO dbo.TestTable DEFAULT VALUES; GO 1000000 CREATE CLUSTERED INDEX [ClustTestTable] ON [dbo].[TestTable] ( [Table_id] ASC, [Customer_id] ASC ); SET STATISTICS TIME ON; UPDATE TestTable SET Table_id = NEWID(), Customer_id = NEWID();
Au fur et à mesure que j'exécutais la série de tests, les performances s'amélioraient régulièrement dans le niveau Standard jusqu'à ce que j'arrive à l'option S12 où, curieusement, le processeur et le temps écoulé ont augmenté. J'ai exécuté le test plusieurs fois et S12 durait systématiquement 54 secondes. Il est assez clair avec mon premier test que le niveau Premium a surpassé le niveau Standard. Par exemple, le S9 et le P2 sont les plus proches dans le temps, mais la taille DTU pour Standard est de 1 600 contre 250 pour le P2. Ce test concerne davantage les capacités d'E/S. Le tableau ci-dessous indique la taille, le niveau DTU, le coût, le temps CPU, le temps écoulé et le temps en secondes pour chaque test :
Pendant l'exécution des tests, j'ai observé dans le tableau de bord du moniteur que le pourcentage d'E/S de données et d'E/S de journal était le moteur du pourcentage de DTU. Le graphique suivant provient d'une exécution sur une base de données S4 :
J'ai alors décidé d'essayer une autre série de tests qui seraient plus gourmands en CPU. Pour ce test, j'ai utilisé le script suivant :
SET STATISTICS TIME ON;
SELECT SUM(CONVERT(BIGINT, t1.object_id)
+ CONVERT(BIGINT, t2.object_id)
+ CONVERT(BIGINT, t3.object_id)
+ CONVERT(BIGINT, t4.object_id))
FROM sys.objects t1
CROSS JOIN sys.objects t2
CROSS JOIN sys.objects t3
CROSS JOIN sys.objects t4; Ce que j'ai observé dans le tableau de bord du moniteur sur cette série de tests, c'est que le pourcentage de CPU était le seul facteur du pourcentage de DTU. Au cours de la série de tests du niveau Standard, le test a semblé se stabiliser à environ 27 secondes et a commencé à la taille S4. Ce qui m'a semblé étrange, c'est qu'un S4 à 200 DTU a pris 27 secondes pour se terminer et le P2 correspondant à 250 DTU a pris 38 secondes; un P4 à 500 DTU était plus comparable. Si nous regardons le différentiel de coût pour cette démo, un S4 lors de la prévisualisation ne coûte que 150,01 $, tandis qu'un P4 coûte 1 860 $; le S4 permet de réaliser des économies d'un peu plus de 1 700 $. Imaginons qu'un P2 à 250 DTU se comporte comme prévu ; un P2 coûte 930 $ et coûterait encore 780 $ de plus qu'un S4.
Les résultats complets de tous les tests de la deuxième démo sont inclus dans le tableau suivant :
Contrairement à la première démo, celle-ci était 100 % pilotée par le processeur. J'avais essayé d'inclure une jointure croisée supplémentaire, mais la démo prenait alors des heures par session au lieu de quelques minutes. Pour un futur test, j'essaierai de proposer quelques scénarios supplémentaires qui poussent une charge de travail OLTP plus réaliste; un qui est plus CPU, et un qui est plus lié aux E/S, puis un bon mélange des deux.
Vous pouvez voir sur le graphique ci-dessous que, lors de cette exécution sur une base de données S4, le processeur a atteint un pic de près de 50 %, tandis que le pourcentage de DTU correspondait exactement :
D'après les deux charges de travail différentes que j'ai testées, il est très évident que si vous avez une charge de travail d'E/S importante, vous aurez besoin du niveau Premium, mais si votre charge de travail est principalement liée au processeur sans aucun besoin d'E/S important, le plus élevé Les niveaux Standard peuvent vous permettre de réaliser des économies substantielles par rapport au niveau Premium.
Si vous envisagez une migration vers une base de données Azure SQL, la calculatrice DTU est un excellent point de départ pour avoir une idée d'un point de départ pour le dimensionnement; cependant, au moment de la rédaction, le calculateur de DTU ne prend pas en compte le niveau Standard étendu. Ce qui est génial avec le calculateur DTU, c'est qu'il décompose l'utilisation du processeur, des IOP et des journaux pour vous faire savoir quel est le facteur déterminant pour la recommandation de niveau DTU. Par exemple, j'ai exécuté la dernière démo sur une machine virtuelle 4 vCPU, 4 Go, et le calculateur DTU a recommandé un P2. Lorsque j'ai choisi "Afficher plus de détails", j'ai reçu les messages suivants.
Niveau de service/niveau de performance pour le processeur – En nous basant uniquement sur l'utilisation du processeur, nous vous recommandons de migrer votre charge de travail SQL Server vers Premium – P2. Ce niveau de service/niveau de performance doit couvrir environ 100,00 % de l'utilisation de votre CPU.
Niveau de service/Niveau de performance pour Iops – En nous basant uniquement sur l'utilisation des Iops, nous vous recommandons de migrer votre charge de travail SQL Server vers Basic. Ce niveau de service/niveau de performance devrait couvrir environ 89,92 % de votre utilisation Iops.
REMARQUE :Environ 10,08 % de votre charge de travail relève d'un niveau de service/niveau de performance supérieur. Après avoir migré votre base de données vers Azure, vous devez évaluer les performances de votre base de données à l'aide des conseils mentionnés dans la section d'informations ci-dessus.
Niveau de service/Niveau de performance pour le journal – Basé uniquement sur l'utilisation du journal, nous vous recommandons de migrer votre charge de travail SQL Server vers Basic. Ce niveau de service/niveau de performance doit couvrir environ 100,00 % de l'utilisation de votre journal.
Étant donné que je sais que cette charge de travail est fortement liée au processeur, si je ne peux pas régler la charge de travail pour réduire les besoins en processeur, j'ai jusqu'à 3 000 DTU disponibles au niveau Standard. Plutôt que de dépenser 930 $ par mois pour un P2 avec 250 DTU, un S4 avec 200 DTU à 150 $ par mois (ou un S6 avec 400 DTU à 300,02 $ par mois) serait une option beaucoup plus économique.
En conclusion, il existe des outils disponibles pour vous aider à déterminer un bon point de départ pour la taille de vos migrations Azure SQL Database, mais la meilleure méthode absolue consiste à tester votre charge de travail. La migration d'une copie de votre base de données de production, la capture d'une charge de travail de production et la relecture de cette charge de travail par rapport à Azure SQL Database vous permettront de mieux comprendre la taille de DTU dont vous avez réellement besoin.
