Freigeben über

Mehrinstanzenfähigkeit und Azure Cosmos DB

  • Artikel

In diesem Artikel werden Die Features von Azure Cosmos DB beschrieben, die Sie für mehrinstanzenfähige Systeme verwenden können. Es enthält Anleitungen und Beispiele zur Verwendung von Azure Cosmos DB in einer mehrinstanzenübergreifenden Lösung.

Anforderungen an die Mehrinstanzenfähigkeit

Wenn Sie eine Mehrinstanzenlösung planen, haben Sie zwei wichtige Anforderungen:

  • Sorgen Sie für eine starke Isolation zwischen Mandanten und erfüllen Sie strenge Sicherheitsanforderungen für diejenigen, die sie benötigen.
  • Verwalten Sie eine niedrige Kosten pro Mandant. Stellen Sie als Anbieter sicher, dass die Kosten für die Ausführung der Anwendung bei der Skalierung nachhaltig bleiben.

Diese beiden Anforderungen können oft in Konflikt geraten und einen Kompromiss einführen, bei dem Sie eine Priorität gegenüber dem anderen festlegen müssen. Die Anleitung in diesem Artikel kann Ihnen helfen, die Trade-Offs besser zu verstehen, die Sie für diese Anforderungen vornehmen müssen. Dieser Artikel hilft Ihnen bei der Navigation in diesen Überlegungen, damit Sie fundierte Entscheidungen treffen können, wenn Sie Ihre mehrinstanzenfähige Lösung entwerfen.

Isolationsmodelle

Bestimmen Sie die Isolationsebene, die Sie zwischen Ihren Mandanten benötigen. Azure Cosmos DB unterstützt eine Reihe von Isolationsmodellen, aber für die meisten Lösungen empfehlen wir, eine der folgenden Strategien zu verwenden:

  • Ein Partitionsschlüssel pro Mandant wird häufig für vollständig mehrinstanzenfähige Lösungen wie Business-to-Consumer-Software as a Service (B2C SaaS)-Lösungen verwendet.
  • Ein Datenbankkonto pro Mandant wird häufig für SaaS-Lösungen (Business-to-Business, B2B) verwendet.

Um das am besten geeignete Isolationsmodell auszuwählen, berücksichtigen Sie Ihr Geschäftsmodell und die Anforderungen der Mandanten. Eine starke Leistungsisolation ist z. B. für einige B2C-Modelle möglicherweise nicht vorrangig, wenn ein Unternehmen ein Produkt oder eine Dienstleistung direkt an einen einzelnen Kunden verkauft. B2B-Modelle können jedoch eine starke Sicherheits- und Leistungsisolation priorisieren und erfordern möglicherweise, dass Mandanten über ein eigenes bereitgestelltes Datenbankkonto verfügen.

Sie können auch mehrere Modelle für unterschiedliche Kundenanforderungen kombinieren. Angenommen, Sie erstellen eine B2B SaaS-Lösung, die Sie an Unternehmenskunden verkaufen, und Sie bieten eine kostenlose Testversion für potenzielle neue Kunden. Sie können ein separates Datenbankkonto für kostenpflichtige Unternehmensmandanten bereitstellen, die starke Sicherheits- und Isolationsgarantien benötigen. Und Sie können ein Datenbankkonto freigeben und Partitionsschlüssel verwenden, um Testkunden zu isolieren.

Das Partitionsschlüssel-pro-Mandant-Modell und das Datenbankkonto-pro-Mandant-Modell sind die am häufigsten verwendeten Isolationsmodelle für Lösungen mit mehreren Mandanten. Diese Modelle bieten das beste Gleichgewicht zwischen Mandantenisolation und Kosteneffizienz.

Partitionsschlüssel-pro-Mandant-Modell

Wenn Sie Ihre Mandanten nach Partitionsschlüssel isolieren, wird der Durchsatz über Mandanten hinweg freigegeben und innerhalb desselben Containers verwaltet.

Hinweis

Eine Anforderungseinheit (RU) ist eine logische Abstraktion der Kosten eines Datenbankvorgangs oder einer Abfrage. In der Regel stellen Sie eine definierte Anzahl von Anforderungseinheiten pro Sekunde (RU/s) für Ihre Workload bereit, die als Durchsatz bezeichnet wird.

