Freigeben über

Mehrinstanzenfähigkeit und Azure Cosmos DB

  • Artikel

Auf dieser Seite werden einige der Funktionen von Azure Cosmos DB beschrieben, die nützlich sind, wenn Sie mit mehrmandantenfähigen Systemen arbeiten. Darüber hinaus finden Sie Links zu Anleitungen und Beispielen für die Verwendung von Azure Cosmos DB in einer mehrinstanzenfähigen Lösung.

Features von Azure Cosmos DB, die Mehrinstanzenfähigkeit unterstützen

Partitionierung

Wenn Sie Partitionen mit Ihren Azure Cosmos DB-Containern verwenden, können Sie Container erstellen, die von mehreren Mandanten gemeinsam genutzt werden. In der Regel verwenden Sie den Mandantenbezeichner als Partitionsschlüssel, aber Sie können auch mehrere Partitionsschlüssel für einen einzelnen Mandanten verwenden. Eine gut geplante Partitionierungsstrategie implementiert das Shardingmuster auf effektive Weise. Bei großen Containern verteilt Azure Cosmos DB Ihre Mandanten auf mehrere physische Knoten, um ein hohes Maß an Skalierung zu erreichen.

Sie sollten die Verwendung hierarchischer Partitionsschlüssel überprüfen, um die Leistung Ihrer mehrmandantenfähigen Lösung zu verbessern. Mit hierarchischen Partitionsschlüsseln können Sie einen Partitionsschlüssel erstellen, der mehrere Werte enthält. Sie könnten zum Beispiel einen hierarchischen Partitionsschlüssel verwenden, der die Kennung des Mandanten und die Art der gespeicherten Daten enthält. Mit diesem Ansatz können Sie den Grenzwert für logische Partitionen von 20 GB pro Partitionsschlüsselwert überschreiten.

Weitere Informationen:

Verwalten von Anforderungseinheiten

Das Preismodell von Azure Cosmos DB basiert auf der Anzahl der Anforderungseinheiten (Request Unit, RU) pro Sekunde, die Sie bereitstellen oder nutzen. Eine Anforderungseinheit ist eine logische Abstraktion der Kosten für einen Datenbankvorgang oder eine Abfrage. In der Regel stellen Sie eine definierte Anzahl von Anforderungseinheiten pro Sekunde für Ihre Workload zur Verfügung, die als Durchsatz bezeichnet wird. Azure Cosmos DB bietet mehrere Optionen für die Art der Bereitstellung des Durchsatzes. In einer mehrinstanzenfähigen Umgebung wirkt sich die von Ihnen getroffene Auswahl auf die Leistung und den Preis Ihrer Azure Cosmos DB-Ressourcen aus.

Ein Mandantenmodell für Azure Cosmos DB umfasst die Bereitstellung separater Container für jeden Mandanten innerhalb einer freigegebenen Datenbank. Mit Azure Cosmos DB können Sie Anforderungseinheiten für eine Datenbank bereitstellen, und alle Container verwenden die Anforderungseinheiten gemeinsam. Wenn sich Ihre Mandantenworkloads in der Regel nicht überschneiden, kann dies ein nützlicher Ansatz zur Verringerung Ihrer Betriebskosten sein. Dieser Ansatz ist jedoch anfällig für das Noisy Neighbor-Problem, weil der Container eines einzelnen Mandanten möglicherweise eine unverhältnismäßig große Menge der gemeinsam genutzten, bereitgestellten Anforderungseinheiten verbraucht. Um dieses Problem zu beheben, müssen Sie zuerst die störenden Mandanten identifizieren. Anschließend können Sie ggf. den bereitgestellten Durchsatz für einen bestimmten Container festlegen. Die anderen Container in der Datenbank teilen weiterhin ihren Durchsatz, aber der störende Mandant verbraucht seinen eigenen dedizierten Durchsatz.

Azure Cosmos DB bietet außerdem eine serverlose Ebene, die für Workloads mit zeitweiligem oder unvorhersehbarem Datenverkehr geeignet ist. Alternativ können Sie mit der automatischen Skalierung Richtlinien konfigurieren, um die Skalierung des bereitgestellten Durchsatzes anzugeben. Darüber hinaus können Sie die Vorteile der Azure Cosmos DB Burst-Kapazität nutzen und so die Auslastung Ihrer bereitgestellten Durchsatzkapazität maximieren, die ansonsten auf einen Grenzwert begrenzt gewesen wäre. In einer mehrinstanzenfähigen Lösung können Sie alle diese Ansätze kombinieren, um verschiedene Mandantentypen zu unterstützen.

