Azure SQL Database – Performance-Klassen – Refresh Teil 2

Ich betrachte die weiteren Beiträge als einen persönlichen Refresh meiner Kenntnisse über die Azure SQL Database und all ihre zahlreichen Features. Es war nach längerer Zeit mal wieder notwendig sich im Detail damit zu beschäftigen und für mich und meine eigenen Erfahrungen mit dem Lernen zeigen, dass „aufschreiben“ sehr gut hilft, sich Inhalte und wichtige Punkte zu verinnerlichen. Also werde ich einfach die nächsten (wenn auch vielleicht kürzeren) Blogpost dafür verwenden, euch an meinem „Refresh“ teil haben zu lassen. Dies ist in sofern auch relevant, als dass Microsoft Produktgruppe im Laufe der vergangenen Monate nicht untätig war und zahlreiche neue Features präsentiert hat bzw Optimierungen an den bereits vorhandenen vorgenommen hat. (Danke dafür 😉 )

Welche Leistungen gibt es für Datenbanken

Die Auswahl im Deployment-Prozess, wieviel Leistung der Datenbank bzw dem Elastic-Pool zugewiesen werden soll ist im Grunde recht einfach bzw es stehen nicht wirklich viele Optionen zur Wahl. Eines haben alle Performance-Klassen gemeinsam, es geht immer die Höhe der Compute-Power, eine gewissen „Gemenge-Lage“ aus (v)CPU, RAM und IOPS. Microsoft stellt hierzu unterschiedliche Kategorien und Größen zur Verfügung, die im folgenden näher vorstellen möchte.

Wie bereits kurz angedeutet – in meinem vorherigen Post – gibt es für die unterschiedlichen Services auch verschiedene Gruppierungen. Die Single-DB lässt sich unterteilen in DTU (Data Transaction Units) und das vCore-Modell, bei den DTUs gibt es die Untergruppierung nach Basic, Standard und Premium, bei den vCores wird unterschieden in „General Purpose / Allgemein“ und „Business Critical / Unternehmenskritisch“.

Neben diesen beiden – allgemeinen – Performance-Klassen unterscheidet Microsoft auch noch in die zwei „besonderen“ Klassen – Serverless und Hyperscale. Diese beiden werden seitens Microsoft als Performance-Klassen (vielleicht passt Dienstebenen besser) bezeichnet, dazu aber später mehr.

Data Transaction Units (DTU)

In der Performance-Klasse DTU kann man nun nicht nur zwischen Basic, Standard und Premium unterscheiden, sondern auch noch granularer nach mehreren Abstufungen. Bei der Auswahl der jeweilig zu nutzenden Performance-Klasse gibt Microsoft als Richtlinie an, dass die hauptsächlich davon abhängt, was Ihre Applikation in Bezug auf Verfügbarkeit, Leistung der CPUs, RAM, Storage-IOPS oder Features wie In-Memory oder Columnstore benötigt. Die folgende Tabelle aus der Microsoft-Dokumentation kommt vom 01.August 2021 und aktuell gültig und soll verdeutlichen wie man idealerweise die Nutzung der Klassen für die Azure SQL Database angegangen werden soll.

	Basic	Standard	Premium
Zielworkload	Entwicklung und Produktion	Entwicklung und Produktion	Entwicklung und Produktion
Betriebszeit-SLA	99,99 %	99,99 %	99,99 %
Maximale Sicherungsaufbewahrung	7 Tage	35 Tage	35 Tage
CPU	Niedrig	Niedrig, Mittel, Hoch	Mittel, Hoch
IOPS (ungefähr) *	1–4 IOPS pro DTU	1–4 IOPS pro DTU	Mehr als 25 IOPS pro DTU
E/A-Wartezeit (ungefähr)	5 ms (Lesen), 10 ms (Schreiben)	5 ms (Lesen), 10 ms (Schreiben)	2 ms (Lesen/Schreiben)
Columnstore-Indizierung	–	S3 und höher	Unterstützt
In-Memory-OLTP	–	–	Unterstützt

Wie der Dokumentation zu entnehmen ist, bietet die Performance-Klasse Basic keine Wahl-Möglichkeit bzgl Performance sondern nur fix „Basic“ aber bietet die Auswahl des maximal zu verwendenden Speicher von 0,1 – 2 GB. Hiermit wendet sich Azure an die Entwickler oder „Ausprobierer“, die „nur mal eben schnell“ etwas testen wollen, ob oder wie etwas funktioniert und keine produktiven Workloads etablieren wollen.

In Standard wird es dann schon etwas kompliziert bzw vielfältiger… hier kann man zwischen S0 und S12 wählen und davon unabhängig ebenfalls den maximal zur Verfügung stehenden Storage je nach Auswahl der Stufen. (siehe Bild oben) Zur Auswahl stehen hier bei S0 – 10 DTU und Speicher zwischen 0,1 – 250GB, sowie S12 – 3000 DTU und Speicher bis 1024GB.

Die Performance-Klasse Premium ist analog zu Standard aufgebaut, auch hier kann man zwischen P1 und P15 wählen und davon unabhängig ebenfalls den maximal zur Verfügung stehenden Storage je nach Auswahl der Stufen. Zur Auswahl stehen hier bei P1 – 125 DTU und Speicher zwischen 0,1 – 1024GB, sowie P15 – 4000 DTU und Speicher bis 4096GB.

Bezogen auf die tatsächliche Compute-Leistung der einzelnen Leistungen schreibt Microsoft, dass bei den Klassen S0, S1, S2 kein vollständiger Kern zur Verfügung gestellt wird, dies geschieht erst ab S3. Ebenso kommen bei den Klassen S0 und S1 keine performanten SSD-Festplatten zum Einsatz, sondern nur HDDs.

Für die Auswahl der Performance-Klassen bei den Elastic-Pools ist die Unterscheidung ähnlich, hier heißt es dann aber nicht DTU sondern eDTU. Bei einem Elastic-Pool wird dem kompletten Pool die ausgewählte Performance-Klasse zur Verfügung gestellt, welche dann auf die einzelnen Datenbanken verteilt werden. Beispielsweise wird dem Elastic-Pool ein Kontigent von 800 DTUs zugewiesen, bedeutet, dass das alle Datenbanken innerhalb des Pools in Summe (je nach Konfiguration) maximal 2048GB groß werden können (bspw. 10 Datenbanken je 204,8GB) oder bei gleicher Auslastung jede Datenbank (naiv) mit 80 DTUs arbeiten könnte. Aber zu Elastic-Pools kommt auch noch ein Beitrag 😉

virtuelle Kerne (vCores) – Modell

Da viele Kunden nichts mit der Einheit DTU anfangen konnten, im Vergleich zu dem was sie bisher gewöhnt waren, hat Microsoft vor einigen Jahren die „vCore“ Performance-Klassen eingeführt. Mit diesem „neuen“ Modell konnte man als Kunde sich eher vorstellen und natürlich auch exakt auswählen, wieviel Leistung man erhält beispielsweise 4vCPU. Das vCore Modell ist auch granularer konfigurierbar, denn hier stehen mehr Werte zur Verfügung.

Aber bevor man zur Auswahl der Kerne bzw des Storages kommt, muss man sich erst einmal – wie beim DTU.-Modell für ein Servie-Tier entscheiden. Zur Auswahl bei der Azure SQL Database stehen „Generel Purpose“, „Business Critical“ und „Hyperscale“, alle unterscheiden sich in der Hauptsache in der zugrunde liegenden Infrastruktur bzw Umsetzung der Hochverfügbarkeit. Alle Datenbanken – egal in welcher Performance-Klasse sind zu 99,99% verfügbar, daran ändert sich nichts, aber die verwendeten internen Services machen hier den Unterschied, wie die beiden folgenden Bilder zeigen.

In General Purpose wird „nur“ ein Prozess der sqlservr.exe in der Service-Fabric gestartet und dieser Prozess erhält eine Verbindung zu einem Storage (Blob Storage) für die mdf/ldf-Dateien. Im Vergleich dazu wird zwar auch in der BC die Datenbank-Engine nur SQL Server Prozess abgebildet, erhält aber eine direkte Verbindung zu einer lokalen SSD und wird zur Realisierung des Read-Only-Endpunktes in einer mit einer AlwaysOn AvailabilityGruppe