Vorteile

  • Kosteneffizienz: Sie platzieren alle Mandanten in einem Container, der von der Mandanten-ID partitioniert wird. Bei diesem Ansatz gibt es nur eine abrechnende Ressource, die RUs für mehrere Mandanten bereit stellt und gemeinsam verwendet. Dieses Modell ist in der Regel kostengünstiger und einfacher zu verwalten als separate Konten für jeden Mandanten.

  • Vereinfachte Verwaltung: Sie haben weniger Azure Cosmos DB-Konten zur Verwaltung.

Nachteile

  • Ressourcenverknügung: Der gemeinsame Durchsatz (SHARED Throughput, RU/s) über Mandanten hinweg, die sich im gleichen Container befinden, kann während der Spitzenauslastung zu Einer Beeinflussung führen. Diese Konflikte können zu lauten Nachbarnproblemen und Leistungsproblemen führen, wenn Ihre Mandanten über hohe oder überlappende Workloads verfügen. Verwenden Sie dieses Isolationsmodell für Arbeitslasten, die garantierte RUs für einen einzelnen Mandanten benötigen und den Durchsatz gemeinsam nutzen können.

  • Eingeschränkte Isolation: Dieser Ansatz bietet eine logische Isolation, nicht physische Isolation. Es erfüllt möglicherweise keine strengen Isolationsanforderungen aus Leistungs- oder Sicherheitsgründen.

  • Weniger Flexibilität: Sie können Features auf Kontoebene nicht anpassen, z. B. Georeplikation, Point-in-Time-Wiederherstellung und vom Kunden verwaltete Schlüssel für jeden Mandanten, wenn Sie den Partitionsschlüssel oder die Datenbank oder den Container isolieren.

Azure Cosmos DB-Features für Mehrinstanzenfähigkeit

  • Steuern Des Durchsatzes: Erkunden Sie Features, die helfen können, das laute Nachbarproblem zu steuern, wenn Sie einen Partitionsschlüssel zum Isolieren von Mandanten verwenden. Verwenden Sie Features wie Durchsatz-Relocation, Platzkapazität und Durchsatzsteuerung im Java SDK.

  • Hierarchische Partitionsschlüssel: Verwenden Sie Azure Cosmos DB, sodass jede logische Partition bis zu 20 GB vergrößert werden kann. 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. Statt beispielsweise einen einzelnen Partitionsschlüssel Contosozu haben, können Sie die Partitionsschlüssel verteilen, indem Sie mehrere Partitionsschlüssel für einen Mandanten erstellen, z Contoso1 . B. und Contoso2.

    Wenn Sie Daten für einen Mandanten abfragen, können Sie die WHERE IN Klausel verwenden, um alle Partitionsschlüssel abzugleichen. Sie können auch hierarchische Partitionsschlüssel verwenden, um große Mandanten mit mehr als 20 GB Speicherplatz bereitzustellen, wenn Sie eine hohe Kardinalität von Mandanten haben. Sie müssen für diese Methode keine synthetischen Partitionsschlüssel oder mehrere Partitionsschlüsselwerte pro Mandant verwenden.

    Angenommen, Sie haben eine Workload, die Mandanten nach Partitionsschlüssel isoliert. Ein Mandant, Contoso, ist größer und schreibintensiver als andere, und es nimmt weiterhin an Größe zu. Um das Risiko zu vermeiden, dass für diesen Mandanten keine weiteren Daten erfasst werden können, können Sie hierarchische Partitionsschlüssel verwenden. Geben Sie TenantID als Schlüssel der ersten Ebene an, und fügen Sie dann eine zweite Ebene wie UserId hinzu. Wenn Sie von der TenantID Kombination UserID ausgehen, dass logische Partitionen erzeugt werden, die den Grenzwert von 20 GB überschreiten, können Sie die Partition weiter nach unten auf eine andere Ebene wie z SessionID. B. . Abfragen, die eine TenantID oder beide TenantID angeben und UserID effektiv nur an die Teilmenge der physischen Partitionen weitergeleitet werden, die die relevanten Daten enthalten, wodurch eine vollständige Fanoutabfrage vermieden wird. Wenn der Container über 1.000 physische Partitionen verfügt, ein bestimmter TenantId Wert jedoch nur auf fünf physischen Partitionen liegt, wird die Abfrage an die kleinere Anzahl relevanter physischer Partitionen weitergeleitet.

    Wenn Ihre erste Ebene nicht über ausreichend hohe Kardinalität verfügt und Sie die logische Partitionsgrenze von 20 GB für Den Partitionsschlüssel erreichen, sollten Sie einen synthetischen Partitionsschlüssel anstelle eines hierarchischen Partitionsschlüssels verwenden.