Hinweis

Stellen Sie beim Planen Ihrer Azure Cosmos DB-Konfiguration sicher, dass Sie die Dienstkontingente und -grenzwerte berücksichtigen.

Um die Kosten zu überwachen und zu verwalten, die den einzelnen Mandanten zugeordnet sind, umfasst jeder Vorgang, der die Azure Cosmos DB-API verwendet, die verbrauchten Anforderungseinheiten. Sie können diese Informationen verwenden, um die tatsächlich von den einzelnen Mandanten verbrauchten Anforderungseinheiten zu aggregieren und zu vergleichen. Anschließend können Sie Mandanten mit unterschiedlichen Leistungsmerkmalen identifizieren.

Weitere Informationen:

Vom Kunden verwaltete Schlüssel

Einige Mandanten erfordern möglicherweise die Verwendung ihrer eigenen Verschlüsselungsschlüssel. Azure Cosmos DB bietet ein Feature für kundenseitig verwaltete Schlüssel. Dieses Feature wird auf der Ebene eines Azure Cosmos DB-Kontos angewendet, sodass Mandanten, die ihre eigenen Verschlüsselungsschlüssel benötigen, mithilfe dedizierter Azure Cosmos DB-Konten bereitgestellt werden müssen.

Weitere Informationen:

Isolationsmodelle

Bei der Arbeit mit einem mehrinstanzenfähigen System, das Azure Cosmos DB verwendet, müssen Sie eine Entscheidung über den Isolationsgrad treffen, den Sie verwenden möchten. Business-to-Business (B2B) bezieht sich auf Verkäufe an ein Unternehmen. Business-to-Consumer (B2C) bezieht sich auf den direkten Verkauf an einen einzelnen Kunden, der das Produkt oder die Dienstleistung nutzt. Azure Cosmos DB unterstützt mehrere Isolationsmodelle:

Workload-Bedarf Partitionsschlüssel pro Mandant Container pro Mandant (gemeinsamer Durchsatz) Container pro Mandant (dedizierter Durchsatz) Datenbank pro Mandant Datenbankkonto pro Mandant
Mandantenübergreifende Abfragen Einfach (Container fungiert als Grenze für Abfragen) Schwierig Schwierig Schwierig Schwierig
Mandantendichte Hoch (geringste Kosten pro Mandant) Medium Niedrig Niedrig Niedrig
Löschen von Mandantendaten Schwierig Einfach (Container löschen, wenn der Mandant geht) Einfach (Container löschen, wenn der Mandant geht) Einfach (Datenbank löschen, wenn der Mandant geht) Einfach (Datenbank löschen, wenn der Mandant geht)
Isolation der Datenzugriffssicherheit Muss in Anwendung implementiert werden Container-RBAC Container-RBAC Datenbank-RBAC RBAC
Georeplikation Mandantenspezifische Georeplikation nicht möglich Gruppierung von Mandanten in Datenbankkonten abhängig von den Anforderungen Gruppierung von Mandanten in Datenbankkonten abhängig von den Anforderungen Gruppierung von Mandanten in Datenbankkonten abhängig von den Anforderungen Gruppierung von Mandanten in Datenbankkonten abhängig von den Anforderungen
Noisy Neighbor-Schutz Keine Keine Ja Ja Ja
Wartezeit bei der Erstellung neuer Mandanten Unmittelbar Schnell Schnell Medium Langsam
Vorteile der Datenmodellierung Keine Kollokation von Entitäten Kollokation von Entitäten Mehrere Container zum Modellieren von Mandantenentitäten Mehrere Container und Datenbanken zum Modellieren von Mandanten
Verschlüsselungsschlüssel Identisch für alle Mandanten Identisch für alle Mandanten Identisch für alle Mandanten Identisch für alle Mandanten Kundenseitig verwalteter Schlüssel pro Mandant
Durchsatzanforderungen >0 RUs pro Mandant >100 RUs pro Mandant >100 RUs pro Mandant (nur mit automatischer Skalierung, andernfalls >400 RUs pro Mandant) >400 RUs pro Mandant >400 RUs pro Mandant
Beispiel eines Anwendungsfalls B2C-Apps Standardangebot für B2B-Apps Premium-Angebot für B2B-Apps Premium-Angebot für B2B-Apps Premium-Angebot für B2B-Apps

Partitionsschlüssel pro Mandant

Wenn Sie einen einzelnen Container für mehrere Mandanten verwenden, können Sie die Partitionierungsunterstützung von Azure Cosmos DB nutzen. Durch die Verwendung separater Partitionsschlüssel für jeden Mandanten können Sie die Daten problemlos für einen einzelnen Mandanten ganz einfach abfragen. Sie können auch mehrere Mandanten abfragen, auch wenn sie sich in separaten Partitionen befinden. Partitionsübergreifende Abfragen haben jedoch höhere Kosten für Anforderungseinheiten (Request Unit, RU) als Einzelpartitionsabfragen.

Dieser Ansatz funktioniert in der Regel gut, wenn die Menge der für jeden Mandanten gespeicherten Daten gering ist. Er kann eine gute Wahl für die Entwicklung eines Preismodells sein, das einen Free-Tarif (kostenlos) umfasst, sowie für B2C-Lösungen (Business-to-Consumer). Im Allgemeinen erzielen Sie durch die Verwendung freigegebener Container die höchste Dichte von Mandanten und somit den niedrigsten Preis pro Mandant.

Es ist wichtig, den Durchsatz Ihres Containers zu berücksichtigen. Alle Mandanten nutzen den Durchsatz des Containers gemeinsam, sodass das Noisy Neighbor-Problem Leistungsherausforderungen verursachen kann, wenn Ihre Mandanten über hohe oder überlappende Workloads verfügen. Dieses Problem kann manchmal durch Gruppieren von Teilmengen der Mandanten in verschiedene Container behoben werden, und indem sichergestellt wird, dass jede Mandantengruppe kompatible Nutzungsmuster hat. Alternativ können Sie ein Hybridmodell mit mehreren und einem Mandanten in Betracht ziehen. Gruppieren Sie kleinere Mandanten in freigegebene partitionierte Container, und weisen Sie großen Kunden dedizierte Container zu. Darüber hinaus gibt es Features, mit denen das Nosiy Neighbor-Problem bei der Modellierung von Mandanten über Partitionen gesteuert werden kann, z. B. Durchsatzumverteilung, Burstkapazität und Durchsatzsteuerung im Java SDK.

Es ist auch wichtig, die Menge der Daten zu berücksichtigen, die Sie in jeder logischen Partition speichern. Mit Azure Cosmos DB kann jede logische Partition auf bis zu 20 GB anwachsen. Wenn Sie über einen einzelnen Mandanten verfügen, der mehr als 20 GB an Daten speichern muss, sollten Sie erwägen, die Daten auf mehrere logische Partitionen zu verteilen. Anstatt beispielsweise über einen einzelnen Partitionsschlüssel von Contoso zu verfügen, können Sie die Partitionsschlüssel durch Erstellen mehrerer Partitionsschlüssel für einen Mandanten wie als Salt verwenden, z. B. Contoso1, Contoso2 usw. Wenn Sie die Daten für einen Mandanten abfragen, können Sie die WHERE IN-Klausel verwenden, um alle Partitionsschlüssel abzugleichen. Hierarchische Partitionsschlüssel können ebenfalls verwendet werden, um große Mandanten mit einem Speicher von mehr als 20 GB zu unterstützen, ohne synthetische Partitionsschlüssel oder mehrere Partitionsschlüsselwerte pro Mandant verwenden zu müssen.

Berücksichtigen Sie die betrieblichen Aspekte Ihrer Lösung und die verschiedenen Phasen des Mandantenlebenszyklus. Wenn ein Mandant beispielsweise in einen dedizierten Tarif wechselt, müssen Sie die Daten wahrscheinlich in einen anderen Container verschieben. Wenn die Bereitstellung eines Mandanten aufgehoben wird, müssen Sie eine Löschabfrage für den Container ausführen, um die Daten zu entfernen. Bei großen Mandanten kann diese Abfrage während der Ausführung eine erhebliche Menge an Durchsatz verbrauchen.

Container pro Mandant

Sie können für jeden Mandanten dedizierte Container bereitstellen. Dedizierte Container funktionieren gut, wenn die Daten, die Sie für Ihren Mandanten speichern, in einem einzelnen Container zusammengefasst werden können. Dieses Modell ermöglicht eine höhere Leistungsisolation als das oben genannte Modell mit mandantenspezifischen Partitionsschlüsseln und bietet auch eine erhöhte Isolation der Datenzugriffssicherheit über Azure RBAC.

Wenn Sie einen Container für jeden Mandanten verwenden, können Sie erwägen, den Durchsatz mit anderen Mandanten zu teilen, indem Sie Durchsatz auf Datenbankebene bereitstellen. Berücksichtigen Sie die Einschränkungen und Grenzwerte für die Mindestanzahl von Anforderungseinheiten für Ihre Datenbank und die Höchstanzahl von Containern in der Datenbank. Überlegen Sie außerdem, ob Ihre Mandanten ein garantiertes Leistungsniveau benötigen und ob sie für das Noisy Neighbor-Problem anfällig sind. Bei einer gemeinsamen Nutzung des Durchsatzes auf Datenbankebene sollte Workload oder Speicherung für alle Container relativ einheitlich sein. Andernfalls kann es zu einem Noisy Neighbor-Problem kommen, wenn es einen oder mehrere große Mandanten gibt. Erwägen Sie ggf. eine Gruppierung dieser Mandanten in verschiedenen Datenbanken, die auf Workloadmustern basieren.

Alternativ können Sie dedizierten Durchsatz für jeden Container bereitstellen. Dieser Ansatz funktioniert gut für größere Mandanten und für Mandanten, für die das Risiko des Noisy Neighbor-Problems besteht. Der Baselinedurchsatz für jeden Mandanten ist jedoch höher. Berücksichtigen Sie daher die Mindestanforderungen und Kostenauswirkungen dieses Modells.

Wenn für Ihr Mandantendatenmodell mehrere Entitäten erforderlich sind, können sich die Entitäten gemeinsam im selben Container befinden, solange alle Entitäten denselben Partitionsschlüssel gemeinsam nutzen können. Wenn das Mandantendatenmodell jedoch komplexer ist und Entitäten erforderlich sind, die nicht denselben Partitionsschlüssel gemeinsam nutzen können, sollten Sie die unten erwähnten Modelle mit mandantenspezifischen Datenbanken oder Datenbankkonten in Betracht ziehen. Weitere Informationen finden Sie in unserem Artikel zum Modellieren und Partitionieren von Daten in Azure Cosmos DB anhand eines realen Beispiels.

Die Lebenszyklusverwaltung ist im Allgemeinen einfacher, wenn Container Mandanten dediziert zugeordnet werden. Sie können Mandanten problemlos zwischen Modellen mit gemeinsam genutztem und dediziertem Durchsatz verschieben, und wenn Sie die Bereitstellung eines Mandanten aufheben, können Sie den Container schnell löschen.

Datenbank pro Mandant

Sie können Datenbanken für jeden Mandanten im selben Datenbankkonto bereitstellen. Wie das obige Modell mit mandantenspezifischen Containern ermöglicht dieses Modell eine höhere Leistungsisolation als das Modell mit mandantenspezifischen Partitionsschlüsseln und bietet auch eine erhöhte Isolation der Datenzugriffssicherheit über Azure RBAC.

Wie das folgende Modell mit mandantenspezifischen Konten ermöglicht dieser Ansatz die höchste Leistungsisolation, aber die niedrigste Mandantendichte. Diese Option ist jedoch am besten geeignet, wenn jeder Mandant ein komplexeres Datenmodell benötigt, als im Modell mit mandatenspezifischen Containern machbar ist. Sie sollten diesen Ansatz auch befolgen, wenn neue Mandanten schnell und/oder ohne Mehraufwand für die Erstellung von Mandantenkonten im Voraus erstellt werden müssen. Es kann auch der Fall sein, dass abhängig vom jeweils verwendeten Softwareentwicklungsframework mandantenspezifische Datenbanken die einzige Möglichkeit zur Leistungsisolation sind, die im Framework verfügbar ist. Die Isolation auf Entitätsebene (Containerebene) und die Kollokation von Entitäten werden in solchen Frameworks in der Regel nicht nativ unterstützt.

Datenbankkonto pro Mandant

Mit Azure Cosmos DB können Sie separate Datenbankkonten für jeden Mandanten bereitstellen, was die höchste Isolationsstufe bietet, aber die niedrigste Dichte. Wie die oben genannten Modelle mit mandantenspezifischen Containern und Datenbanken bietet dieses Modell eine höhere Leistungsisolation als das Modell mit mandantenspezifischen Partitionsschlüsseln. Darüber hinaus bietet es eine höhere Isolation der Datenzugriffssicherheit über Azure RBAC. Darüber hinaus ermöglicht dieses Modell eine Isolation der Datenbankverschlüsselung auf Mandantenebene über kundenseitig verwaltete Schlüssel.

Einem Mandanten wird dediziert ein einzelnes Datenbankkonto zugeordnet, sodass das Noisy Neighbor-Problem nicht auftritt. Sie können den Position des Datenbankkontos den Anforderungen des Mandanten entsprechend konfigurieren. Sie können auch die Konfiguration von Azure Cosmos DB-Features wie Georeplikation und kundenseitig verwaltete Verschlüsselungsschlüssel an die Anforderungen des jeweiligen Mandanten anpassen. Wenn Sie ein dediziertes Azure Cosmos DB-Konto pro Mandant verwenden, berücksichtigen Sie die Höchstanzahl von Azure Cosmos DB-Konten pro Azure-Abonnement.

Wenn Sie dieses Modell verwenden, sollten Sie berücksichtigen, wie schnell Ihre Anwendung in der Lage sein muss, neue Mandanten zu generieren. Die Kontoerstellung in Azure Cosmos DB kann einige Minuten dauern, sodass Konten möglicherweise im Voraus erstellt werden müssen. Wenn dieser Ansatz nicht möglich ist, sollten Sie das Modell mit mandantenspezifischen Datenbanken in Betracht ziehen.

Wenn Sie Mandanten die Migration von einem freigegebenen Konto zu einem dedizierten Azure Cosmos DB-Konto erlauben, sollten Sie den Migrationsansatz in Betracht ziehen, den Sie verwenden, um die Daten eines Mandanten zwischen den alten und neuen Konten zu verschieben.

Hybridansätze

Sie können eine Kombination der oben genannten Ansätze in Betracht ziehen, um die Anforderungen verschiedener Mandanten und Ihr Preismodell zu erfüllen. Zum Beispiel:

  • Stellen Sie alle Kunden mit einer kostenlosen Testversion in einem freigegebenen Container bereit, und verwenden Sie die Mandanten-ID oder einen synthetischen Partitionsschlüssel.
  • Bieten Sie einen kostenpflichtigen Bronze-Tarif an, der einen dedizierten Container pro Mandant bereitstellt, aber mit gemeinsam genutztem Durchsatz für eine Datenbank.
  • Bieten Sie einen höheren Silver-Tarif an, der dedizierten Durchsatz für den Container des Mandanten bereitstellt.
  • Bieten Sie den höchsten Gold-Tarif an, und stellen Sie ein dediziertes Datenbankkonto für den Mandanten bereit, mit dem Mandanten auch die Geografie für ihre Bereitstellung auswählen können.

Beitragende

Dieser Artikel wird von Microsoft gepflegt. Er wurde ursprünglich von folgenden Mitwirkenden geschrieben:

Hauptautoren:

  • Paul Burpo | Principal Customer Engineer, FastTrack for Azure
  • John Downs | Principal Customer Engineer, FastTrack for Azure

Andere Mitwirkende:

Melden Sie sich bei LinkedIn an, um nicht öffentliche LinkedIn-Profile anzuzeigen.

Nächste Schritte

Überprüfen Sie dieSpeicher- und Datenansätze für Mehrinstanzenfähigkeit.

Weitere Informationen zu Mehrinstanzenfähigkeit und Azure Cosmos DB:

  • Azure Cosmos DB und mehrinstanzenfähige Systeme: In diesem Blogbeitrag wird die Erstellung eines mehrinstanzenfähigen Systems mit Azure Cosmos DB erläutert.
  • Mehrinstanzenfähige Anwendungen mit Azure Cosmos DB (Video)
  • Video: Building a multitenant SaaS with Azure Cosmos DB and Azure (Erstellen einer mehrinstanzenfähigen SaaS-Lösung mit Azure Cosmos DB und Azure): Eine Fallstudie aus der Praxis, die zeigt, wie Whally, ein Startup für mehrinstanzenfähiges SaaS, eine moderne Plattform von Grund auf in Azure Cosmos DB und Azure erstellt hat. Whally erläutert die Entwurfs- und Implementierungsentscheidungen, die in Bezug auf Partitionierung, Datenmodellierung, sichere Mehrinstanzenfähigkeit, Leistung, Echtzeitstreaming aus dem Änderungsfeed zu SignalR und mehr getroffen wurden. Alle diese Lösungen verwenden ASP.NET Core für Azure App Services.

Weitere Informationen finden Sie in unseren anderen Cosmos DB-Architekturszenarien: