Mandantenfähigkeit und Azure Table Storage

Azure Table Storage speichert strukturierte, nichtrelationale Daten. In diesem Artikel werden Partitionierungsstrategien, Isolationsmodelle und Tabellenspeicherfunktionen für mandantenfähige Lösungen beschrieben. Es enthält Anleitungen, mit denen Sie Entitätsdaten und Anfragelast verteilen, Mandantenentitäten isolieren und Zugriff, Verschlüsselung und Nutzung verwalten können.

Partitionierungsstrategien

Der Tabellenspeicher partitioniert Entitäten automatisch basierend auf dem Wert der PartitionKey Eigenschaft. Jede Entität muss ein PartitionKey und ein RowKey enthalten. Zusammen identifizieren diese Eigenschaften die Entität eindeutig. Jede Eigenschaft kann eine Zeichenfolge von bis zu 1.024 Zeichen enthalten.

Alle Entitäten, die denselben PartitionKey Wert haben, gehören zur gleichen Partition. Wenn die Anwendung die erste Entität mit einem neuen PartitionKey Wert schreibt, erstellt Table Storage die entsprechende logische Partition und verwaltet die physische Platzierung. Der Tabellenspeicher verteilt Partitionen über Speicherknoten hinweg und kann sie neu ausgleichen, wenn sich Anforderungsmuster ändern. Mit dieser automatischen Partitionsverwaltung kann der Dienst beim Hinzufügen von Partitionsschlüsselwerten horizontal skaliert werden.

Schlüssel für Zugriffsmuster entwerfen

Wählen Sie PartitionKey- und RowKey-Werte basierend darauf aus, wie Ihre Anwendung Daten abfragt und ändert. Eine Punktabfrage, die beide Werte angibt, ist die effizienteste Abfrage. Abfragen, die ein PartitionKey und einen Bereich von RowKey-Werten angeben, scannen nur eine Partition. Abfragen, die keinen PartitionKey angeben, müssen mehrere Partitionen oder die gesamte Tabelle durchsuchen. Wählen Sie eine RowKey aus, die die Sortierreihenfolge und Bereichsabfragen unterstützt, die Ihre Workload am häufigsten verwendet.

Ein natürlicher Schlüssel eignet sich nur dann als PartitionKey, wenn er den Abfrage-, Verteilungs- und Transaktionsanforderungen der Workload entspricht. Wenn eine logische Partition genau eine Entität enthält, können Sie den natürlichen Schlüssel als PartitionKey und eine leere Zeichenfolge als RowKey verwenden. Wenn eine Entität über mehrere stabile Schlüsseleigenschaften verfügt, wählen Sie den Wert oder die Werte für PartitionKey, die die Anforderungslast verteilen, dominante Abfragen unterstützen und Entitäten gruppieren, die atomare Transaktionen erfordern. Verwenden Sie RowKey, um Entitäten innerhalb dieser Partition eindeutig zu identifizieren und zu ordnen. Wenn keine einzelne Eigenschaft diese Anforderungen erfüllt, erstellen Sie einen synthetischen Schlüssel, indem Sie stabile Eigenschaftswerte verketten.

Table Storage indiziert automatisch nur PartitionKey und RowKey. Wenn Sie regelmäßig andere Eigenschaften abfragen, sollten Sie das Indextabellenmuster implementieren, Entitäten duplizieren, um ein anderes Zugriffsmuster zu unterstützen, oder einen Datenspeicher verwenden, der sekundäre Indizes unterstützt. Weitere Informationen zum Abfrageentwurf finden Sie unter Entwurf für Abfragen.

Vertikales Partitionieren von Entitätseigenschaften

Verwenden Sie für logische Entitäten, die viele Eigenschaften enthalten, serverseitige Projektion, um nur die Eigenschaften abzurufen, die für jede Abfrage erforderlich sind. Wenn Gruppen von Eigenschaften wesentlich unterschiedliche Zugriffs- oder Aktualisierungsmuster aufweisen oder wenn sich eine logische Entität den Entitätsgrenzen von Table Storage nähert, erwägen Sie, sie auf mehrere Entitäten oder Tabellen aufzuteilen. Speichern Sie zusammengehörige Entitäten in derselben Tabelle mit demselben PartitionKey, wenn Sie diese in einer Entitätsgruppentransaktion aktualisieren müssen. Weitere Informationen finden Sie unter Entwurfsmuster für Tabellen.

Partitionsschlüssel-Granularität auswählen

Die Granularität von PartitionKey Werten wirkt sich auf Skalierbarkeit, Abfrageeffizienz und Transaktionsgrenzen aus:

  • Eine Partition für viele Entitäten: Die Verwendung desselben PartitionKey Werts für viele Entitäten hält verwandte Daten zusammen. Abfragen können die Entitätsgruppe aus einer Partition abrufen, und Entitätsgruppentransaktionen können die Entitäten atomar aktualisieren. Alle Anforderungen für diese Entitäten teilen jedoch das Durchsatzziel der Partition. Die Verwendung eines einzelnen PartitionKey-Werts für eine gesamte Tabelle kann zu einer heißen Partition führen und eignet sich nur für kleine Workloads.
  • Eine Partition für jede Entität: Die Verwendung eines eindeutigen PartitionKey Werts für jede Entität verteilt die Anforderungslast über viele Partitionen. Punktabfragen bleiben effizient, aber Abfragen, die mehrere Entitäten abrufen, müssen möglicherweise auf viele Partitionen zugreifen. Mehrere Entitäten können nicht an derselben Entitätsgruppentransaktion teilnehmen, da sie nicht dieselbe PartitionKey gemeinsam nutzen.
  • Eine Partition für jede verwandte Gruppe: Die gemeinsame Nutzung eines PartitionKey Werts zwischen Entitäten, die die Anwendung häufig abfragt oder aktualisiert, ergibt ein ausgewogenes Verhältnis zwischen Abfragelokalität, Transaktionsunterstützung und Skalierbarkeit. Bei einer mehrinstanzenfähigen Workload kann es sich bei der zugehörigen Gruppe um einen Mandanten oder einen Bucket mit Entitäten innerhalb eines großen Mandanten handeln.

Vermeiden Sie monoton steigende oder abnehmende PartitionKey Werte in Schreiblasten, z. B. 0001, 0002 und 0003. Diese Werte können Schreibvorgänge auf einen engen Schlüsselbereich konzentrieren und eine heiße Partition verursachen. Verwenden Sie stabiles Hashing oder Bucketing, wenn Sie Schreibvorgänge verteilen müssen, und testen Sie die Partitionierungsstrategie unter erwarteter Spitzenlast. Aktuelle Grenzwerte und Entwurfsanleitungen finden Sie unter "Skalierbarkeitsziele für Tabellenspeicher" und "Entwerfen einer skalierbaren Partitionierungsstrategie für Tabellenspeicher".

Partitionieren nach Mandant

In einer gemeinsam genutzten Tabelle können Sie den Mandantenbezeichner als PartitionKey verwenden, wenn sich die meisten Vorgänge auf einen einzelnen Mandanten beziehen und die Spitzenauslastung jedes Mandanten innerhalb des Skalierbarkeitsziels für eine einzelne Partition liegt. Für Entitäten mit 1 KiB verfügt eine Partition über einen Zieldurchsatz von bis zu 2.000 Entitäten pro Sekunde, und ein Speicherkonto hat eine maximale Anforderungsrate von 20.000 Transaktionen pro Sekunde. Ein überproportional aktiver Mandant kann eine heiße Partition verursachen und gedrosselt werden, selbst wenn andere Partitionen über ungenutzte Kapazität verfügen.

Durch das Erstellen weiterer Tabellen innerhalb desselben Speicherkontos wird das Anforderungsziel auf Kontoebene nicht erhöht. Wenn sich eine Partition ihrem Ziel nähert, verfeinern Sie die PartitionKey Strategie, um ihre Anforderungslast zu verteilen. Wenn sich die aggregierte Workload dem Zielwert des Speicherkontos nähert, verteilen Sie die Workload auf mehrere Speicherkonten.

Erstellen Sie für große oder aktive Mandanten mehrere mandantenbezogene PartitionKey Werte, indem Sie den Mandantenbezeichner mit einem stabilen Bucket oder domänenspezifischen Wert kombinieren. Dieser Ansatz verteilt die Entitäten eines Mandanten und die Anforderungslast über Partitionen hinweg, führt jedoch Kompromisse ein:

  • Mandantenweite Abfragen müssen möglicherweise mehrere Partitionen abfragen.
  • Entitätsgruppentransaktionen können sich nicht über die Partitionen des Mandanten erstrecken.
  • Die Anwendung muss Vorgänge an die richtige Partition weiterleiten.
  • Der Entwurf und die Ausstellung von auf Schlüsselbereiche bezogenen Shared Access Signatures (SAS) werden komplexer.

Transaktionsgrenzen planen

Tabellenspeicher unterstützt Entitätsgruppentransaktionen für Entitäten in derselben Tabelle, die denselben PartitionKey Wert aufweisen. Eine Transaktion kann höchstens 100 Entitäten enthalten, und ihre Nutzlast muss kleiner als 4 MiB sein. Alle Vorgänge in der Transaktion werden atomar entweder erfolgreich ausgeführt oder schlagen fehl.

Vorgänge, die sich über Partitionen erstrecken, sind nicht transaktional. Wenn ein Geschäftsvorgang Entitäten atomar aktualisieren muss, speichern Sie diese Entitäten in derselben Partition. Entwerfen Sie andernfalls die Anwendung so, dass sie Teilfehler behandeln kann und eine geeignete Konsistenzstrategie verwendet. Weitere Informationen finden Sie unter Ausführen von Entitätsgruppentransaktionen.

Isolationsmodelle

Nachdem Sie Ihre mandantenfähigen Partitionsschlüssel entwerfen, bestimmen Sie die Ebene der Mandantenisolation, die angewendet werden soll. Tabellenspeicher unterstützt freigegebene Tabellen, Tabellen für jeden Mandanten und Speicherkonten für jeden Mandanten. In der folgenden Tabelle sind die Unterschiede zwischen den Wichtigsten Mandantenisolationsmodellen für Tabellenspeicher zusammengefasst.

Consideration Freigegebene Tabellen mit mandantenfähigen Partitionsschlüsseln Tabellen für jeden Mandanten Speicherkonten für jeden Mandanten
Datenisolation Niedrig Die Anwendung oder eine auf einen Schlüsselbereich beschränkte freigegebene Zugriffssignatur (Shared Access Signature, SAS) erzwingt die Isolation. Low-medium Hoch
Leistungsisolation Low Niedrig Die meisten Kontingente und Grenzwerte gelten für das gesamte Speicherkonto. Hoch
Bereitstellungskomplexität Low Medium Hoch
Komplexität des Betriebs Low Medium Hoch
Beispielszenario Eine große Mehrinstanzenlösung verfügt über eine freigegebene Anwendungsebene. Mandantenspezifische SAS-URLs werden ausgegeben. Jeder Mandant verfügt über einen eigenen Bereitstellungsstempel.

Hinweis

Berücksichtigen Sie Kontingente und Grenzwerte, wenn Sie ein Isolationsmodell auswählen. Zu diesen Grenzwerten gehören Azure-Dienstgrenzwerte, Skalierbarkeitsziele für Tabellenspeicher und Skalierbarkeitsziele für den Speicherressourcenanbieter.

Freigegebene Tabellen mit mandantenbezogenen Partitionsschlüsseln

Wenn Sie eine einzelne freigegebene Tabelle verwenden, verwenden Sie den Mandantenbezeichner als den vollständigen PartitionKey für Mandanten, deren Daten und Anforderungslast in eine Partition passen, z. B. kleinere Mandanten, oder als eine Komponente eines Synthetischen PartitionKey für größere Mandanten. Wichtige Überlegungen zur Gestaltung und Skalierbarkeit finden Sie unter Partitionierungsstrategien.

SAS-Token ermöglichen es Ihnen, einen Partitionsschlüsselbereich anzugeben. Table Storage stellt sicher, dass Anforderungen, die die Signatur enthalten, nur auf Entitäten innerhalb der angegebenen Partitions- und Zeilenschlüsselbereiche zugreifen können. Wenn sich die Daten eines Mandanten über mehrere PartitionKey-Werte erstrecken, entwerfen Sie die Werte und SAS-Bereiche so, dass das Token keinen Zugriff auf die Entitäten eines anderen Mandanten gewähren kann. Sie können das Valet Key-Muster implementieren, um nicht vertrauenswürdigen Clients den Zugriff auf die Entitäten eines Mandanten zu ermöglichen, ohne anderen Mandanten Zugriff zu gewähren.

Wenn Ihre Anwendung im Auftrag von Mandanten auf eine freigegebene Tabelle zugreift, erzwingen Sie den Schlüsselbereich des Mandanten für jeden Vorgang. Eine Benennungskonvention für Partitionsschlüssel bietet allein keine Zugriffsisolation.

Tabellen für jeden Mandanten

Sie können einzelne Tabellen für jeden Mandanten innerhalb eines einzigen Speicherkontos erstellen. Es gibt keine Beschränkung auf die Anzahl der Tabellen, die Sie innerhalb eines Speicherkontos erstellen können.

Getrennte Tabellen bieten eine Routing- und Zugriffssteuerungsgrenze, bieten jedoch keine Leistungsisolierung. Alle Tabellen im Konto teilen sich die Kapazitäts- und Leistungsziele des Speicherkontos.

In diesem Szenario können Sie die Zugriffssteuerung für Table Storage, einschließlich SAS, verwenden, um den Zugriff auf die Daten jedes Mandanten zu verwalten.

Speicherkonten für jeden Mandanten

Die stärkste Isolationsebene verwendet ein dediziertes Speicherkonto für jeden Mandanten. Dieses Modell stellt eine vollständige Isolation von Speicherkontoschlüsseln sicher, die Unabhängig voneinander gedreht werden können. Außerdem können Sie Ihre Lösung über die Grenzwerte und Kontingente für jedes Speicherkonto skalieren. Betrachten Sie dieses Modell für Mandanten, die über anhaltende hohe Transaktionsvolumes verfügen oder unabhängige regionale Konfigurationen, Verschlüsselungsschlüssel oder Leistungsziele erfordern. Sie müssen auch die maximale Anzahl von Speicherkonten berücksichtigen, die innerhalb eines einzelnen Azure-Abonnements zulässig sind.

Features von Table Storage zur Unterstützung der Mandantenfähigkeit

Die folgenden Table Storage-Features können Ihnen dabei helfen, ihr ausgewähltes Isolationsmodell zu implementieren und zu betreiben.

Geteilte Zugriffssignaturen

Wenn Sie Tabellenspeicher aus einer Clientanwendung verwenden, überlegen Sie, ob Anforderungen über Ihre Anwendungsebene weitergeleitet werden sollen, oder ob Clients eine direkte Verbindung mit einer Tabelle herstellen können. Der direkte Clientzugriff kann die Last ihrer Back-End-Anwendungen und die Anzahl der Netzwerksprünge verringern.

Mit einer Shared Access Signature (SAS) können Sie Clientanwendungen eingeschränkten Zugriff auf eine Tabelle gewähren. Sie können die Vorgänge einschränken, die ein Client ausführen kann, die Partitions- und Zeilenschlüsselbereiche, auf die er zugreifen kann, und den Zeitraum, in dem der Zugriff zulässig ist. Sie können z. B. eine SAS ausgeben, mit der ein Mandant nur die Entitäten innerhalb eines eigenen Partitionsschlüsselbereichs lesen kann.

Verwenden Sie das Valet Key-Muster , um eingeschränkte und bereichsbezogene SAS-Token von Ihrer Anwendungsebene aus auszugeben. Authentifizieren Sie den Client mithilfe des Authentifizierungssystems Ihrer Anwendung, bestimmen Sie, auf welche Mandantenentitäten der Client zugreifen kann, und stellen Sie ein Token nur für die erforderlichen Schlüsselbereiche und Vorgänge aus.

Mithilfe von gespeicherten Zugriffsrichtlinien können Sie eine einzelne Richtlinie definieren, die verwendet werden soll, wenn Sie mehrere Dienst-SAS-Token ausstellen. Gespeicherte Zugriffsrichtlinien gelten nicht für SAS-Token für die Benutzerdelegierung oder Konto-SAS-Token.

SAS für die Benutzerdelegierung

Ein Sas- oder Konto-SAS des Diensts ist mit einem Ihrer Speicherkontoschlüssel signiert. Stattdessen wird eine Benutzerdelegierungs-SAS mit Microsoft Entra Anmeldeinformationen gesichert. Ihre Anwendungsebene fordert einen Benutzerdelegierungsschlüssel mithilfe einer eigenen verwalteten Identität an und signiert dann bereichsbezogene, zeitlich begrenzte Token für jeden Mandanten. Sie verteilen oder speichern keine Kontoschlüssel. Microsoft empfiehlt die Verwendung einer Benutzerdelegierungs-SAS anstelle einer SAS mit Kontoschlüssel, wenn Ihr Design sie unterstützt.

Verwenden Sie kurze Tokenlebensdauern, und planen Sie, wie Sie den Zugriff widerrufen, wenn ein Token kompromittiert wird. Um Ihre Anwendungsprotokolle mit Tabellenspeicherprotokollen zu korrelieren, legen Sie eine Clientanforderungs-ID (x-ms-client-request-id) für Speicheranforderungen fest, und protokollieren Sie sie zusammen mit der Mandanten-ID.

Identitätsbasierte Zugriffssteuerung

Tabellenspeicher bietet identitätsbasierte Zugriffssteuerung über Microsoft Entra ID. Verwenden Sie verwaltete Identitäten und Azure rollenbasierte Zugriffssteuerung, um Ihre Anwendung für den Zugriff auf Tabellen zu autorisieren, ohne Kontoschlüssel zu speichern. Beschränken Sie den Zugriff auf die Tabelle des jeweiligen Mandanten, wenn Mandanten direkten Zugriff benötigen. Rollenzuweisungen auf Tabellenebene beschränken den Zugriff auf die Partition eines Mandanten innerhalb einer freigegebenen Tabelle nicht.

Encryption

Der Tabellenspeicher verschlüsselt ruhende Daten standardmäßig mit Microsoft verwalteten Schlüsseln. Um kundenseitig verwaltete Schlüssel zu verwenden, konfigurieren Sie das Speicherkonto für die Verwendung eines kontobezogenen Verschlüsselungsschlüssels für Tabellen, wenn Sie das Konto erstellen. Sie können diesen Verschlüsselungsschlüsselbereich nach der Kontoerstellung nicht mehr ändern. Kapazität und Transaktionen in Table Storage werden zu unterschiedlichen Tarifen abgerechnet, wenn das Konto für die Verwendung eines kontobezogenen Verschlüsselungsschlüssels für Tabellen erstellt wird, selbst wenn der Schlüssel von Microsoft verwaltet wird.

Wenn Mandanten separate vom Kunden verwaltete Schlüssel benötigen, verwenden Sie separate Speicherkonten. Blob Storage-Verschlüsselungsbereiche und kundenseitig bereitgestellte Schlüssel für einzelne Anforderungen gelten nicht für Table Storage. Planen Sie die Schlüsselrotation und den Schlüsselwiderruf im Einklang mit Ihrem Mandantenlebenszyklus.

Monitoring

Überlegen Sie in einer mehrinstanzenfähigen Lösung, ob Sie den Verbrauch für jeden Mandanten messen müssen. Definieren Sie die spezifischen Metriken, die nachverfolgt werden sollen, z. B. die Anzahl der Entitäten oder Vorgänge für die Daten jedes Mandanten. Sie können die Kostenzuordnung auch verwenden, um die Kosten der Nutzung jedes Mandanten nachzuverfolgen und Rückbuchungen für mehrere Abonnements zu aktivieren.

Der Tabellenspeicher bietet integrierte Überwachungsfunktionen. Wenn Mandanten eine Tabelle freigeben, schließen Sie Mandanten-IDs in Ihre Anwendungstelemetrie ein, sodass Sie Vorgänge und die Nutzung dem richtigen Mandanten zuordnen können.

Überwachen Sie die Anforderungsraten sowie die Antworten HTTP 500 und 503, um Partitionen oder Konten zu erkennen, die sich den Skalierbarkeitszielen nähern. Korrelieren Sie diese Telemetrie mit Mandanten-IDs, damit Sie Mandanten identifizieren können, deren Nutzung sich auf die gemeinsame Kapazität auswirkt.

Sie können Anfrageprotokolle sammeln und dann zusammen mit Ihrer Anwendungstelemetrie aggregieren und analysieren. Berücksichtigen Sie bei Lösungen, die ein hohes Volumen an Anfragen erzeugen, ob der Vorteil die Kosten für die Erfassung und Verarbeitung dieser Protokolle rechtfertigt.

Contributors

Dieser Artikel wird von Microsoft gepflegt. Die folgenden Mitwirkenden haben diesen Artikel geschrieben.

Hauptautor:

  • John Downs | Principal Software Engineer, Azure Patterns & Practices

Andere Mitwirkende:

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

  • Zuletzt aktualisiert um