Datenbankkonto-pro-Mandant-Modell

Wenn Sie Ihre Mandanten nach Datenbankkonto isolieren, verfügt jeder Mandant über einen eigenen Durchsatz auf Datenbankebene oder Containerebene.

Vorteile

  • Hohe Isolation: Dieser Ansatz vermeidet Konflikte oder Störungen aufgrund dedizierter Azure Cosmos DB-Konten und Container, die RUs pro eindeutigen Mandanten bereitgestellt haben.

  • Benutzerdefinierte Vereinbarungen auf Serviceebene (SLAs): Jeder Mandant verfügt über ein eigenes Konto, sodass Sie spezifische maßgeschneiderte Ressourcen, kundenorientierte SLAs und Garantien bereitstellen können, da Sie das Datenbankkonto jedes Mandanten unabhängig für den Durchsatz optimieren können.

  • Verbesserte Sicherheit: Physische Datenisolation trägt zur Gewährleistung einer robusten Sicherheit bei, da Kunden verwaltete Schlüssel auf Kontoebene pro Mandant aktivieren können. Die Daten jedes Mandanten sind durch ein Konto isoliert, anstatt sich im selben Container zu befinden.

  • Flexibilität: Mandanten können Features auf Kontoebene wie Georeplikation, Point-in-Time-Wiederherstellung und kundenverwaltete Schlüssel nach Bedarf aktivieren.

Nachteile

  • Erhöhte Verwaltung: Dieser Ansatz ist komplexer, da Sie mehrere Azure Cosmos DB-Konten verwalten.

  • Höhere Kosten: Mehr Konten bedeuten, dass Sie den Durchsatz für jede Ressource, z. B. Datenbanken oder Container, innerhalb des Kontos für jeden Mandanten bereitstellen müssen. Jedes Mal, wenn eine Ressource RUs bereit stellt, erhöhen sich ihre Azure Cosmos DB-Kosten.

  • Abfragebeschränkungen: Alle Mandanten befinden sich in verschiedenen Konten, sodass Anwendungen, die mehrere Mandanten abfragen, mehrere Aufrufe innerhalb der Logik der Anwendung erfordern.

Azure Cosmos DB-Features für Mehrinstanzenfähigkeit

  • Sicherheitsfeatures: Dieses Modell bietet erhöhte Datenzugriffssicherheitsisolation über Azure RBAC. Dieses Modell bietet auch die Sicherheitsisolation der Datenbankverschlüsselung auf Mandantenebene über vom Kunden verwaltete Schlüssel.

  • Benutzerdefinierte Konfiguration: Sie können die 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, sollten Sie die maximale Anzahl von Azure Cosmos DB-Konten pro Azure-Abonnement berücksichtigen.

Vollständige Liste der Isolationsmodelle

Workload-Bedarf Partitionsschlüssel pro Mandant (empfohlen) Container pro Mandant (gemeinsamer Durchsatz) Container pro Mandant (dedizierter Durchsatz) Datenbank pro Mandant Datenbankkonto pro Mandant (empfohlen)
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 Einfach 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 innerhalb der 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 No No Ja Ja Ja
Wartezeit bei der Erstellung neuer Mandanten Unmittelbar Schnell Schnell Medium Langsam
Vorteile der Datenmodellierung Keine Entitätskolocation Entitätskolocation 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 Vom Kunden 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

Container-pro-Mandant-Modell

Sie können für jeden Mandanten dedizierte Container bereitstellen. Dedizierte Container funktionieren gut, wenn Sie die Daten, die Sie für Ihren Mandanten speichern, in einem einzigen Container kombinieren können. Dieses Modell bietet eine höhere Leistungsisolation als das Partitionsschlüssel-pro-Mandant-Modell. Darüber hinaus bietet es eine höhere Isolation der Datenzugriffssicherheit über Azure RBAC.

Wenn Sie einen Container für jeden Mandanten verwenden, sollten Sie den Durchsatz für andere Mandanten freigeben, indem Sie den Durchsatz auf Datenbankebene bereitstellen. Berücksichtigen Sie die Einschränkungen und Grenzwerte für die Mindestanzahl von RUs für Ihre Datenbank und die maximale Anzahl von Containern in der Datenbank. Überlegen Sie außerdem, ob Ihre Mandanten eine garantierte Leistungsstufe erfordern und ob sie anfällig für das laute Nachbarproblem sind. Bei einer gemeinsamen Nutzung des Durchsatzes auf Datenbankebene sollte Workload oder Speicherung für alle Container relativ einheitlich sein. Andernfalls haben Sie möglicherweise ein lautes Nachbarproblem, wenn Sie über einen oder mehrere große Mandanten verfügen. 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 eignet sich gut für größere Mandanten und für Mandanten, die das laute Nachbarproblem gefährden. Der grundlegende Durchsatz für jeden Mandanten ist jedoch höher. Berücksichtigen Sie daher die Mindestanforderungen und Kostenauswirkungen dieses Modells.

Wenn Ihr Mandantendatenmodell mehrere Entitäten erfordert und alle Entitäten denselben Partitionsschlüssel gemeinsam nutzen können, können Sie sie im selben Container verlagern. Wenn das Mandantendatenmodell jedoch komplexer ist und Entitäten erforderlich sind, die nicht denselben Partitionsschlüssel gemeinsam nutzen können, sollten Sie die Datenbank-pro-Mandant- oder Datenbankkonto-pro-Mandant-Modelle berücksichtigen. Weitere Informationen finden Sie unter Modell- und Partitionsdaten in Azure Cosmos DB.

Die Lebenszyklusverwaltung ist im Allgemeinen einfacher, wenn Sie Container für Mandanten bereitstellen. Sie können Mandanten ganz einfach zwischen gemeinsam genutzten und dedizierten Durchsatzmodellen verschieben. Und wenn Sie einen Mandanten aufheben, können Sie den Container schnell löschen.

Datenbank-pro-Mandant-Modell

Sie können Datenbanken für jeden Mandanten im selben Datenbankkonto bereitstellen. Wie das Modell "Container pro Mandant" bietet dieses Modell eine höhere Leistungsisolation als das Partitionsschlüssel-pro-Mandant-Modell. Darüber hinaus bietet es eine höhere Isolation der Datenzugriffssicherheit über Azure RBAC.

Ähnlich wie das Konto-pro-Mandant-Modell bietet dieser Ansatz die höchste Leistungsisolation, bietet aber die niedrigste Mandantendichte. Verwenden Sie diese Option, wenn jeder Mandant ein komplizierteres Datenmodell erfordert, als im Container-pro-Mandanten-Modell machbar ist. Oder befolgen Sie diesen Ansatz, wenn die Erstellung eines neuen Mandanten schnell oder kostenlos sein muss. Bei einigen Softwareentwicklungsframeworks kann das Datenbank-pro-Mandant-Modell die einzige Leistungsisolation sein, die das Framework unterstützt. Solche Frameworks unterstützen in der Regel keine Isolation auf Entitätsebene (Container) und Entitätskolocation.

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

Partitionierung

Verwenden Sie Partitionen mit Ihren Azure Cosmos DB-Containern, um Container zu erstellen, die mehrere Mandanten freigeben. 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. Wenn Sie über große Container verfügen, verteilt Azure Cosmos DB Ihre Mandanten über mehrere physische Knoten, um einen hohen Maßstab zu erzielen.

Ziehen Sie hierarchische Partitionsschlüssel in Betracht, um die Leistung Ihrer Mehrinstanzenlösung zu verbessern. Verwenden Sie hierarchische Partitionsschlüssel, um einen Partitionsschlüssel zu erstellen, der mehrere Werte enthält. Sie können z. B. einen hierarchischen Partitionsschlüssel verwenden, der den Mandantenbezeichner enthält, z. B. eine GUID mit hoher Kardinalität, um nahezu ungebundene Skalierung zu ermöglichen. Sie können auch einen hierarchischen Partitionsschlüssel angeben, der eine Eigenschaft enthält, die häufig verwendet wird. Dieser Ansatz hilft Ihnen, partitionsübergreifende Abfragen zu vermeiden. Verwenden Sie hierarchische Partitionsschlüssel, um über den logischen Partitionsgrenzwert von 20 GB pro Partitionsschlüsselwert zu skalieren und teure Fanoutabfragen einzuschränken.

Weitere Informationen finden Sie in den folgenden Ressourcen:

Verwalten von RUs

Das Azure Cosmos DB-Preismodell basiert auf der Anzahl der RU/s, die Sie bereitstellen oder nutzen. Azure Cosmos DB bietet mehrere Optionen zum Bereitstellen des Durchsatzes. In einer mehrinstanzenübergreifenden Umgebung wirkt sich Ihre Auswahl auf die Leistung und den Preis Ihrer Azure Cosmos DB-Ressourcen aus.

Für Mandanten, die eine garantierte Leistung und Sicherheitsisolation erfordern, empfehlen wir, Mandanten nach Datenbankkonto zu isolieren und dem Mandanten RUs zuzuweisen. Für Mandanten mit weniger strengen Anforderungen empfehlen wir, Mandanten nach Partitionsschlüssel zu isolieren. Verwenden Sie dieses Modell, um RUs zwischen Ihren Mandanten zu teilen und die Kosten pro Mandant zu optimieren.

Ein alternatives Mandantenmodell für Azure Cosmos DB umfasst die Bereitstellung separater Container für jeden Mandanten innerhalb einer freigegebenen Datenbank. Verwenden Sie Azure Cosmos DB, um RUs für eine Datenbank bereitzustellen, damit alle Container die RUs gemeinsam nutzen. 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 laute Nachbarproblem , da der Container eines einzelnen Mandanten möglicherweise eine unverhältnismäßige Menge der freigegebenen bereitgestellten RUs verbrauchen kann. Um dieses Problem zu beheben, identifizieren Sie zuerst die lauten Mandanten. 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 auch eine serverlose Ebene, die für Workloads geeignet ist, die zeitweise oder unvorhersehbaren Datenverkehr aufweisen. Alternativ können Sie die automatische Skalierung verwenden, um Richtlinien zu konfigurieren, die die Skalierung des bereitgestellten Durchsatzes angeben. Sie können auch die Kapazität von Azure Cosmos DB nutzen, um die Nutzung Ihrer bereitgestellten Durchsatzkapazität zu maximieren, was andernfalls durch Geschwindigkeitsgrenzwerte eingeschränkt ist. In einer multitenanten Lösung können Sie all diese Ansätze kombinieren, um verschiedene Mandantentypen zu unterstützen.

Hinweis

Wenn Sie Ihre Azure Cosmos DB-Konfiguration planen, sollten Sie die Dienstkontingente und -grenzwerte berücksichtigen.

Um die Kosten zu überwachen und zu verwalten, die jedem Mandanten zugeordnet sind, denken Sie daran, dass jeder Vorgang, der die Azure Cosmos DB-API verwendet, die genutzten RUs enthält. Sie können diese Informationen verwenden, um die tatsächlichen RUs zu aggregieren und zu vergleichen, die jeder Mandant nutzt. Anschließend können Sie Mandanten identifizieren, die unterschiedliche Leistungsmerkmale aufweisen.

Weitere Informationen finden Sie in den folgenden Ressourcen:

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. Sie wenden dieses Feature auf der Ebene eines Azure Cosmos DB-Kontos an. Wenn Mandanten also eigene Verschlüsselungsschlüssel benötigen, müssen Sie dedizierte Azure Cosmos DB-Konten verwenden, um die Mandanten bereitzustellen.

Weitere Informationen finden Sie unter Konfigurieren von kundenseitig verwalteten Schlüsseln für Ihr Azure Cosmos DB-Konto mit Azure Key Vault.

Beitragende

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

Hauptautoren:

Andere Mitwirkende:

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

Nächste Schritte

Weitere Informationen zu Mehrinstanzenfähigkeit und Azure Cosmos DB:

Sehen Sie sich einige unserer anderen Architekturszenarien von Azure Cosmos DB an: