Entwerfen von Azure SQL-Datenbank für cloudnative Anwendungen

Azure SQL-Datenbank ist ein PaaS -Dienst (Platform-as-a-Service), der hohe Skalierbarkeitsfunktionen bietet und eine hervorragende Lösung für bestimmte Workloads sein kann. Er erfordert minimalen Wartungsaufwand.

Azure SQL-Datenbank ist auf die Entwicklung neuer Anwendungen ausgerichtet, da Entwickler ein großes Maß an Flexibilität beim Erstellen neuer Anwendungsdienste und differenzierte Bereitstellungsoptionen im großen Stil erhalten. SQL-Datenbank bietet eine Lösung mit geringem Wartungsaufwand, die eine hervorragende Option für bestimmte Workloads sein kann.

Kaufmodell

Für SQL-Datenbank sind zwei Hauptkaufmodelle verfügbar: das auf virtuellen Kernen basierende Modell und das auf DTU basierende Modell. Jedes Kaufmodell bietet die folgenden Dienstebenen:

vCore-basiertes Modell

In diesem Kaufmodell werden Compute- und Speicherressourcen entkoppelt. Dies bedeutet, dass Sie Speicher- und Computeressourcen unabhängig voneinander skalieren können. Dies sind die verfügbaren Dienstebenen:

Dienstebene	Fähigkeit
Allgemeiner Zweck	Diese Dienstebene ist für weniger intensive Vorgänge konzipiert und bietet budgetorientierte, ausgeglichene Compute- und Speicheroptionen. Sie bietet sowohl eine bereitgestellte Computeebene als auch eine serverlose Computeebene.
Unternehmenskritisch	Diese Dienstebene unterstützt In-Memory-OLTP und integrierte schreibgeschützte Replikate. Außerdem enthält sie mehr Arbeitsspeicher pro Kern und verwendet lokalen SSD-Speicher, der für leistungsempfindliche Workloads konzipiert ist.
Hyperscale	Hyperscale führt neue Funktionen für horizontale Skalierung ein, die erweiterte Techniken zum Hinzuzufügen von Computeknoten bei zunehmenden Datengrößen verwenden. Sie wird nur in einer einzelnen SQL-Datenbank unterstützt. Mit Hyperscale können Sie Speicher- und Computeressourcen erheblich über die Grenzwerte skalieren, die für die Dienstebenen „Universell“ und „Unternehmenskritisch“ verfügbar sind.

DTU-basiertes Modell

Im DTU-Modell sind drei Dienstebenen verfügbar: „Basic“, „Standard“ und „Premium“. Compute- und Speicherressourcen sind von der DTU-Ebene abhängig und bieten eine Reihe von Leistungsfunktionen mit einem festen Speicherlimit, einer festen Sicherungsaufbewahrung und festen Kosten.

Wenn Ihre Datenbank beispielsweise bis zudem Punkt anwächst, an dem sie das maximale Speicherlimit erreicht, müssten Sie Ihre DTU-Kapazität erhöhen, auch wenn die Computeauslastung gering ist.

Der Skalierungsvorgang für SQL-Datenbank kann zu einer kurzen Verbindungsunterbrechung am Ende des Skalierungsvorgangs führen. Es gibt zwei Hauptänderungen, die dieses Verhalten auslösen:

• Sobald Sie einen Skalierungsvorgang initiiert haben, der ein internes Failover erfordert.
• Beim Hinzufügen oder Entfernen von Datenbanken zum oder aus dem Pool für elastische Datenbanken.

Sie können eine ordnungsgemäße Wiederholungslogik in Ihrer Anwendung verwenden, um Verbindungsfehler zu behandeln.

Serverlose Computeebene

Trotz des Namens erfordert die serverlose Computeebene, dass Sie über einen Server mit Ihrer Datenbank verfügen. Die serverlose Option kann am besten als automatische Skalierungs- und Autopausenlösung für SQL-Datenbank betrachtet werden. Es ist effektiv, die Kosten in Entwicklungs- und Testumgebungen zu senken. Sie können z. B. ein Minimum und eine maximale vCores-Konfiguration für Ihre Datenbank einrichten, in der sie dynamisch basierend auf Ihrer Workload skaliert wird.

