Mehrinstanzenfähigkeit und Azure SQL-Datenbank

Mehrinstanzenfähige Lösungen in Azure verwenden in der Regel Azure SQL-Datenbank. In diesem Artikel werden Partitionierungs- und Mandantenstrategien und SQL-Datenbankfeatures für mehrinstanzenfähige Lösungen beschrieben.

Lesen Sie diesen Artikel zusammen mit Architekturansätzen für Speicher und Daten in mehrinstanzenfähigen Lösungen; dort werden allgemeine Überlegungen und Ansätze beschrieben, die für verschiedene Datendienste gleichermaßen gelten.

Partitionierungs- und Mandantenstrategien

Wählen Sie das Mandantenmodell aus, das den Skalierungs-, Isolations-, Wiederherstellungs-, Anpassungs- und Kostenanforderungen der Workload entspricht. Bevorzugen Sie das einfachste Modell, das diese Anforderungen erfüllt. Sharding erhöht die Komplexität auf Anwendungs- und Betriebsebene; führen Sie es daher nicht ein, nur um Beschränkungen zu umgehen, die sich durch eine höhere Dienstebene abdecken ließen.

Um die architektonischen Kompromisse gängiger Mandantenmodelle (Tenancy-Modelle) für Azure SQL-Datenbanken zu vergleichen, siehe Auswahl des geeigneten Mandantenmodells.

Entscheiden, ob eine oder mehrere Datenbanken verwendet werden sollen

Eine einzelne SQL-Datenbank verfügt über begrenzte Speicherkapazität. Der Durchsatz und die Parallelität werden durch die Dienstebene, die Computekonfiguration, Verbindungsbeschränkungen und Workloadmerkmale eingeschränkt. Schätzen Sie die aggregierten Anforderungen und die Anforderungen pro Mandant für Speicher, Durchsatz, Parallelität, Latenz, Isolation, Wiederherstellung und regionale Konfiguration, bevor Sie eine freigegebene Datenbank, eine Datenbank für jeden Mandanten oder eine Sharded-Topologie auswählen.

Die Datenbankgrenze bestimmt auch die Granularität von Sicherungs-, Wiederherstellungs-, Georeplikations- und Failovervorgängen. Weitere Informationen finden Sie unter Bewährte Methoden für die Architektur für Azure SQL-Datenbank.

Eine freigegebene mandantenfähige Datenbank kann eine hohe Mandantendichte und niedrige Kosten pro Mandant bereitstellen, aber mehrere Datenbanken sind möglicherweise angemessen, bevor eine einzelne Datenbank ihre technischen Grenzen erreicht, wenn Mandanten eine stärkere Isolierung oder unabhängige Konfiguration und Lebenszyklusvorgänge erfordern.

Sie können Mandantenmodelle kombinieren. Sie können beispielsweise die meisten Mandanten in freigegebenen Datenbanken platzieren und Mandanten mit hoher Nachfrage oder regulatorischen Anforderungen dedizierte Datenbanken zuweisen. Verwenden Sie einen Mandantenkatalog, um jeden Mandanten der entsprechenden Datenbank zuzuordnen.

Bewerten Sie die Hyperscale-Dienstebene, wenn datenbankgröße, Sicherungs- und Wiederherstellungsdauer, Leseskalierung oder schnelle Computeskalierung das Design bestimmen. Hyperscale unterstützt den automatisch wachsenden Speicher von bis zu 128 TB für eine Datenbank und bis zu 100 TB für einen Hyperscale-Elastikpool. Wenn eine vorhandene Architektur nur Sharding verwendet, um Datenbankspeichergrenzwerte zu umgehen, sollten Sie die Shards in einer Hyperscale-Datenbank konsolidieren. Überprüfen Sie den Schreibdurchsatz, Kosten, Wiederherstellungsziele, Isolation und betriebliche Anforderungen vor der Konsolidierung.

Freigegebene mehrinstanzenfähige Datenbank

Speichern Sie in einer freigegebenen Datenbank einen Mandantenbezeichner in jeder Tabelle, die daten im Besitz des Mandanten enthält. Übertragen Sie authentifizierte Benutzer- und Mandantenidentitäten für jede Anfrage in die Datenbank. Richten Sie diesen Kontext ein und überprüfen Sie ihn, wenn Sie eine poolierte Verbindung wiederverwenden, anstatt sich auf den Kontext einer vorherigen Anforderung zu verlassen. Verwenden Sie Row-Level Security als durch die Datenbank erzwungenen Schutz vor mandantenübergreifendem Datenzugriff.

Alle Mandanten teilen die Compute-, Speicher-, Sicherungs-, Wiederherstellungs- und regionalkonfiguration der Datenbank. Dieses Modell ist anfällig für das Antipattern "Noisy Neighbor", bei dem sich die Arbeitsauslastung eines Mandanten auf andere Mandanten auswirkt. Das Wiederherstellen oder Verschieben eines Mandanten erfordert anwendungsgesteuerte Datenextraktion und -validierung. Verwenden Sie dieses Modell, wenn Mandantendichte und Kosteneffizienz wichtiger sind als mandantenspezifische Konfiguration oder starke Leistungsisolation.

Datenbank pro Mandant

Verwenden Sie eine separate Datenbank für jeden Mandanten, wenn Mandanten eine stärkere Daten- und Leistungsisolation, unabhängige Sicherung und Wiederherstellung, Schemaanpassung, regionale Platzierung oder klarere Kostenzuordnung erfordern. Die Anwendung muss eine zuverlässige Zuordnung von jedem Mandantenbezeichner zu seiner Datenbank beibehalten und Verbindungen entsprechend weiterleiten.

Platzieren Sie Datenbanken mit kompatiblen Leistungs- und Wiederherstellungsanforderungen in elastischen Pools , um bereitgestellte Compute zu teilen. Verwenden Sie Hyperscale oder elastische Hyperscale-Pools, wenn einzelne Mandantendatenbanken Hyperscale-Speicher, Sicherung, Wiederherstellung oder Lesefunktionen erfordern.

Geshardete mehrinstanzenfähige Datenbanken

Verwenden Sie horizontal partitionierte Multitenant-Datenbanken, wenn die Verteilung von Mandanten auf mehrere gemeinsam genutzte Datenbanken die Anforderungen der Workload an Skalierung, Wiederherstellung, Mandantendichte oder Kosten besser erfüllt als eine einzelne gemeinsam genutzte Datenbank oder eine Datenbank-pro-Mandant-Topologie. Ein Shard ist eine Azure SQL Datenbank, die einen oder mehrere Mandanten speichert. Verwenden Sie einen stabilen Shardschlüssel, z. B. einen Mandantenbezeichner, damit die Anwendung bestimmen kann, welche Datenbank die Daten eines Mandanten speichert.

Behandeln Sie das Dataset jedes Mandanten als Platzierungseinheit. Bewahren Sie alle Daten für einen Mandanten nach Möglichkeit in einem Shard auf, sodass mandantenbezogene Abfragen und Transaktionen in einer Datenbank verbleiben. Verwalten Sie eine Zuordnung von jedem Mandantenbezeichner zu der Datenbank, die ihre Daten enthält.

Eine Mandanten-zu-Datenbank-Zuordnung wird häufig als Shardmap bezeichnet. Eine Shard-Karte ist ein Katalog, der jedem Shardschlüssel oder einem Schlüsselbereich die Datenbank zuordnet, in der die zugehörigen Daten gespeichert werden. Implementieren Sie die Shardmap als dauerhafte Anwendungsmetadaten, die die Verfügbarkeits- und Konsistenzanforderungen der Workload erfüllen. Anwendungsinstanzen können Shard-Map-Einträge zwischenspeichern, um die Routinglatenz zu reduzieren, aber sie müssen zwischengespeicherte Einträge aktualisieren oder ungültig machen, wenn sich Zuordnungen ändern.

Machen Sie die autoritative Shardmap hochgradig verfügbar und aktualisieren Sie sie atomisch mit Mandantenmigrationsvorgängen. Die Anwendung muss auch für Verbindungsrouting, Shardbereitstellung, Mandantenbewegung, Rebalancing und Fehlerbehandlung verantwortlich sein. Planen Sie, wie die Anwendung veraltete Zuordnungen während der Umschaltung und des Rollbacks verarbeitet. Allgemeine Entwurfsanleitungen finden Sie im Shardingmuster.

Datenbankübergreifende Vorgänge planen

Entwerfen Sie jede Datenbank als unabhängige Transaktions- und Integritätsgrenze:

  • Datenlokalität und Integrität beibehalten: Bewahren Sie Daten, die die Anwendung per Join zusammenführt oder transaktional aktualisiert, in derselben Datenbank auf. Erstellen Sie keine Abhängigkeiten über Datenbanken hinweg durch referenzielle Integrität, Trigger oder gespeicherte Prozeduren. Verwenden Sie für Geschäftsvorgänge, die Datenbanken umfassen, eine eventuelle Konsistenz oder ein anderes Koordinationsmuster auf Anwendungsebene.
  • Schemas einheitlich verwalten: Verwenden Sie dieselben Tabellen, Spalten, Indizes, Ansichten und gespeicherten Prozeduren in jedem Shard, sodass die Anwendung dieselbe Datenzugriffslogik verwenden kann, nachdem sie eine Anforderung an einen beliebigen Shard weitergeleitet hat. Automatisieren Sie Schemabereitstellungen über die Datenbankflotte hinweg, und verfolgen Sie die Schemaversion jeder Datenbank. Wenn Sie die Schemavariation absichtlich unterstützen, sollten Sie den Anwendungs- und Bereitstellungsprozess versionsbewusst gestalten.
  • Referenzdaten bewusst verwalten: Statische oder sich langsam ändernde Referenzdaten replizieren, wenn dadurch synchrone datenbankübergreifende Vorgänge vermieden werden. Definieren Sie, wie die Anwendung Updates verteilt und veraltete Kopien behandelt.
  • Shards ausgleichen und platzieren: Shards nach Datenvolumen und Anforderungslast ausgleichen, nicht nur nach Mandantenanzahl. Planen Sie einen automatisierten und wiederaufnehmbaren Prozess, um Mandanten zwischen Shards zu verschieben. Platzieren Sie Datenbanken entsprechend den Anforderungen für Mandantenlatenz, Datenresidenz und Notfallwiederherstellung.

Verwenden Sie Elastic Jobs für geplante Schemaänderungen, Wartung, Telemetriesammlung und andere Vorgänge in Datenbankgruppen. Für Berichterstellung und Analysen über Mandantendatenbanken hinweg verwenden Sie einen zentralen Analysespeicher – etwa Microsoft Fabric mittels Spiegelung für Azure SQL-Datenbank – oder eine ETL-Pipeline (Extract, Transform, Load) wie Azure Data Factory. Wenn eine Anwendung synchrone Fanoutabfragen erfordert, erstellen Sie eine Abfrage- und Aggregationsebene, die Timeout, Wiederholung, Teilweisefehler und Ergebniszusammenführungsverhalten definiert.

Features der SQL-Datenbank, die Mehrinstanzenfähigkeit unterstützen

SQL-Datenbank enthält viele Features, die mehrinstanzenfähige Funktionen unterstützen.

Elastische Pools

Elastic Pools teilen sich einen konfigurierten Satz von Computeressourcen auf demselben logischen Server über mehrere Datenbanken hinweg. Pools können Kosten reduzieren, wenn Mandantendatenbanken niedrige durchschnittliche Auslastung und seltene, nicht überlappende Nutzungsspitzen aufweisen. Datenbanken mit dauerhafter mittlerer bis hoher Auslastung eignen sich möglicherweise besser für dedizierte Rechenkapazität. Sie können mindeste und maximale Ressourcengrenzwerte für einzelne Pooldatenbanken festlegen, um den Ressourcenverbrauch einzuschränken, aber alle Datenbanken teilen weiterhin die Gesamtkapazität des Pools. Überwachen Sie sowohl die Aggregatpoolnutzung als auch die individuelle Datenbanknutzung.

Weitere Informationen finden Sie in den folgenden Ressourcen:

Hyperscale

Azure SQL-Datenbank Hyperscale trennt Compute vom Speicher, sodass Sie sie unabhängig voneinander skalieren können. Verwenden Sie Hyperscale, wenn eine gemeinsam genutzte mandantenfähige Datenbank oder die Datenbank eines einzelnen Mandanten höhere Speichergrenzen, schnelle Sicherungen und Wiederherstellungen oder Leseskalierung erfordert.

Weitere Informationen finden Sie in den folgenden Ressourcen:

Elastische Aufträge

Verwenden Sie Elastische Aufträge, um geplante Transact-SQL-Skripts (T-SQL) und Wartungsaufgaben auf einer oder mehreren Datenbanken auszuführen. Zielgruppen können einzelne Datenbanken, logische Server, elastische Pools und Datenbanken über mehrere Abonnements hinweg umfassen. Häufige Multitenant-Anwendungen umfassen die Bereitstellung von Schemaänderungen, das Verwalten von Anmeldeinformationen, das Sammeln von Telemetriedaten und das Ausführen von Batchdatenverarbeitungsaufgaben über mehrere Datenbanken hinweg.

Elastic Jobs stellen keine synchrone Abfrageschicht für Anwendungen bereit. Wenn eine Anwendungsanfrage mehrere Datenbanken abfragen und die Ergebnisse sofort aggregieren muss, implementieren Sie dieses Verhalten in einer Anwendung oder analytischen Ebene.

Weitere Informationen finden Sie unter Elastische Aufträge für Azure SQL-Datenbank.

Sicherheit auf Zeilenebene

Sicherheit auf Zeilenebene hilft beim Erzwingen der Isolation auf Mandantenebene in freigegebenen Tabellen. Weitere Informationen finden Sie unter Row-level security implementation on Azure SQL.

Schlüsselverwaltung

Azure SQL-Datenbank verwendet die transparente Datenverschlüsselung (TDE), um Daten im Ruhezustand zu verschlüsseln. Wenn Mandanten ihre eigenen Verschlüsselungsschlüssel bereitstellen müssen, verwenden Sie separate Datenbanken, und konfigurieren Sie vom Kunden verwaltete TDE-Schlüssel auf Datenbankebene. Verwenden Sie Always Encrypted, wenn das Datenbankmodul und seine Operatoren keinen Zugriff auf Klartextwerte in bestimmten vertraulichen Spalten haben dürfen. Überprüfen Sie die Anwendungs- und Abfragekompatibilität, da Always Encrypted einige Vorgänge für verschlüsselte Spalten einschränkt.

Beitragende

Microsoft verwaltet diesen Artikel. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautoren:

  • Paul Burpo | Principal Customer Engineer, FastTrack für Azure
  • John Downs | Principal Software Engineer, Azure Patterns & Practices

Andere Mitwirkende:

Um nicht-öffentliche LinkedIn-Profile anzuzeigen, melden Sie sich bei LinkedIn an.

Nächste Schritte

  • Zuletzt aktualisiert um