Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Mehrinstanzenfähige SaaS-Partitionierungsmodelle für PostgreSQL
Die beste Methode zur Realisierung von Multi-Tenancy hängt von den Anforderungen für Ihre SaaS-Anwendung ab. In den folgenden Abschnitten werden Partitionierungsmodelle für die erfolgreiche Implementierung von Mehrmandantenfähigkeit in PostgreSQL demonstriert.
**Anmerkung**
Die in diesem Abschnitt erörterten Modelle gelten sowohl für Amazon RDS for PostgreSQL als auch für Aurora PostgreSQL-Compatible. Verweise auf *PostgreSQL* in diesem Abschnitt gelten für beide Dienste.
Es gibt drei High-Level-Modelle, die Sie in PostgreSQL für die SaaS-Partitionierung verwenden können: Silo, Bridge und Pool. Die folgende Abbildung fasst die Kompromisse zwischen den Silo- und Poolmodellen zusammen. Das Brückenmodell ist eine Mischung aus den Modellen Silo und Pool.
****
| **Partitionierungsmodell** | **Vorteile** | **Nachteile** |
| --- | --- | --- |
| Silo | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) |
| Pool | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) |
| Brücke | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/partitioning-models.html) |
In den folgenden Abschnitten werden die einzelnen Modelle ausführlicher behandelt.
**Topics**
+ [
# PostgreSQL-Silomodell
](silo.md)
+ [
# PostgreSQL-Poolmodell
](pool.md)
+ [
# PostgreSQL-Brückenmodell
](bridge.md)
+ [
# Entscheidungsmatrix
](matrix.md)
# PostgreSQL-Silomodell
Das Silomodell wird implementiert, indem für jeden Mandanten in einer Anwendung eine PostgreSQL-Instanz bereitgestellt wird. *Das Silomodell zeichnet sich durch die Leistung der Mandanten und die Sicherheitsisolierung aus und beseitigt das Phänomen der störenden Nachbarn vollständig.* Das Noisy-Neighbor-Phänomen tritt auf, wenn die Nutzung eines Systems durch einen Mandanten die Leistung eines anderen Mandanten beeinträchtigt. Mit dem Silomodell können Sie die Leistung speziell auf jeden Mandanten zuschneiden und Ausfälle möglicherweise auf das Silo eines bestimmten Mandanten beschränken. Was die Einführung eines Silo-Modells im Allgemeinen vorantreibt, sind jedoch strenge Sicherheits- und behördliche Auflagen. Diese Einschränkungen können durch SaaS-Kunden motiviert werden. Beispielsweise könnten SaaS-Kunden aufgrund interner Einschränkungen verlangen, dass ihre Daten isoliert werden, und SaaS-Anbieter könnten einen solchen Service gegen eine zusätzliche Gebühr anbieten.
![\[SaaS PostgreSQL silo model\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-silo.png)
Obwohl das Silomodell in bestimmten Fällen notwendig sein könnte, hat es viele Nachteile. Es ist oft schwierig, das Silomodell kostengünstig zu verwenden, da die Verwaltung des Ressourcenverbrauchs über mehrere PostgreSQL-Instanzen hinweg kompliziert sein kann. Darüber hinaus macht es die verteilte Natur der Datenbank-Workloads in diesem Modell schwieriger, einen zentralen Überblick über die Tenant-Aktivitäten zu behalten. Die Verwaltung so vieler unabhängig voneinander betriebener Workloads erhöht den Betriebs- und Verwaltungsaufwand. Das Silomodell macht das Onboarding von Mandanten auch komplizierter und zeitaufwändiger, da Sie mandantenspezifische Ressourcen bereitstellen müssen. Darüber hinaus kann es schwieriger sein, das gesamte SaaS-System zu skalieren, da die ständig steigende Anzahl mandantenspezifischer PostgreSQL-Instanzen mehr Betriebszeit für die Verwaltung in Anspruch nehmen wird. Eine letzte Überlegung ist, dass eine Anwendung oder eine Datenzugriffsebene eine Zuordnung von Mandanten zu ihren zugehörigen PostgreSQL-Instanzen beibehalten muss, was die Implementierung dieses Modells noch komplexer macht.
# PostgreSQL-Poolmodell
Das Poolmodell wird implementiert, indem eine einzelne PostgreSQL-Instance (Amazon RDS oder Aurora) bereitgestellt und [Sicherheit auf Zeilenebene (RLS)](https://aws.amazon.com/blogs/database/multi-tenant-data-isolation-with-postgresql-row-level-security/) verwendet wird, um die Isolierung der Mandantendaten aufrechtzuerhalten. RLS-Richtlinien schränken ein, welche Zeilen in einer Tabelle von `SELECT` Abfragen zurückgegeben werden oder welche Zeilen von, und Befehlen betroffen sind. `INSERT` `UPDATE` `DELETE` Das Poolmodell zentralisiert alle Mandantendaten in einem einzigen PostgreSQL-Schema, sodass es deutlich kostengünstiger ist und weniger Betriebskosten für die Wartung erfordert. Die Überwachung dieser Lösung ist aufgrund ihrer Zentralisierung ebenfalls erheblich einfacher. Die Überwachung der mandantenspezifischen Auswirkungen im Poolmodell erfordert jedoch in der Regel zusätzliche Instrumente in der Anwendung. Dies liegt daran, dass PostgreSQL standardmäßig nicht weiß, welcher Mandant Ressourcen verbraucht. Das Onboarding von Mandanten wird vereinfacht, da keine neue Infrastruktur erforderlich ist. Diese Flexibilität macht es einfacher, schnelle und automatisierte Workflows für das Onboarding von Mandanten durchzuführen.
![\[SaaS PostgreSQL pool model\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-pool.png)
Obwohl das Poolmodell im Allgemeinen kostengünstiger und einfacher zu verwalten ist, hat es einige Nachteile. Das Phänomen der lauten Nachbarn kann bei einem Poolmodell nicht vollständig ausgeschlossen werden. Dies kann jedoch verringert werden, indem sichergestellt wird, dass die entsprechenden Ressourcen auf der PostgreSQL-Instance verfügbar sind, und indem Strategien zur Reduzierung der Belastung in PostgreSQL verwendet werden, z. B. das Auslagern von Abfragen an Read Replicas oder Amazon. ElastiCache Eine effektive Überwachung spielt auch eine Rolle bei der Reaktion auf Bedenken hinsichtlich der Leistungsisolierung von Mandanten, da die Anwendungsinstrumentierung mandantenspezifische Aktivitäten protokollieren und überwachen kann. Schließlich halten einige SaaS-Kunden die von RLS bereitgestellte logische Trennung möglicherweise nicht für ausreichend und verlangen möglicherweise zusätzliche Isolationsmaßnahmen.
# PostgreSQL-Brückenmodell
Das PostgreSQL-Bridge-Modell ist eine Kombination aus gepoolten und isolierten Ansätzen. Wie beim Poolmodell stellen Sie für jeden Mandanten eine einzelne PostgreSQL-Instanz bereit. Um die Isolierung der Mandantendaten aufrechtzuerhalten, verwenden Sie logische PostgreSQL-Konstrukte. In der folgenden Abbildung werden PostgreSQL-Datenbanken verwendet, um Daten logisch zu trennen.
**Anmerkung**
Eine PostgreSQL-Datenbank bezieht sich nicht auf eine separate Amazon RDS for PostgreSQL- oder Aurora PostgreSQL-kompatible DB-Instance. Stattdessen bezieht es sich auf ein logisches Konstrukt des PostgreSQL-Datenbankmanagementsystems zur Trennung von Daten.
![\[SaaS PostgreSQL bridge model with separate databases\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-bridge-dbs.png)
Sie können das Bridge-Modell auch implementieren, indem Sie eine einzelne PostgreSQL-Datenbank mit mandantenspezifischen Schemas in jeder Datenbank verwenden, wie in der folgenden Abbildung dargestellt.
![\[SaaS PostgreSQL bridge model with separate schemas\]](http://docs.aws.amazon.com/de_de/prescriptive-guidance/latest/saas-multitenant-managed-postgresql/images/saas-postgresql-bridge-schemas.png)
Beim Bridge-Modell bestehen dieselben Probleme bei der Leistungsisolierung von Nachbarn und Mandanten wie beim Pool-Modell. Es verursacht auch zusätzlichen Betriebs- und Bereitstellungsaufwand, da entweder separate Datenbanken oder Schemas pro Mandant bereitgestellt werden müssen. Es erfordert eine effektive Überwachung, um schnell auf Leistungsprobleme der Mandanten reagieren zu können. Außerdem ist eine Anwendungsinstrumentierung erforderlich, um die mandantenspezifische Nutzung zu überwachen. Insgesamt kann das Bridge-Modell als Alternative zu RLS angesehen werden, das den Aufwand für das Onboarding von Mandanten geringfügig erhöht, da neue PostgreSQL-Datenbanken oder -Schemas erforderlich sind. Wie beim Silomodell muss eine Anwendung oder eine Datenzugriffsebene eine Zuordnung der Mandanten zu ihren zugehörigen PostgreSQL-Datenbanken oder -Schemas verwalten.
# Entscheidungsmatrix
Um zu entscheiden, welches Multi-Tenant-SaaS-Partitionierungsmodell Sie mit PostgreSQL verwenden sollten, ziehen Sie die folgende Entscheidungsmatrix zu Rate. In der Matrix werden diese vier Partitionierungsoptionen analysiert:
+ Silo — Eine separate PostgreSQL-Instanz oder ein Cluster für jeden Mandanten.
+ Bridge mit separaten Datenbanken — Eine separate Datenbank für jeden Mandanten in einer einzelnen PostgreSQL-Instanz oder einem Cluster.
+ Bridge mit separaten Schemas — Ein separates Schema für jeden Mandanten in einer einzelnen PostgreSQL-Datenbank, in einer einzelnen PostgreSQL-Instanz oder einem Cluster.
+ Pool — Gemeinsam genutzte Tabellen für Mandanten in einer einzigen Instanz und einem Schema.
****
| **** | **Silo** | **Brücke mit separaten Datenbanken** | **Brücke mit separaten Schemas** | **Pool** |
| --- | --- | --- | --- | --- |
| Anwendungsfall | Die Isolierung von Daten mit vollständiger Kontrolle über die Ressourcennutzung ist eine wichtige Anforderung, wenn Sie über sehr große und sehr leistungsabhängige Mandanten verfügen. | Die Isolierung von Daten ist eine zentrale Anforderung, und es ist nur ein begrenzter oder kein Querverweis auf die Daten der Mandanten erforderlich. | Moderate Anzahl von Mietern mit einer moderaten Datenmenge. Dies ist das bevorzugte Modell, wenn Sie die Daten von Mietern miteinander vergleichen müssen. | Große Anzahl von Mandanten mit weniger Daten pro Mandant. |
| Agilität beim Onboarding neuer Mandanten | Sehr langsam. (Für jeden Mandanten ist eine neue Instanz oder ein neuer Cluster erforderlich.) | Mäßig langsam. (Erfordert die Erstellung einer neuen Datenbank für jeden Mandanten zum Speichern von Schemaobjekten.) | Mäßig langsam. (Erfordert die Erstellung eines neuen Schemas für jeden Mandanten zum Speichern von Objekten.) | Schnellste Option. (Minimale Einrichtung ist erforderlich.) |
| Aufwand und Effizienz bei der Konfiguration des Datenbankverbindungspools | Erheblicher Aufwand erforderlich. (Ein Verbindungspool pro Mandant.) Weniger effizient. (Keine gemeinsame Nutzung von Datenbankverbindungen zwischen Mandanten.) | Erheblicher Aufwand erforderlich. (Eine Verbindungspool-Konfiguration pro Mandant, sofern Sie nicht [Amazon RDS Proxy](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/rds-proxy.html) verwenden.) Weniger effizient. (Keine gemeinsame Nutzung der Datenbankverbindung zwischen Mandanten und Gesamtzahl der Verbindungen. Die Nutzung für alle Mandanten ist je nach DB-Instance-Klasse begrenzt.) | Weniger Aufwand erforderlich. (Eine Verbindungspool-Konfiguration für alle Mandanten.) Mäßig effizient. (Wiederverwendung von Verbindungen über den `SET SCHEMA` Befehl `SET ROLE` oder nur im Sitzungspoolmodus. `SET`Befehle führen auch zu Sitzungs-Pinning, wenn Amazon RDS Proxy verwendet wird, aber die Client-Verbindungspools können entfernt werden und aus Effizienzgründen können direkte Verbindungen für jede Anfrage hergestellt werden.) | Geringster Aufwand erforderlich. Am effizientesten. (Ein Verbindungspool für alle Mandanten und effiziente Wiederverwendung von Verbindungen für alle Mandanten. Die Grenzwerte für Datenbankverbindungen basieren auf der DB-Instance-Klasse.) |
| Datenbankwartung ([Vakuummanagement](https://www.postgresql.org/docs/current/routine-vacuuming.html)) und Ressourcennutzung | Einfachere Verwaltung. | Mittlere Komplexität. (Kann zu einem hohen Ressourcenverbrauch führen, da danach für jede Datenbank ein Vacuum Worker gestartet werden mussvacuum\$1naptime, was zu einer hohen CPU-Auslastung des Autovacuum-Launchers führt. Möglicherweise ist auch zusätzlicher Aufwand mit dem Löschen der PostgreSQL-Systemkatalogtabellen für jede Datenbank verbunden.) | Große PostgreSQL-Systemkatalogtabellen. (pg\$1catalogGesamtgröße in Dutzenden GBs, abhängig von der Anzahl der Mandanten und Beziehungen. Wahrscheinlich müssen die Parameter für das Staubsaugen geändert werden, um zu wenig Platz auf dem Tisch zu haben.) | Die Tabellen können je nach Anzahl der Mandanten und den Daten pro Mandant umfangreich sein. (Wahrscheinlich sind Änderungen an den mit dem Staubsaugen verbundenen Parametern erforderlich, um ein Übermaß an Tabellen zu verhindern.) |
| Aufwand für die Verwaltung von Erweiterungen | Erheblicher Aufwand (für jede Datenbank in separaten Instanzen). | Erheblicher Aufwand (auf jeder Datenbankebene). | Minimaler Aufwand (einmalig in der gemeinsamen Datenbank). | Minimaler Aufwand (einmal in der gemeinsamen Datenbank). |
| Implementierungsaufwand ändern | Erheblicher Aufwand. (Connect zu jeder einzelnen Instanz her und führen Sie die Änderungen durch.) | Erheblicher Aufwand. (Connect zu jeder Datenbank und jedem Schema her und führen Sie die Änderungen durch.) | Mäßiger Aufwand. (Connect zu einer gemeinsamen Datenbank her und führen Sie die Änderungen für jedes Schema durch.) | Minimaler Aufwand. (Connect zu einer gemeinsamen Datenbank her und führen Sie die Änderungen durch.) |
| Implementierung von Änderungen — Umfang der Auswirkungen | Minimal. (Einzelner Mieter betroffen.) | Minimal. (Einzelner Mieter betroffen.) | Minimal. (Einzelner Mieter betroffen.) | Sehr groß. (Alle Mieter betroffen.) |
| Leistungsmanagement und Aufwand abfragen | Überschaubare Abfrageleistung. | Überschaubare Abfrageleistung. | Überschaubare Abfrageleistung. | Wahrscheinlich ist ein erheblicher Aufwand erforderlich, um die Abfrageleistung aufrechtzuerhalten. (Im Laufe der Zeit können Abfragen aufgrund der größeren Tabellen langsamer ausgeführt werden. Sie können Tabellenpartitionierung und Datenbank-Sharding verwenden, um die Leistung aufrechtzuerhalten.) |
| Auswirkungen auf mandantenübergreifende Ressourcen | Keine Auswirkungen. (Keine gemeinsame Nutzung von Ressourcen unter den Mietern.) | Mäßige Wirkung. (Mandanten teilen sich gemeinsame Ressourcen wie Instanz-CPU und Arbeitsspeicher.) | Mäßige Auswirkung. (Mandanten teilen sich gemeinsame Ressourcen wie Instanz-CPU und Arbeitsspeicher.) | Starker Aufprall. (Mandanten beeinflussen sich gegenseitig in Bezug auf Ressourcen, Sperrkonflikte usw.) |
| Optimierung auf Mandantenebene (z. B. Erstellung zusätzlicher Indizes pro Mandant oder Optimierung von DB-Parametern für einen bestimmten Mandanten) | Möglich. | Einigermaßen möglich. (Änderungen auf Schemaebene können für jeden Mandanten vorgenommen werden, aber die Datenbankparameter gelten global für alle Mandanten.) | Einigermaßen möglich. (Änderungen auf Schemaebene können für jeden Mandanten vorgenommen werden, aber die Datenbankparameter gelten global für alle Mandanten.) | Nicht möglich. (Die Tabellen werden von allen Mandanten gemeinsam genutzt.) |
| Neugewichtung des Aufwands für leistungssensible Mieter | Minimal. (Sie müssen das Gleichgewicht nicht neu ausbalancieren. Skalieren Sie Server und I/O Ressourcen, um dieses Szenario zu bewältigen.) | Mäßig. (Verwenden Sie logische Replikation oder pg\$1dump um die Datenbank zu exportieren, aber die Ausfallzeiten können je nach Datengröße lang sein. Sie können die Funktion für transportable Datenbanken in Amazon RDS for PostgreSQL verwenden, um Datenbanken schneller zwischen Instances zu kopieren.) | Moderat, aber wahrscheinlich mit längeren Ausfallzeiten verbunden. (Verwenden Sie logische Replikation oder pg\$1dump um das Schema zu exportieren, aber die Ausfallzeiten können je nach Datengröße lang sein.) | Signifikant, da alle Mandanten dieselben Tabellen verwenden. (Das Sharding der Datenbank erfordert das Kopieren aller Daten in eine andere Instanz und einen zusätzlichen Schritt zum Bereinigen der Mandantendaten.) Wahrscheinlich ist eine Änderung der Anwendungslogik erforderlich. |
| Ausfallzeiten der Datenbank bei größeren Versionsupgrades | Standardausfallzeit. (Hängt von der Größe des PostgreSQL-Systemkatalogs ab.) | Längere Ausfallzeit wahrscheinlich. (Je nach Größe des Systemkatalogs kann die Dauer variieren. PostgreSQL-Systemkatalogtabellen werden auch datenbankübergreifend dupliziert) | Längere Ausfallzeiten wahrscheinlich. (Je nach Größe des PostgreSQL-Systemkatalogs variiert die Zeit.) | Standardausfallzeit. (Hängt von der Größe des PostgreSQL-Systemkatalogs ab.) |
| Verwaltungsaufwand (z. B. für die Analyse von Datenbankprotokollen oder die Überwachung von Backup-Jobs) | Erheblicher Aufwand | Minimaler Aufwand. | Minimaler Aufwand. | Minimaler Aufwand. |
| Verfügbarkeit auf Mieterebene | Höchste. (Jeder Mandant fällt aus und erholt sich unabhängig.) | Höherer Wirkungsbereich. (Bei Hardware- oder Ressourcenproblemen fallen alle Mandanten aus und stellen die Daten gemeinsam wieder her.) | Höherer Wirkungsbereich. (Bei Hardware- oder Ressourcenproblemen fallen alle Mandanten aus und stellen die Daten gemeinsam wieder her.) | Höherer Wirkungsbereich. (Bei Hardware- oder Ressourcenproblemen fallen alle Mandanten aus und stellen die Daten gemeinsam wieder her.) |
| Sicherungs- und Wiederherstellungsbemühungen auf Mandantenebene | Geringster Aufwand. (Jeder Mandant kann unabhängig gesichert und wiederhergestellt werden.) | Mäßiger Aufwand. (Verwenden Sie den logischen Export und Import für jeden Mandanten. Ein gewisses Maß an Codierung und Automatisierung ist erforderlich.) | Mäßiger Aufwand. (Verwenden Sie den logischen Export und Import für jeden Mandanten. Ein gewisses Maß an Codierung und Automatisierung ist erforderlich.) | Erheblicher Aufwand. (Alle Mieter teilen sich die gleichen Tische.) |
| Wiederherstellungsbemühungen auf Mandantenebene point-in-time | Minimaler Aufwand. (Verwenden Sie Point-in-Time-Recovery mithilfe von Snapshots oder verwenden Sie Backtracking in Amazon Aurora.) | Mäßiger Aufwand. (Verwenden Sie die Snapshot-Wiederherstellung, gefolgt von Export/Import. Dies wird jedoch ein langsamer Vorgang sein.) | Mäßiger Aufwand. (Verwenden Sie die Snapshot-Wiederherstellung, gefolgt von Export/Import. Dies wird jedoch ein langsamer Vorgang sein.) | Erheblicher Aufwand und Komplexität. |
| Einheitlicher Schemaname | Derselbe Schemaname für jeden Mandanten. | Derselbe Schemaname für jeden Mandanten. | Anderes Schema für jeden Mandanten. | Gemeinsames Schema. |
| Anpassung pro Mandant (z. B. zusätzliche Tabellenspalten für einen bestimmten Mandanten) | Möglich. | Möglich. | Möglich. | Kompliziert (weil sich alle Mandanten dieselben Tabellen teilen). |
| Effizienz der Katalogverwaltung auf ORM-Ebene (Object-Relational Mapping) (z. B. Ruby) | Effizient (weil die Client-Verbindung mandantenspezifisch ist). | Effizient (weil die Client-Verbindung datenbankspezifisch ist). | Mäßig effizient. (Je nach verwendetem ORM, user/role Sicherheitsmodell und search\$1path Konfiguration speichert der Client manchmal die Metadaten für alle Mandanten im Cache, was zu einer hohen Speicherauslastung der DB-Verbindung führt.) | Effizient (weil sich alle Mandanten dieselben Tabellen teilen). |
| Konsolidierter Berichtsaufwand für Mieter | Erheblicher Aufwand. (Sie müssen Foreign Data Wrapper [FDWs] verwenden, um Daten in allen Mandanten zu konsolidieren oder [ETL] zu extrahieren, zu transformieren und in eine andere Berichtsdatenbank zu laden.) | Erheblicher Aufwand. (Sie müssen es verwenden, FDWs um Daten in allen Mandanten oder ETL in einer anderen Berichtsdatenbank zu konsolidieren.) | Mäßiger Aufwand. (Sie können Daten in allen Schemas mithilfe von Unions aggregieren.) | Minimaler Aufwand. (Alle Mandantendaten befinden sich in denselben Tabellen, sodass die Berichterstattung einfach ist.) |
| Mandantenspezifische, schreibgeschützte Instanz für Berichte (z. B. auf Abonnementbasis) | Geringster Aufwand. (Erstellen Sie eine Read Replica.) | Mäßiger Aufwand. (Sie können die logische Replikation oder den AWS Database Migration Service [AWS DMS] zur Konfiguration verwenden.) | Mäßiger Aufwand. (Sie können die logische Replikation verwenden oder AWS DMS konfigurieren.) | Kompliziert (weil alle Mandanten dieselben Tabellen verwenden). |
| Datenisolierung | Am besten. | Besser. (Sie können Berechtigungen auf Datenbankebene mithilfe von PostgreSQL-Rollen verwalten.) | Besser. (Sie können Berechtigungen auf Schemaebene mithilfe von PostgreSQL-Rollen verwalten.) | Schlimmer noch. (Da alle Mandanten dieselben Tabellen verwenden, müssen Sie Funktionen wie Sicherheit auf Zeilenebene [RLS] zur Mandantenisolierung implementieren.) |
| Mandantenspezifischer Speicherverschlüsselungsschlüssel | Möglich. (Jeder PostgreSQL-Cluster kann seinen eigenen AWS Key Management Service [AWS KMS] Schlüssel für die Speicherverschlüsselung haben.) | Nicht möglich. (Alle Mandanten verwenden denselben KMS-Schlüssel für die Speicherverschlüsselung.) | Nicht möglich. (Alle Mandanten verwenden denselben KMS-Schlüssel für die Speicherverschlüsselung.) | Nicht möglich. (Alle Mandanten verwenden denselben KMS-Schlüssel für die Speicherverschlüsselung.) |
| Verwendung von AWS Identity and Access Management (IAM) für die Datenbankauthentifizierung für jeden Mandanten | Möglich. | Möglich. | Möglich (durch separate PostgreSQL-Benutzer für jedes Schema). | Nicht möglich (da Tabellen von allen Mandanten gemeinsam genutzt werden). |
| Kosten für die Infrastruktur | Am höchsten (weil nichts gemeinsam genutzt wird). | Mäßig. | Mäßig. | Niedrigste. |
| Datenduplizierung und Speichernutzung | Höchstes Aggregat für alle Mandanten. (Die PostgreSQL-Systemkatalogtabellen und die statischen und allgemeinen Daten der Anwendung werden für alle Mandanten dupliziert.) | Höchstes Aggregat für alle Mandanten. (Die PostgreSQL-Systemkatalogtabellen und die statischen und allgemeinen Daten der Anwendung werden für alle Mandanten dupliziert.) | Mäßig. (Die statischen und allgemeinen Daten der Anwendung können sich in einem gemeinsamen Schema befinden, auf das andere Mandanten zugreifen können.) | Minimal. (Keine Vervielfältigung von Daten. Die statischen und allgemeinen Daten der Anwendung können sich im selben Schema befinden.) |
| Mandantenorientierte Überwachung (finden Sie schnell heraus, welcher Mandant Probleme verursacht) | Geringster Aufwand. (Da jeder Mandant separat überwacht wird, ist es einfach, die Aktivitäten eines bestimmten Mandanten zu überprüfen.) | Mäßiger Aufwand. (Da sich alle Mandanten dieselbe physische Ressource teilen, müssen Sie zusätzliche Filter anwenden, um die Aktivität eines bestimmten Mandanten zu überprüfen.) | Mäßiger Aufwand. (Da sich alle Mandanten dieselbe physische Ressource teilen, müssen Sie zusätzliche Filter anwenden, um die Aktivität eines bestimmten Mandanten zu überprüfen.) | Erheblicher Aufwand. (Da alle Mandanten alle Ressourcen, einschließlich Tabellen, gemeinsam nutzen, müssen Sie die Erfassung von Bind-Variablen verwenden, um zu überprüfen, zu welchem Mandanten eine bestimmte SQL-Abfrage gehört.) |
| Zentralisierte Verwaltung und health/activity Überwachung | Erheblicher Aufwand (Einrichtung einer zentralen Überwachung und einer zentralen Kommandozentrale). | Mäßiger Aufwand (da sich alle Mandanten dieselbe Instanz teilen). | Moderater Aufwand (da sich alle Mandanten dieselbe Instanz teilen). | Minimaler Aufwand (da sich alle Mandanten dieselben Ressourcen teilen, einschließlich des Schemas). |
| Wahrscheinlichkeit eines Wraparounds zwischen Objekt-Identifier (OID) und Transaktions-ID (XID) | Minimal. | Hoch. (Aufgrund von OID ist XID ein einziger postgreSQL-Cluster-weiter Zähler, und es kann zu Problemen beim effektiven Vacuumieren zwischen physischen Datenbanken kommen). | Mäßig. (Aufgrund von OID ist XID ein einzelner postgreSQL-Clusterweiter Zähler). | Hoch. (Beispielsweise kann eine einzelne Tabelle je nach Anzahl der Spalten das TOAST-OID-Limit von 4 Milliarden erreichen.) out-of-line |