In diesem Dokument werden verschiedene Möglichkeiten zur Implementierung der Mehrmandantenfähigkeit in Cloud Spanner beschrieben. Außerdem werden Datenverwaltungsmuster und die Verwaltung des Mandantenlebenszyklus erläutert.
Die Mehrmandantenfähigkeit bezeichnet die Option, eine einzelne Instanz oder mehrere Instanzen einer Softwareanwendung für mehrere Mandanten oder Kunden bereitzustellen. Dieses Softwaremuster kann von einem einzelnen Mandanten oder Kunden auf Hunderte oder Tausende Mandanten skaliert werden. Dieser Ansatz ist ein fundamentaler Bestandteil von Cloud-Computing-Plattformen, bei denen die zugrunde liegende Infrastruktur von mehreren Organisationen gemeinsam genutzt wird.
Stellen Sie sich eine Mehrmandantenfähigkeit als eine Art Partitionierung vor, die auf gemeinsam genutzten Computing-Ressourcen wie z. B. Datenbanken basiert. Eine weitere Analogie wären Mieter in einem Apartmentgebäude: Es gibt eine gemeinsam genutzte Infrastruktur, aber sie alle haben eigene Räume. Die Mehrmandantenfähigkeit ist Teil der meisten, vielleicht sogar von allen SaaS-Anwendungen (Software as a Service).
Dieses Dokument richtet sich an Datenbankarchitekten, Datenarchitekten und Entwickler, die Mehrmandantenanwendungen in Spanner als relationale Datenbanken implementieren. In diesem Kontext werden verschiedene Ansätze zum Speichern von Mehrmandantendaten beschrieben. Die Begriffe "Mandant", "Kunde" und "Organisation" werden im gesamten Artikel gleichbedeutend verwendet, um die Entität anzugeben, die auf die Mehrmandantenanwendung zugreift.
In diesem Artikel wird als Beispiel ein HR-Anbieter (Human Resources) verwendet, der seine mehrmandantenfähige Anwendung in Google Cloud implementiert. In diesem Beispiel müssen mehrere Kunden des HR-SaaS-Anbieters auf die mehrmandantenfähige Anwendung zugreifen. Diese Kunden werden als Mandanten bezeichnet.
Spanner ist eine vollständig verwaltete, für Unternehmen geeignete, verteilte, konsistente und konsistente Datenbank von Google Cloud, die die Vorteile des relationalen Datenbankmodells mit nicht-relationaler horizontaler Skalierbarkeit vereint. Spanner nutzt relationale Semantiken – mit Schemas, erzwungenen Datentypen, strikter Konsistenz, ACID-Transaktionen mit mehreren Anweisungen und einer SQL-Abfragesprache, die ANSI 2011 SQL implementiert.
Spanner vermeidet Ausfallzeiten bei geplanten Wartungsarbeiten oder Regionalfehlern und bietet ein Verfügbarkeits-SLA von 99,999%. Spanner unterstützt moderne Mehrmandantenanwendungen durch hohe Verfügbarkeit und Skalierbarkeit. In diesem Artikel werden die verschiedenen Architekturansätze erläutert, um die Mehrmandantenfähigkeit mit Spanner zu implementieren.
Überlegungen zu Kriterien zum Mandanten-Datenabgleich
In einer Mehrmandantenanwendung sind die Daten jedes Mandanten in einem von mehreren Architekturansätzen in der zugrundeliegenden Spanner-Datenbank isoliert. In folgender Liste werden die verschiedenen Architekturansätze dargestellt, mit denen die Daten eines Mandanten Spanner zugeordnet werden:
- Instanz: Mandanten befinden sich ausschließlich in einer Spanner-Instanz, mit genau einer Datenbank pro Mandant.
- Datenbank: Mandanten befinden sich in einer Datenbank in einer einzelnen Spanner-Instanz mit mehreren Datenbanken.
- Schema: Mandanten befinden sich in exklusiven Tabellen innerhalb einer Datenbank; es können mehrere Mandanten in derselben Datenbank sein.
- Tabelle: Mandantendaten sind Zeilen in Datenbanktabellen. Diese Tabellen werden für andere Mandanten freigegeben.
Die vorherigen Kriterien werden als Datenverwaltungsmuster bezeichnet und im Abschnitt Datenverwaltungsmuster für Mehrmandantenfähigkeit ausführlich erläutert. Diese Diskussion basiert auf folgenden Kriterien:
- Isolation: Der Grad der Datenisolation über mehrere Mandanten hinweg ist ein wichtiger Aspekt der Mehrmandantenfähigkeit. Die Isolation wird durch Entscheidungen bedingt, die für die Kriterien in anderen Kategorien getroffen wurden. Beispielsweise können bestimmte Vorgaben- und Compliance-Anforderungen ein höheres Maß an Isolation erforderlich machen.
- Agilität: Die Einrichtung und Deaktivierung von Aktivitäten für einen Mandanten in Bezug auf das Erstellen von Instanzen, Datenbanken und Tabellen.
- Vorgänge: Die Verfügbarkeit oder Komplexität der Implementierung von typischen, mandantenspezifischen Datenbankvorgängen und Administrationsaktivitäten, darunter regelmäßige Wartungs-, Logging-, Sicherungs- oder Notfallwiederherstellungsvorgänge.
- Skalieren: Die Fähigkeit, nahtlos zu skalieren, um zukünftiges Wachstum zu ermöglichen. Die Beschreibung jedes Musters enthält die Anzahl der Mandanten, die das Muster unterstützen kann.
- Leistung: Die Möglichkeit, jedem Mandanten exklusive Ressourcen zuzuweisen, das Noisy Neighbour-Phänomen anzusprechen und allen Mandanten eine vorhersehbare Lese- und Schreibleistung zu ermöglichen.
- Verordnungen und Compliance: Fähigkeit, die Bedürfnisse streng regulierter Branchen und Länder zu unterstützen, die eine vollständige Isolation von Ressourcen und Wartungsvorgängen erfordern. Beispielsweise ist es in Frankreich erforderlich, dass personenbezogene Daten ausschließlich in Frankreich gespeichert werden.
Die einzelnen Datenverwaltungsmuster, die diesen Kriterien genügen, werden im nächsten Abschnitt detailliert. Verwenden Sie dieselben Kriterien, wenn Sie ein Datenverwaltungsmuster für eine bestimmte Mandantengruppe auswählen.
Mehrmandantenfähigkeit-Datenverwaltungsmuster
In folgenden Abschnitten werden die vier wichtigsten Datenverwaltungsmuster beschrieben: "Instanz", "Datenbank", "Schema" und "Tabelle".
Instanz
Um für eine vollständige Isolation zu sorgen, speichert das Datenverwaltungsmuster der Instanz die Daten jedes Mandanten in einer eigenen Spanner-Instanz und -Datenbank. Eine Spanner-Instanz kann eine oder mehrere Datenbanken haben. In diesem Muster wird nur eine einzelne Datenbank erstellt. Für die zuvor erwähnte HR-Anwendung wird eine separate Spanner-Instanz mit jeweils einer Datenbank pro Kundenorganisation erstellt.
Wie im folgenden Diagramm dargestellt, hat das Datenverwaltungsmuster jeweils einen Mandanten pro Instanz.
Die Verwendung separater Instanzen für jeden Mandanten ermöglicht die Verwendung separater Google Cloud-Projekte, um für die einzelnen Mandanten separate Vertrauensgrenzen zu erzielen. Ein weiterer Vorteil besteht darin, dass jede Instanzkonfiguration basierend auf dem Standort jedes Mandanten ausgewählt werden kann (entweder regional oder multiregional), wodurch die Flexibilität und Leistung des Standorte optimiert werden.
Die Architektur kann problemlos auf eine beliebige Anzahl an Mandanten skaliert werden. SaaS-Anbieter können eine beliebige Anzahl an Instanzen in den gewünschten Regionen erstellen, ohne echte Beschränkungen.
Die folgende Tabelle zeigt, wie das Datenverwaltungsmuster "Instanz" verschiedene Kriterien erfüllt.
| Kriterien | Instanz – Ein Mandanten pro Instanz-Datenverwaltungsmuster |
|---|---|
| Isolation |
|
| Agilität |
|
| Vorgänge |
|
| Skalieren |
|
| Leistung |
|
| Vorschriften und Compliance-Anforderungen |
|
Die wichtigsten Punkte sind:
- Vorteil: Höchste Isolationsebene
- Nachteil: Höchster operativer Aufwand
Das Datenverwaltungsmuster "Instanz" eignet sich am besten für folgende Szenarien:
- Verschiedene Mandanten sind über eine Vielzahl an Regionen verteilt und erfordern eine lokalisierte Lösung.
- Rechtliche und Compliance-Anforderungen für einige Mandanten erfordern höhere Sicherheitsebenen und Audit-Logs.
- Die Mandantengröße variiert erheblich, sodass die gemeinsame Nutzung von Ressourcen durch Mandanten mit hohem Volumen und hohem Traffic zu Konflikten und gegenseitigen Beeinträchtigungen führen kann.
Datenbank
Im Datenverwaltungsmuster "Datenbank" befindet sich jeder Mandant in einer Datenbank innerhalb einer einzelnen Spanner-Instanz. In einer einzelnen Instanz können sich mehrere Datenbanken befinden. Wenn eine Instanz für die Anzahl der Mandanten nicht ausreicht, erstellen Sie mehrere Instanzen. Dieses Muster impliziert, dass eine einzelne Spanner-Instanz von mehreren Mandanten gemeinsam genutzt wird.
Spanner hat ein festes Limit von 100 Datenbanken pro Instanz. Dieses Limit bedeutet, dass der SaaS-Anbieter mehrere Spanner-Instanzen erstellen und verwenden muss, falls er auf mehr als 100 Kunden skalieren muss.
Für die Personalwesen-Anwendung erstellt und verwaltet der SaaS-Anbieter jeden Mandanten mit einer separaten Datenbank in einer Spanner-Instanz.
Wie im folgenden Diagramm dargestellt, hat das Datenverwaltungsmuster jeweils einen Mandanten pro Datenbank.
Mit dem Datenverwaltungsmuster "Datenbank" wird die logische Isolation auf Datenbankebene für die Daten verschiedener Mandanten erreicht. Da es sich jedoch um eine einzelne Spanner-Instanz handelt, nutzen alle Mandantendatenbanken die gleiche regionale Konfiguration und die zugrunde liegende Compute- und Speichereinrichtung.
Die folgende Tabelle zeigt die Verbindung zwischen dem Datenverwaltungsmuster "Datenbank" und verschiedenen Kriterien.
| Kriterien | Datenbank – Ein Mandant pro Datenbank-Datenverwaltungsmuster |
|---|---|
| Isolation |
|
| Agilität |
|
| Vorgänge |
|
| Skalieren |
|
| Leistung |
|
| Vorschriften und Compliance-Anforderungen |
|
Die wichtigsten Punkte sind:
- Vorteil: Höhere Isolationsebene
- Nachteil: Begrenzte Anzahl an Mandanten pro Instanz; keine Standortflexibilität
Das Datenverwaltungsmuster "Datenbank" eignet sich für folgende Szenarien:
- Mehrere Kunden befinden sich im selben Datenbereich (z. B. Frankreich, Vereinigtes Königreich) und/oder unterstehen derselben Aufsichtsbehörde.
- Mandanten erfordern eine systembasierte Datentrennung und Sicherung/Wiederherstellung, die Freigabe von Infrastrukturressourcen ist aber akzeptabel.
Schema
Im Datenverwaltungsmuster "Schema" wird eine einzelne Datenbank, die ein einzelnes Schema implementiert, für mehrere Mandanten verwendet. Für die Daten jedes Mandanten wird eine separate Tabellengruppe verwendet. Um diese Tabellen zu unterscheiden, sollten Sie tenant ID als Präfix oder Suffix in die Tabellennamen aufnehmen.
Dieses Datenverwaltungsmuster (die Nutzung einer eigenen Tabellengruppe pro Mandant) bietet im Vergleich zu den vorherigen Optionen (Datenverwaltungsmuster "Instanz" und "Datenbank") eine viel höhere Isolation. Das Muster erleichtert auch das Onboarding, was das Erstellen neuer Tabellen, der zugehörigen referenziellen Integrität und von Indexes umfasst.
Ein wichtiger Nachteil besteht darin, dass Zugriffsberechtigungen für Spanner über Identity and Access Management (IAM) nur auf Instanz- oder Datenbankebene bereitgestellt werden. Zugriffsberechtigungen können nicht auf Tabellenebene erteilt werden. Pro Datenbank gilt ein Limit von 5.000 Tabellen. Für viele Kunden schränkt dieses Limit die Nutzung der Anwendung ein.
Außerdem kann die Verwendung von separaten Tabellen pro Kunde dazu führen, dass ein großer Rückstand an Schemaaktualisierungsvorgängen entsteht. Ein solcher Rückstand kann sehr viel Zeit in Anspruch nehmen.
Für die HR-Anwendung kann der SaaS-Anbieter eine Reihe an Tabellen für jeden Kunden erstellen und dabei das Präfix tenant ID in den Tabellennamen nutzen, z. B. customer1_employee, customer1_payroll, customer1_department.
Wie im folgenden Diagramm dargestellt, enthält das Datenverwaltungsmuster "Schema" einen Satz Tabellen pro Mandant.
In folgender Tabelle sehen Sie, wie sich das Datenverwaltungsmuster "Schema" auf verschiedene Kriterien auswirkt.
| Kriterien | Schema – Ein Tabellensatz pro Mandanten-Datenverwaltungsmuster |
|---|---|
| Isolation |
|
| Agilität |
|
| Vorgänge |
|
| Skalieren |
|
| Leistung |
|
| Vorschriften und Compliance-Anforderungen |
|
Die wichtigsten Punkte sind:
- Vorteil: Onboarding ist einfach
- Nachteil: Höherer operativer Aufwand; keine Sicherheitskontrollen auf Tabellenebene
Das Datenverwaltungsmuster "Schema" eignet sich für folgende Szenarien:
- Interne Anwendungen für verschiedene Abteilungen, bei denen eine strikte Datensicherheits-Isolierung im Vergleich zur Nutzerfreundlichkeit weniger wichtig ist.
- Mehrmandantenanwendungen, bei denen die Daten keine strenge Trennung aufgrund von rechtlichen oder behördlichen Anforderungen erfordern.
Es ist zwar möglich, mehrere Tabellengruppen in einer Datenbank zu erstellen, die jeweils einen Mandanten darstellen. Dies ist jedoch aus der Datenbankperspektive das am wenigsten geeignete Muster. Hauptgrund dafür ist, dass für Tabellen folgende Namenskonventionen eingehalten werden müssen. Die Anwendung und alle Datenbanktools (z. B. IDE- und Schemamigrations-Tools) müssen die Namenskonvention verstehen. Sollte die Anzahl der Tabellen pro Mandanten recht groß werden, so bietet das Datenverwaltungsmuster "Schema" leider keine signifikante Skalierung.
Ein besserer Ansatz besteht darin, nur eine Datenbank pro Mandant zu nutzen und die Anzahl der Instanzen zu erhöhen, oder zum Datenverwaltungsmuster "Tabelle" zu wechseln.
Tabelle
Das endgültige Datenverwaltungsmuster stellt mehrere Mandanten mit einem gemeinsamen Satz von Tabellen bereit. Jede Tabelle enthält Daten für mehrere Mandanten. Dieses Datenverwaltungsmuster stellt ein extremes Maß an Mehrinstanzenfähigkeit dar, wobei alles – von der Infrastruktur über das Schema bis zum Datenmodell – von mehreren Mandanten gemeinsam genutzt wird. Innerhalb einer Tabelle werden Zeilen anhand von Primärschlüsseln partitioniert, wobei tenant ID das erste Element des Schlüssels ist. Aus Sicht der Skalierung unterstützt Spanner dieses Muster am besten, da es Tabellen ohne Einschränkung skalieren kann.
Für die Personalwesen-Anwendung kann der Primärschlüssel der Lohnabrechnungstabelle eine Kombination aus customerID und payrollID sein.
Wie im folgenden Diagramm dargestellt, enthält das Datenverwaltungsmuster "Tabelle" eine Tabelle für mehrere Mandanten.
Ähnlich wie beim Muster "Schema" kann der Datenzugriff im Tabellenmuster nicht separat für verschiedene Mandanten gesteuert werden. Die Verwendung von weniger Tabellen bedeutet, dass Vorgänge zur Schemaaktualisierung schneller abgeschlossen werden, wenn jeder Mandant seine eigenen Datenbanktabellen hat. Dieser Ansatz vereinfacht das Onboarding, das Offboarding und den Betrieb erheblich.
Die folgende Tabelle zeigt, wie sich das Datenverwaltungsmuster "Tabelle" auf verschiedene Kriterien auswirkt.
| Kriterien | Tabelle – Eine Tabelle für mehrere Mandanten-Datenverwaltungsmuster |
|---|---|
| Isolation |
|
| Agilität |
|
| Vorgänge |
|
| Skalieren |
|
| Leistung |
|
| Vorschriften und Compliance-Anforderungen |
|
Die wichtigsten Punkte sind:
- Vorteil: Hoch skalierbar; hat nur geringen operativen Aufwand
- Nachteil: Hoher Ressourcenverbrauch; es gibt keine pro Mandant zuständigen Sicherheitskontrollen
Dieses Muster eignet sich optimal für folgende Szenarien:
- Interne Anwendungen für verschiedene Abteilungen, bei denen eine strikte Datensicherheits-Isolierung im Vergleich zur Wartungsfreundlichkeit weniger wichtig ist.
- Maximale Ressourcenfreigabe für Mandanten, die kostenlose Anwendungsfunktionen nutzen, wobei die Ressourcenbereitstellung gleichzeitig minimiert wird.
Datenverwaltungsmuster und Verwaltung des Mandantenlebenszyklus
In folgender Tabelle werden die verschiedenen Datenverwaltungsmuster über alle Kriterien hinweg allgemein verglichen.
| Instanz | Datenbank | Schema | Tabelle | |
|---|---|---|---|---|
| Isolation | Fertig | Fertig | Niedrig | Am niedrigsten |
| Agilität | Niedrig | Mäßig besucht | Mäßig besucht | Highest |
| Bedienkomfort | Hoch | Hoch | Niedrig | Niedrig |
| Skalieren | Hoch | Begrenzt | Potenziell sehr eingeschränkt | Hoch |
| Leistung* | Hoch | Mäßig besucht | Mäßig besucht | Potenziell hoch |
| Verordnungen und Compliance | Highest | Hoch | Niedrig | Niedrig |
* Die Leistung hängt stark vom Schemadesign und den Best Practices für Abfragen ab. Die hier angegebenen Werte sind nur eine durchschnittliche Erwartung.
Die besten Datenverwaltungsmuster für eine bestimmte mehrmandantenfähige Anwendung sind diejenigen, die die meisten ihrer Anforderungen je nach Kriterien erfüllen. Ist ein bestimmtes Kriterium nicht erforderlich, können Sie die Zeile, in der es enthalten ist, ignorieren.
Kombinierte Datenverwaltungsmuster
Oft reicht ein einzelnes Datenverwaltungsmuster aus, um die Anforderungen einer Mehrmandantenanwendung zu erfüllen. Ist dies der Fall, kann das Design ein einzelnes Datenverwaltungsmuster nutzen.
Einige Mehrmandantenanwendungen erfordern jedoch mehrere Datenverwaltungsmuster gleichzeitig, z. B. eine Mehrinstanzanwendung, die eine kostenlose Stufe, eine reguläre Stufe und eine Unternehmensstufe unterstützt.
Kostenlose Stufe:
- Muss Kostengünstig sein
- Muss ein Limit als Obergrenze für das Datenvolumen haben
- Unterstützt in der Regel die Funktionseinschränkung
- Das Datenverwaltungsmuster "Tabelle" ist ein guter Kandidaten für die kostenlose Stufe.
- Die Mandantenverwaltung ist einfach
- Keine Erstellung bestimmter oder exklusiver Mandantenressourcen erforderlich
Reguläre Stufe:
- Geeignet für zahlende Kunden, die keine besonderen Anforderungen an die Skalierung oder Isolation haben
- Die Datenverwaltungsmuster "Schema" und "Datenbank" sind gute Kandidaten für die reguläre Stufe.
- Tabellen und Indexe sind ausschließlich für den Mandanten verfügbar
- Die Sicherung im Datenverwaltungsmuster "Datenbank" ist einfach
- Die Sicherung wird für das Datenverwaltungsmuster "Schema" nicht unterstützt
- Die Mandantensicherung muss als Dienstprogramm außerhalb von Spanner implementiert werden
Unternehmensstufe:
- In der Regel eine High-End-Stufe mit vollständiger Autonomie in allen Aspekten
- Mandanten haben dedizierte Ressourcen, die eine dedizierte Skalierung und vollständige Isolation umfassen
- Das Datenverwaltungsmuster "Instanz" ist gut für die Unternehmensstufe geeignet
Eine Best Practice besteht darin, unterschiedliche Datenverwaltungsmuster in verschiedenen Datenbanken zu speichern. Es ist zwar möglich, verschiedene Datenverwaltungsmuster in einer Spanner-Datenbank zu kombinieren, aber die Implementierung der Zugriffslogik und Lebenszyklusvorgänge der Anwendung ist dann schwierig.
Im Abschnitt Anwendungsdesign finden Sie einige Überlegungen zu m Design von Mehrmandantenanwendungen, die bei der Verwendung eines einzelnen Datenverwaltungsmusters oder mehrerer Datenverwaltungsmuster relevant sind.
Mandantenlebenszyklus verwalten
Mandanten haben einen Lebenszyklus. Daher müssen Sie die entsprechenden Verwaltungsvorgänge in Ihrer mehrmandantenfähigen Anwendung implementieren. Berücksichtigen Sie neben den grundlegenden Vorgängen zum Erstellen, Aktualisieren und Löschen von Mandanten die folgenden zusätzlichen datenbezogenen Vorgänge:
Mandantendaten exportieren:
- Beim Löschen von Mandanten hat es sich bewährt, deren Daten zuerst zu exportieren und Ihnen ggf. das Dataset zur Verfügung zu stellen.
- Wenn Sie das Datenverwaltungsmuster "Tabelle" oder "Schema" verwenden, muss die Mehrmandantenanwendung den Export implementieren oder der Datenbankfunktion (Datenbankexport) zuordnen.
Mandantendaten sichern:
- Verwenden Sie die Export- oder Sicherungsfunktionen der Datenbank, wenn Sie eines der Datenverwaltungsmuster "Instanz" oder "Datenbank" verwenden und die Daten der einzelnen Mandanten sichern.
- Wenn Sie das Datenverwaltungsmuster "Schema" oder "Tabelle" verwenden und Daten für einzelne Mandanten sichern, muss die Mehrmandantenanwendung diesen Vorgang implementieren. Die Spanner-Datenbank kann nicht ermitteln, welche Daten zu welchem Mandanten gehören.
Mandantendaten verschieben:
Um einen Mandanten von einem Datenverwaltungsmuster zu einem anderen zu verschieben (oder um einen Mandanten innerhalb desselben Datenverwaltungsmusters zwischen Instanzen oder Datenbanken zu bewegen) müssen die Daten aus dem Tabellen-Datenverwaltungsmuster extrahiert und in das Datenverwaltungsmuster "Datenbank" eingefügt werden.
- Führen Sie einen Export/Import durch, wenn eine Anwendungsausfallzeit möglich ist.
- Führen Sie eine Datenbankmigration ohne Ausfallzeit durch, falls Ausfallzeiten nicht vertretbar sind.
Probleme mit "Noisy Neighbours" sind ein weiterer Grund für das Verschieben von Mandanten.
Anwendungsdesign
Beim Entwerfen einer Mehrmandantenanwendung sollten Sie eine mandantenfähige Geschäftslogik implementieren Das bedeutet, dass die Anwendung Geschäftslogiken immer im Kontext eines bekannten Mandanten ausüben muss.
Aus Datenbankperspektive bedeutet das Anwendungsdesign, dass jede Abfrage nach dem Datenverwaltungsmuster ausgeführt werden muss, in dem der Mandanten ausgeführt wird. In folgenden Abschnitten werden einige der zentralen Konzepte des Designs von Mehrmandantenanwendungen vorgestellt.
Konfiguration von dynamischem Mandanten und Abfragen
Beim dynamischen Zuordnen von Mandantendaten zu Mandantenanwendungsanfragen wird eine Zuordnungskonfiguration verwendet:
- Bei den Datenverwaltungsmustern "Datenbank" und "Instanz" ist ein Verbindungsstring ausreichend, um auf die Daten eines Mandanten zuzugreifen.
- Beim Datenverwaltungsmuster "Schema" müssen die korrekten Tabellennamen festgelegt werden.
- Bei Datenverwaltungsmustern für Tabellen müssen Abfragen anhand der Datenbank ausgeführt werden. Verwenden Sie die entsprechenden Prädikate, um die Daten eines bestimmten Mandanten abzurufen.
Ein Mandant kann in einem der vier Datenverwaltungsmuster residieren. Die folgende Zuordnungsimplementierung spricht eine Verbindungskonfiguration für den allgemeinen Fall einer Mehrmandantenanwendung an, die alle Datenverwaltungsmuster gleichzeitig nutzt. Wenn ein bestimmter Mandanten in einem Muster residiert, verwenden einige Mehrmandantenanwendungen ein Datenverwaltungsmuster für alle Mandanten. Dieser Fall wird implizit durch folgende Zuordnung abgedeckt.
Wenn ein Mandant eine Geschäftslogik ausführt (z. B. ein Mitarbeiter, der sich mit seiner Mandanten-ID anmeldet), muss die Anwendungslogik das Datenverwaltungsmuster des Mandanten, den Speicherort der Daten für eine bestimmte Mandanten-ID und optional die Tabellen-Namenskonvention (für das Schemamuster) bestimmen.
Diese Anwendungslogik erfordert eine Zuordnung des Mandanten-zu-Daten-Verwaltungsmusters. Im folgenden Codebeispiel bezieht sich connection string auf die Datenbank, in der sich die Mandantendaten befinden. Im Beispiel werden die Spanner-Instanz und die Datenbank identifiziert. Für die Datenverwaltungsmuster-Instanz und die Datenbank reicht der folgende Code aus, damit die Anwendung eine Verbindung herstellen und Abfragen ausführen kann:
tenant id -> (data management pattern,
database connection string,
[table_prefix])
Für die Datenverwaltungsmuster "Schema" und "Tabellen" ist ein zusätzliches Design erforderlich.
Datenverwaltungsmuster "Schema"
Für das Datenverwaltungsmuster "Schema" gibt es mehrere Mandanten innerhalb derselben Datenbank. Jeder Mandant hat eine eigene Reihe Tabellen. Die Tabellen unterscheiden sich durch ihre Namen. Die Zugehörigkeit zwischen Tabellen und Mandanten ist klar.
Ein Ansatz besteht darin, dem Tabellennamen die Mandanten-ID voranzustellen, z. B. EMPLOYEE-Tabelle wird genannt T356_EMPLOYEE für den Mandanten mit der ID 356. Die Anwendung muss jeder Tabelle das Präfix Ttenant ID voranstellen, bevor die Abfrage an die Datenbank gesendet wird, die von der Zuordnung zurückgegeben wurde.
Ein anderer Ansatz besteht darin, der von der Abfrage verwendeten Zuordnung einen table_prefix voranzustellen, damit die richtigen Tabellen für einen Mandanten gefunden werden.
Ein gemischter Ansatz ist ebenfalls möglich: Ist das genutzte Datenverwaltungsmuster "Schema" und das Tabellenpräfix leer, so wird die Standardzuordnung verwendet (Tabellennamen werden die Mandanten-IDs vorangestellt).
Datenverwaltungsmuster "Tabelle"
Ein ähnliches Design ist für das Datenverwaltungsmuster "Tabelle" erforderlich. In diesem Muster gibt es ein einzelnes Schema. Mandantendaten werden als Zeilen gespeichert. Für einen ordnungsgemäßen Zugriff auf die Daten hängen Sie an jede Abfrage ein Prädikat an, um den entsprechenden Mandanten auszuwählen.
Ein möglicher Ansatz zum Ermitteln des entsprechenden Mandanten besteht darin, in jeder Tabelle eine Spalte namens TENANT zu verwenden. Der Spaltenwert ist tenant ID. Jede Abfrage muss das Prädikat AND TENANT = tenant ID an eine vorhandene WHERE-Klausel anhängen oder eine WHERE-Klausel mit dem Prädikat AND TENANT = tenant ID hinzufügen.
Die Mandanten-ID muss in der Anwendungslogik verfügbar sein, damit eine Verbindung zur Datenbank hergestellt und die ordnungsgemäßen Abfragen erstellt werden können. Sie kann als Parameter übergeben oder als Thread-Kontext gespeichert werden.
Bei einigen Lebenszyklusvorgängen müssen Sie die Zuordnungskonfiguration für Mandanten-zu-Daten-Verwaltungsmuster ändern. Wenn Sie beispielsweise einen Mandanten zwischen Datenverwaltungsmustern verschieben, müssen Sie das Datenverwaltungsmuster und den Datenbank-Verbindungsstring aktualisieren. Möglicherweise müssen Sie auch das Tabellenpräfix aktualisieren.
Abfrage erstellen und zuweisen
Ein Grundprinzip von Mehrmandantenanwendungen ist es, dass mehrere Mandanten eine einzige Cloudressource gemeinsam nutzen können. Die vorherigen Datenverwaltungsmuster fallen in diese Kategorie, außer in Fällen, in denen ein einzelner Mandant einer einzelnen Spanner-Instanz zugewiesen wird.
Das gemeinsame Nutzen von Ressourcen geht über die gemeinsame Nutzung von Daten hinaus. Monitoring und Logging werden ebenfalls gemeinsam genutzt. Beispielsweise werden im Tabellendatenverwaltungsmuster und Schemadatenverwaltungsmuster alle Abfragen für alle Mandanten im selben Audit-Log aufgezeichnet.
Wird eine Abfrage protokolliert, so muss der Abfragetext überprüft werden, um festzustellen, für welchen Mandanten die Abfrage ausgeführt wurde. Im Datenverwaltungsmuster "Tabelle" müssen Sie das Prädikat parsen. Im Datenverwaltungsmuster "Schema" müssen Sie einen der Tabellennamen parsen.
In den Datenverwaltungsmustern "Datenbank" und "Instanz" enthält der Abfragetext keine Mandanteninformationen. Wenn Sie Mandanteninformationen für diese Muster abrufen möchten, müssen Sie die Zuordnungstabelle der Mandanten-zu-Daten-Verwaltungsmuster abfragen.
Die Analyse von Logs und Abfragen ist einfacher, wenn der Mandant für eine bestimmte Abfrage bestimmt wird, ohne den Abfragetext zu parsen. Eine Möglichkeit, einen Mandanten für eine Abfrage über alle Datenverwaltungsmuster hinweg einheitlich zu identifizieren, besteht darin, dem Abfragetext einen Kommentar mit tenant ID und (optional) einem label hinzuzufügen.
Mit der folgenden Abfrage werden alle Mitarbeiterdaten für den mit TENANT 356 identifizierten Mandanten ausgewählt. Damit die SQL-Syntax nicht geparst und die Mandanten-ID nicht aus dem Prädikat extrahiert werden müssen, wird die Mandanten-ID als Kommentar hinzugefügt. Ein Kommentar kann extrahiert werden, ohne die SQL-Syntax parsen zu müssen.
select * from EMPLOYEE
-- TENANT 356
where TENANT = 'T356';
oder
select * from T356_EMPLOYEE;
-- TENANT 356
Bei diesem Design wird jede Abfrage, die für einen Mandanten ausgeführt wird, diesem Mandanten unabhängig vom Datenverwaltungsmuster zugeordnet. Wenn ein Mandant von einem Datenverwaltungsmuster zu einem anderen verschoben wird, kann sich der Abfragetext ändern, die Attribution bleibt jedoch im Abfragetext gleich.
Das vorherige Codebeispiel ist nur eine der verfügbaren Methoden. Eine weitere Methode besteht darin, ein JSON-Objekt als Kommentar einzufügen, statt Label und Wert:
select * from T356_EMPLOYEE;
-- {"TENANT": 356}
Vorgänge des Mandantenzugriffszyklus
Abhängig von Ihrer Entwurfsphilosophie kann eine Mehrmandantenanwendung die zuvor beschriebenen Datenlebenszyklus-Vorgänge direkt implementieren oder ein separates Tool zur Mandantenverwaltung erstellen.
Unabhängig von der Implementierungsstrategie müssen Lebenszyklusvorgänge möglicherweise ausgeführt werden, ohne dass gleichzeitig die Anwendungslogik ausgeführt wird. Beispiel: Wenn ein Mandanten von einem Datenverwaltungsmuster in ein anderes verschoben wird, kann die Anwendungslogik nicht ausgeführt werden, da sich die Daten nicht in nur einer Datenbank befinden. Befinden sich die Daten nicht in einer einzigen Datenbank, so macht das aus der Anwendungsperspektive zwei weitere Vorgänge erforderlich:
- Mandanten beenden: Unterbindet jeden Zugriff auf die Anwendungslogik und erlaubt gleichzeitig Datenlebenszyklus-Vorgänge.
- Mandanten starten: Die Anwendungslogik kann auf die Daten eines Mandanten zugreifen, während die Lebenszyklusvorgänge, die die Anwendungslogik beeinträchtigen würden, deaktiviert sind.
Dies wird nur selten genutzt. Dennoch kann das Notfall-Herunterfahren eines Mandanten ein wichtiger Lebenszyklus-Vorgang sein. Verwenden Sie diese Einstellung, wenn Sie einen Verstoß vermuten und den Zugriff auf die Daten eines Mandanten umfassend unterbinden möchten – nicht nur auf die Anwendungslogik, sondern auch auf die Lebenszyklus-Vorgänge. Ein Verstoß kann innerhalb oder außerhalb der Datenbank erfolgen.
Außerdem muss ein übereinstimmender Lebenszyklus-Vorgang zum Entfernen des Notfallstatus verfügbar sein. Bei einem solchen Vorgang können sich zwei oder mehr Administratoren gleichzeitig anmelden, um die gegenseitige Kontrolle zu implementieren.
Isolierte Anwendungen
Die verschiedenen Datenverwaltungsmuster unterstützen unterschiedliche Grade der Isolation der Mandantendaten. Zwischen der am meisten isolierten Ebene (Instanz) und der am wenigsten isolierten Ebene (Tabelle) sind unterschiedliche Isolationsgrade möglich.
Im Zusammenhang mit Mehrmandantenanwendungen müssen ähnliche Bereitstellungsentscheidungen getroffen werden: Haben alle Mandanten über dieselbe Anwendungsbereitstellung Zugriff auf ihre Daten (möglicherweise unter Nutzung verschiedener Datenverwaltungsmuster)? Beispielsweise kann ein einzelner Kubernetes-Cluster alle Mandanten unterstützen. Wenn dann ein Mandant auf seine Daten zugreift, führt derselbe Cluster die Geschäftslogik aus.
Alternativ werden, wie im Fall der Datenverwaltungsmuster, verschiedene Mandanten auf verschiedene Anwendungsbereitstellungen weitergeleitet. Größere Mandanten haben möglicherweise Zugriff auf eine Anwendungsbereitstellung, die ausschließlich ihnen vorbehalten ist. Kleinere Mandanten oder Mandanten auf der kostenlosen Stufe teilen sich eine Anwendungsbereitstellung.
Anstatt die in diesem Artikel beschriebenen Datenverwaltungsmuster direkt mit entsprechenden Mustern zur Anwendungsverwaltung zu vergleichen, können Sie das Datenverwaltungsmuster "Datenbank" verwenden, sodass alle Mandanten eine einzige Anwendungsbereitstellung gemeinsam nutzen. Sie können das Datenverwaltungsmuster "Datenbank" nutzen, während alle Mandanten eine einzige Anwendungsbereitstellung verwenden.
Die Mehrinstanzenfähigkeit ist ein wichtiges Verwaltungsmuster für Anwendungs-Designdaten, insbesondere, wenn die Ressourceneffizienz eine wichtige Rolle spielt. Spanner unterstützt mehrere Datenverwaltungsmuster für die Implementierung von Mehrmandantenanwendungen. Aufgrund der extremen Skalierbarkeit und der strengen SLAs von Spanner ist dies eine ideale Datenbank für die Bereitstellung größerer Mehrmandantenanwendungen.
Nächste Schritte
- Referenzarchitekturen, Diagramme und Best Practices zu Google Cloud kennenlernen. Weitere Informationen zu Cloud Architecture Center