Mit dem Feature "Autopausenverzögerung" können Sie den Zeitraum definieren, in dem die Datenbank inaktiv ist, bevor sie automatisch angehalten wird. Die Autopausenverzögerungsfunktion kann von 1 Stunde bis sieben Tagen eingerichtet werden. Alternativ kann die Funktion "Autopausenverzögerung" deaktiviert werden.

Der Wiederaufnahmevorgang wird ausgelöst, wenn der nächste Versuch erfolgt, auf die Datenbank zuzugreifen, und es fallen nur Speichergebühren an, wenn die Datenbank angehalten wird.

Die Abbildung oben zeigt, wo Sie die Eigenschaften für die automatische Skalierung und autopause für die serverlose Computeebene ändern können.

Bereitstellungsmodell

Es gibt zwei Hauptbereitstellungsmodelle bei der Bereitstellung von SQL-Datenbank in Azure: Einzeldatenbank und Pool für elastische Datenbanken. Pools für elastische Datenbanken nutzen Ressourcen gemeinsam mit anderen Datenbanken, die Teil desselben Pools sind, während Ressourcen für einzelne Datenbanken unabhängig voneinander verwaltet werden.

SQL-Datenbank kann wie VMs mit Azure Resource Manager-Vorlagen, mit PowerShell, der Azure CLI oder dem Azure-Portal bereitgestellt werden.

Einzeldatenbank

Die Einzeldatenbank ist das einfachste Bereitstellungsmodell von Azure SQL-Datenbank. Sie verwalten jede Ihrer Datenbanken einzeln aus Skalierungs- und Datengrößenperspektive. Jede in diesem Modell bereitgestellte Datenbank verfügt über eigene dedizierte Ressourcen, auch wenn sie auf demselben logischen Server bereitgestellt wird.

Sie können die Nutzung von Datenbankressourcen über das Azure-Portal überwachen. Mit diesem Feature können Sie die Leistung der Datenbank leicht ermitteln, wie in der folgenden Abbildung gezeigt:

Elastischer Pool

Mit Pools für elastische Datenbanken können Sie Speicher- und Computeressourcen einer Gruppe von Datenbanken zuordnen, anstatt Ressourcen für jede Datenbank einzeln verwalten zu müssen. Darüber hinaus sind Pools für elastische Datenbanken einfacher zu skalieren als Einzeldatenbanken, weil die Skalierung einzelner Datenbanken aufgrund von Änderungen am Pool für elastische Datenbanken nicht mehr erforderlich ist.

Pools für elastische Datenbanken bieten eine kostengünstige Lösung für das SaaS-Anwendungsmodell (Software-as-a-Service), da Ressourcen von allen Datenbanken gemeinsam genutzt werden. Sie können Ressourcen entweder basierend auf dem DTU-basierten Kaufmodell oder dem auf virtuellen Kernen basierenden Kaufmodell konfigurieren.

Aufgrund der Art dieses Features wird empfohlen, Ihre Ressourcen kontinuierlich zu überwachen, um gleichzeitige Leistungsspitzen zu identifizieren, die sich auf andere Datenbanken auswirken könnten, die sich auf denselben elastischen Pool auswirken könnten. Häufig müssen Sie Ihre Zuordnungsstrategie erneut überprüfen, um sicherzustellen, dass genügend Ressourcen für alle Datenbanken verfügbar sind, die denselben Pool für elastische Datenbanken verwenden.

Der elastische Pool eignet sich gut für die mehrinstanzenfähige Architektur mit geringer durchschnittlicher Auslastung, wobei jeder Mandant über eine eigene Kopie der Datenbank verfügt.

Netzwerkoptionen

Azure SQL-Datenbank verfügt standardmäßig über einen öffentlichen Internetendpunkt. Der Zugriff auf diesen Endpunkt kann über Firewallregeln gesteuert oder auf bestimmte Azure-Netzwerke beschränkt werden, indem Features wie Virtual Network-Endpunkte oder Private Link verwendet werden.

Sichern und Wiederherstellen

Azure bietet nahtlose Sicherungs- und Wiederherstellungsfunktionen für SQL-Datenbank und SQL Managed Instance. Erfahren Sie mehr über einige der wichtigsten Features.

Kontinuierliche Sicherung

Mit SQL-Datenbank können Sie die Verwaltungseffizienz steigern, indem Sie wissen, dass Datenbanken regelmäßig gesichert werden und dass sie kontinuierlich in einen georedundanten Lesezugriffsspeicher (RA-GRS) kopiert werden.

Vollständige Sicherungen werden wöchentlich erstellt, differenzielle Sicherungen alle 12 bis 24 Stunden und Transaktionsprotokollsicherungen alle fünf bis zehn Minuten.

Geowiederherstellung

Da Sicherungen für SQL-Datenbank und SQL Managed Instance standardmäßig georedundante Sicherungen sind, können Sie Datenbanken problemlos in einer anderen geografischen Region wiederherstellen. Dies ist besonders nützlich für weniger strenge Notfallwiederherstellungsszenarien.

Sicherungsspeicher wird getrennt vom regulären Datenbankdateispeicher abgerechnet. Bei der Bereitstellung einer SQL-Datenbank-Instanz wird der Sicherungsspeicher jedoch ohne zusätzliche Kosten mit der maximalen Größe der für Ihre Datenbank ausgewählten Datenebene erstellt.

Die Dauer eines Geowiederherstellungsvorgangs kann von mehreren zugrunde liegenden Komponenten beeinflusst werden, einschließlich der Größe der Datenbank, der Anzahl von Transaktionsprotokollen, die an einem Wiederherstellungsvorgang beteiligt sind, und der Menge gleichzeitiger Wiederherstellungsanforderungen, die in der Zielregion verarbeitet werden.

Zeitpunktwiederherstellung (Point-in-Time-Restore, PITR)

Sie können eine Aufbewahrungsrichtlinie für einen bestimmten Zeitpunkt für jede Datenbank konfigurieren, die in einem Angebot für SQL-Datenbank ausgeführt wird. Die Aufbewahrungsdauer von SQL-Datenbank kann zwischen einem Tag und 35 Tagen festgelegt werden. Wenn keine Angabe erfolgt, beträgt die Standardkonfiguration sieben Tage.

Sie können Ihre Datenbanken zu einem bestimmten Zeitpunkt gemäß der definierten Aufbewahrungsdauer wiederherstellen. PITR wird jedoch nur unterstützt, wenn Sie eine Datenbank auf demselben Server wiederherstellen, von dem die Sicherung stammt. Sie können das Azure-Portal, Azure PowerShell, die Azure CLI oder die REST-API verwenden, um eine SQL-Datenbank wiederherzustellen.

Langzeitaufbewahrung (Long-Term Retention, LTR)

Langfristige Aufbewahrung ist nützlich für Szenarien, in denen Sie die Aufbewahrungsrichtlinie über den Zeitraum hinaus festlegen müssen, der von Azure angeboten wird. Sie können eine Aufbewahrungsrichtlinie für bis zu 10 Jahre festlegen, und diese Option ist standardmäßig deaktiviert.

In der Abbildung oben können Sie langfristige Aufbewahrungsrichtlinien über das Azure-Portal konfigurieren. Sobald die Datenbank ausgewählt ist, wird auf der rechten Seite des Bildschirms ein neuer Bereich geöffnet, in dem Sie die Standardeigenschaften überschreiben können.

Weitere Informationen zu automatisierten Sicherungen finden Sie unter Automatisierte Sicherungen – Azure SQL-Datenbank und Azure SQL Managed Instance.

Automatische Optimierung

Automatische Optimierung ist ein integriertes Feature, das auf Machine Learning-Regressionsfunktionen basiert und Optimierungsmöglichkeiten auf der Grundlage Ihrer Abfrageleistung automatisch identifiziert.

Automatische Optimierung umfasst derzeit die folgenden Features:

• Identifizieren kostspieliger Abfragen
• Erzwingen des letzten guten Ausführungsplans
• Hinzufügen von Indizes
• Entfernen von Indizes

Die Azure-Dienste verwenden eine Kombination aus integrierten erweiterten Features, um die besten Indizes für Ihr Abfragemuster zu ermitteln. Zunächst werden diese Indizes mit einer Kopie Ihrer Datenbank getestet und schließlich auf Ihre Datenbank angewendet.

Alle Datenbanken erben die Konfiguration von ihrem übergeordneten Server, und Sie können dieses Feature jederzeit problemlos deaktivieren.

Elastische Abfrage (Vorschau)

Mit elastischen Abfragen können Sie T-SQL-Abfragen ausführen, die mehrere Datenbanken in SQL-Datenbank überbrücken. Dieses Feature ist besonders nützlich für Anwendungen, die drei- und vierteilige Namen verwenden, die nicht geändert werden können. Außerdem erhöht es die Portabilität, da es Migration ermöglicht.

Elastische Abfragen unterstützen die folgenden Partitionierungsstrategien:

Dienstebene	Fähigkeit
Vertikale Partitionierung	Wird auch als „datenbankübergreifende Abfragen“ bezeichnet. Die Daten werden vertikal zwischen vielen Datenbanken partitioniert. Die Schemas unterscheiden sich für jede Datenbank. Beispielsweise können Sie über eine Datenbank verfügen, die für Kundendaten verwendet wird, und eine andere Datenbank, die für Zahlungsinformationen verwendet wird. Mithilfe von vertikaler Partitionierung können Sie jetzt eine datenbankübergreifende Abfrage zwischen beiden Datenbanken ausführen.
Horizontale Partitionierung	Wird auch als Sharding bezeichnet. Die Daten werden horizontal partitioniert, um Zeilen auf mehrere horizontal skalierte Datenbanken zu verteilen. In dieser Topologie bleibt das Schema für alle Shardingdatenbanken gleich. Sie unterstützt entweder ein Modell mit einem Mandanten oder Modelle mit mehreren Mandanten.

Elastische Aufträge

Das Feature für elastische Aufträge ist der SQL Server-Agent-Ersatz für Azure SQL-Datenbank. In gewissem Umfang entspricht der elastische Auftrag der Multiserververwaltungsfunktion, die für eine lokale SQL Server-Instanz verfügbar ist.

Sie können T-SQL-Befehle für mehrere Zielbereitstellungen ausführen, z. B. für SQL-Datenbanken, elastische Pools für SQL-Datenbank und SQL-Datenbanken in Shardzuordnungen. Datenbankressourcen können in verschiedenen Azure-Abonnements und/oder -Regionen ausgeführt werden. Die Ausführung erfolgt parallel, was bei der Automatisierung von Datenbankwartungsaufgaben nützlich ist.

SQL-Datenbank in Fabric

SQL-Datenbank in Microsoft Fabric ist eine leistungsstarke und vielseitige Lösung, die nahtlos in das breitere Microsoft-Ökosystem integriert werden kann. Sie ermöglicht Benutzern die Verwendung der Funktionen von SQL-Datenbanken in der Microsoft Fabric-Umgebung und bietet eine einheitliche Plattform zum Verwalten und Analysieren von Daten. Diese Integration ermöglicht es Organisationen, ihre Datenworkflows zu optimieren, die Zusammenarbeit zu verbessern und fundiertere Entscheidungsprozesse zu fördern.

Darüber hinaus unterstützt die SQL-Datenbank in Microsoft Fabric eine Vielzahl von Anwendungsfällen, von Betriebs- und transaktionalen Workloads bis hin zu erweiterten Analysen. Diese Flexibilität macht es zu einer idealen Wahl für Organisationen, die ihre Dateninfrastruktur konsolidieren und das volle Potenzial ihrer Datenressourcen nutzen möchten. Mit Features wie einer nahtlosen Integration mit anderen Microsoft-Diensten, verbesserter Sicherheit und Skalierbarkeit ermöglicht SQL Database in Microsoft Fabric Benutzern das Erstellen und Bereitstellen von datengesteuerten Anwendungen mit Leichtigkeit.

Die Arbeitsauslastung der Datenbanken in Fabric wurde entwickelt, um sich mit vielen Aspekten der operativen SQL-Datenbanken zu befassen, sodass Datentechniker, Analysten und Data Scientists zusammenarbeiten können, um Daten zu erstellen und abzufragen, die für ihre spezifischen Anforderungen optimiert sind.