Azure SQL-Datenbank bietet derzeit drei Dienstebenen, aus denen Sie für Ihre Workload auswählen können. Diese Ebenen bestehen aus Basic, Standard und Premium. Basic unterstützt nur eine Größe von 5 DTUs. Premium beginnt bei 125 DTUs und reicht bis zu 4.000 DTUs. Die Premium-Stufe ist die oberste Stufe, die für höhere I/O-Workloads entwickelt wurde und eine geringere Latenz pro I/O und eine Größenordnung mehr IOPS pro DTU als die Standard-Stufe bietet.
Vor August 2017 unterstützte der Standard-Tarif nur DTU-Größen zwischen 15 und 100 DTUs. Derzeit in der Vorschau verfügbar sind neue Leistungsstufen und Speicher-Add-Ons, die Preisoptimierungsvorteile für CPU-intensive Workloads bieten. Damit unterstützt die Standard-Stufe jetzt bis zu 3.000 DTUs.
An dieser Stelle fragen Sie sich vielleicht, was genau eine DTU ist? Eine DTU ist eine Datenbanktransaktionseinheit und eine Mischung aus CPU, Speicher und Daten- und Transaktionsprotokoll-E/A. (Andy Mallon, @AMtwo, hat dies kürzlich in „Was zum Teufel ist eine DTU?“ angesprochen.) Sie können Ihr DTU-Limit erreichen, indem Sie CPU, Arbeitsspeicher oder I/O ausreizen.
Zuvor bot der Standard-Tarif nur 4 Ebenen:15, 30, 50 und 100 DTUs, mit einer Datenbankgrößenbeschränkung von 250 GB, mit Standarddatenträger. Wenn Sie eine Datenbank hatten, die größer als 250 GB war, aber nicht mehr als 100 DTUs für CPU, Arbeitsspeicher oder E/A benötigten, mussten Sie einen Premium-Preis nur für die Datenbankgröße bezahlen. Mit den neuen Änderungen können Sie jetzt bis zu einer 1-TB-Datenbank im Standard-Tarif haben; Sie müssen nur den zusätzlichen Speicherplatz bezahlen. Derzeit wird Speicherplatz während der Vorschau mit 0,085 $/GB abgerechnet. Eine Erhöhung von 250 GB im Lieferumfang auf 1 TB erhöht sich um 774 GB zu einem Preis von 65,79 $ pro Monat.
Die neuen Standardvorschau-DTU-Größen unterstützen 200, 400, 800, 1.600 und 3.000 DTU-Optionen. Wenn Sie eine SQL Server-Datenbank-Workload haben, die eher CPU-lastig als I/O-lastig ist, haben diese Standard-Tier-Optionen das Potenzial, Ihnen viel Geld zu sparen; Wenn Ihre Workload jedoch E/A-gebunden ist, übertrifft die Premium-Stufe die Standard-Stufe.
Ich habe mich entschieden, zwei verschiedene Workloads auszuprobieren, um zu sehen, wie unterschiedlich die Standard- und Premium-Stufen im Vergleich zueinander sind. Ich wollte einen einfachen und reproduzierbaren Test erstellen, damit andere versuchen können, ihn für sich selbst zu validieren. Für meinen ersten Test wollte ich eine gesunde Mischung aus CPU und I/O generieren. Ich hatte gehofft, dass ich mehr CPU als E/A pushen und zeigen könnte, dass der erweiterte Standard-Tarif einen Premium-Tarif mit der gleichen DTU-Größe übertreffen würde. Ich habe nicht genau die Ergebnisse erzielt, die ich mir erhofft hatte.
Um diese Demo einzurichten, habe ich eine Tabelle mit drei GUID-Spalten erstellt, 1 Million Zeilen eingefügt und dann zwei der drei Spalten mit neuen IDs aktualisiert. Der Beispielcode ist unten:
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();
Während ich die Testreihe durchlief, verbesserte sich die Leistung in der Standard-Stufe stetig, bis ich zur S12-Option kam, wo seltsamerweise die CPU und die verstrichene Zeit zunahmen. Ich habe den Test mehrmals durchgeführt und S12 war konstant 54 Sekunden. Bei meinem ersten Test ist ziemlich klar, dass die Premium-Stufe die Standard-Stufe übertroffen hat. Beispielsweise sind S9 und P2 zeitlich am nächsten, jedoch beträgt die DTU-Größe für Standard 1.600 im Vergleich zu 250 für P2. Bei diesem Test geht es mehr um die E/A-Fähigkeiten. Das folgende Diagramm zeigt die Größe, das DTU-Level, die Kosten, die CPU-Zeit, die verstrichene Zeit und die Zeit in Sekunden für jeden Test:
Während die Tests ausgeführt wurden, beobachtete ich im Monitor-Dashboard, dass der Prozentsatz der Daten-E/A und der Protokoll-E/A die treibende Kraft hinter dem DTU-Prozentsatz war. Das folgende Diagramm stammt von einem Lauf gegen eine S4-Datenbank:
Ich entschied mich dann für eine weitere Testreihe, die CPU-lastiger wäre. Für diesen Test habe ich das folgende Skript verwendet:
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; Was ich im Monitor-Dashboard bei dieser Testreihe beobachtet habe, ist, dass der CPU-Prozentsatz der einzige Faktor für den DTU-Prozentsatz war. Als ich die Testreihe in der Standard-Stufe durchlief, schien der Test bei ungefähr 27 Sekunden ein Plateau zu erreichen und begann bei der Größe S4. Was mir seltsam auffiel, war, dass ein S4 mit 200 DTU 27 Sekunden brauchte, um fertig zu werden, und der entsprechende P2 mit 250 DTU 38 Sekunden dauerte; ein P4 mit 500 DTU war vergleichbarer. Wenn wir uns den Kostenunterschied für diese Demo ansehen, kostete ein S4 während der Vorschau nur 150,01 $, während ein P4 1.860 $ kostete; Der S4 bietet Kosteneinsparungen von knapp über 1.700 US-Dollar. Stellen wir uns vor, dass ein P2 mit 250 DTUs so funktioniert, wie wir es erwartet hatten; Ein P2 kostet 930 US-Dollar und würde immer noch 780 US-Dollar mehr kosten als ein S4.
Die vollständigen Ergebnisse aller Tests in der zweiten Demo sind in der folgenden Tabelle enthalten:
Im Gegensatz zur ersten Demo war diese zu 100 % CPU-gesteuert. Ich hatte versucht, einen zusätzlichen Cross Join einzufügen, aber die Demo dauerte dann Stunden pro Sitzung statt Minuten. Für einen zukünftigen Test werde ich versuchen, ein paar zusätzliche Szenarien zu entwickeln, die eine realistischere OLTP-Arbeitslast vorantreiben; eine, die eine höhere CPU hat, und eine, die mehr I/O-gebunden ist, und dann eine anständige Mischung aus beidem.
Aus dem Diagramm unten können Sie ersehen, dass bei diesem Durchlauf gegen eine S4-Datenbank die CPU um fast 50 % anstieg, während der DTU-Prozentsatz genau übereinstimmte:
Aus den zwei verschiedenen Arbeitslasten, die ich getestet habe, geht hervor, dass Sie bei erheblicher E/A-Arbeitslast die Premium-Stufe benötigen, aber wenn Ihre Arbeitslast hauptsächlich CPU-gebunden ist und keine wesentlichen E/A-Anforderungen bestehen, desto höher Standard-Stufen können Ihnen gegenüber der Premium-Stufe erhebliche Einsparungen bieten.
Wenn Sie eine Migration zu einer Azure SQL-Datenbank in Betracht ziehen, ist der DTU-Rechner ein großartiger Ausgangspunkt, um sich einen Eindruck von einem Ausgangspunkt für die Dimensionierung zu verschaffen. Zum Zeitpunkt des Verfassens dieses Artikels berücksichtigt der DTU-Rechner jedoch nicht die erweiterte Standardstufe. Das Tolle am DTU-Rechner ist, dass er CPU, IOPs und Protokollauslastung aufschlüsselt, um Ihnen mitzuteilen, was der treibende Faktor für die Empfehlung der DTU-Ebene ist. Beispielsweise habe ich die letzte Demo auf einer virtuellen Maschine mit 4 vCPU und 4 GB ausgeführt, und der DTU-Rechner hat P2 empfohlen. Als ich „Weitere Details anzeigen“ auswählte, erhielt ich die folgenden Meldungen.
Service Tier/Performance Level für CPU – Ausschließlich basierend auf der CPU-Auslastung empfehlen wir Ihnen, Ihre SQL Server-Workload zu Premium – P2 zu migrieren. Dieses Service Tier/Performance Level sollte ca. 100,00 % Ihrer CPU-Auslastung abdecken.
Service Tier/Performance Level für Iops – Ausschließlich basierend auf der Iops-Auslastung empfehlen wir Ihnen, Ihre SQL Server-Workload auf Basic zu migrieren. Dieses Service Tier/Performance Level sollte ca. 89,92 % Ihrer Iops-Auslastung abdecken.
HINWEIS:Ungefähr 10,08 % Ihrer Arbeitslast fallen in eine höhere Dienstebene/Leistungsstufe. Nachdem Sie Ihre Datenbank zu Azure migriert haben, sollten Sie die Leistung Ihrer Datenbank anhand der im Informationsabschnitt oben genannten Anleitung bewerten.
Service Tier/Performance Level für Log – Ausschließlich basierend auf der Protokollauslastung empfehlen wir Ihnen, Ihre SQL Server-Workload zu Basic zu migrieren. Diese Dienstebene/Leistungsstufe sollte ungefähr 100,00 % Ihrer Protokollnutzung abdecken.
Da ich weiß, dass diese Workload stark CPU-gebunden ist, stehen mir im Standard-Tarif bis zu 3.000 DTUs zur Verfügung, wenn ich die Workload nicht optimieren kann, um die CPU-Anforderung zu verringern. Anstatt 930 $ pro Monat für einen P2 mit 250 DTUs auszugeben, wäre ein S4 mit 200 DTUs zu 150 $ pro Monat (oder ein S6 mit 400 DTUs zu 300,02 $ pro Monat) eine viel wirtschaftlichere Option.
Zusammenfassend lässt sich sagen, dass Tools zur Verfügung stehen, die Ihnen dabei helfen, einen guten Ausgangspunkt für die Größe Ihrer Azure SQL-Datenbankmigrationen zu ermitteln. Die absolut beste Methode besteht jedoch darin, Ihre Workload zu testen. Wenn Sie eine Kopie Ihrer Produktionsdatenbank migrieren, eine Produktionsworkload erfassen und diese Workload gegen die Azure SQL-Datenbank wiedergeben, erhalten Sie ein viel besseres Verständnis dafür, welche DTU-Größe Sie wirklich benötigen.
