Entscheidungsmatrix

Um zu entscheiden, welches Multi-Tenant-SaaS-Partitionierungsmodell Sie mit PostgreSQL verwenden sollten, konsultieren Sie die folgende Entscheidungsmatrix. Die Matrix analysiert diese vier Partitionierungsoptionen:

• Silo — Eine separate PostgreSQL-Instanz oder ein eigener PostgreSQL-Cluster für jeden Mandanten.

• Bridge mit separaten Datenbanken — Eine separate Datenbank für jeden Mandanten in einer einzelnen PostgreSQL-Instanz oder einem einzelnen PostgreSQL-Cluster.

• Bridge mit separaten Schemas — Ein separates Schema für jeden Mandanten in einer einzelnen PostgreSQL-Datenbank, in einer einzelnen PostgreSQL-Instanz oder einem einzelnen PostgreSQL-Cluster.

• Pool — Gemeinsam genutzte Tabellen für Mandanten in einer einzigen Instanz und einem einzigen Schema.

	Silo	Brücke mit separaten Datenbanken	Brücke mit separaten Schemata	Schwimmbecken
Anwendungsfall	Die Isolierung von Daten mit vollständiger Kontrolle über die Ressourcennutzung ist eine wichtige Anforderung, oder Sie haben sehr große und sehr leistungsempfindliche Mandanten.	Die Isolierung von Daten ist eine wichtige Anforderung, und es sind nur begrenzte oder keine Querverweise von Mieterdaten erforderlich.	Moderate Anzahl von Mietern mit einer moderaten Datenmenge. Dies ist das bevorzugte Modell, wenn Sie die Daten von Mietern mit Querverweisen versehen müssen.	Große Anzahl von Mietern 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 das Erstellen 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 der Datenbankverbindung zwischen Mandanten.)	Erheblicher Aufwand erforderlich. (Eine Verbindungspoolkonfiguration pro Mandant, sofern Sie Amazon RDS Proxy nicht verwenden.) Weniger effizient. (Keine gemeinsame Nutzung der Datenbankverbindung zwischen Mandanten und Gesamtzahl der Verbindungen. Die Nutzung durch alle Mandanten ist je nach DB-Instance-Klasse begrenzt.)	Weniger Aufwand erforderlich. (Eine Verbindungspool-Konfiguration für alle Mandanten.) Mäßig effizient. (Wiederverwendung der Verbindung über denSET SCHEMA BefehlSET ROLE oder nur im Sitzungspool). SETBefehle führen bei der Verwendung von Amazon RDS Proxy auch zu Sitzungs-Pinning, aber die Client-Verbindungspools können entfernt werden und direkte Verbindungen können für jede Anforderung aus Effizienzgründen hergestellt werden.)	Geringster Aufwand erforderlich. Am effizientesten. (Ein Verbindungspool für alle Mandanten und effiziente Wiederverwendung von Verbindungen für alle Mandanten. Die Datenbankverbindungslimits für Datenbankverbindungen basieren auf der DB-Instance-Klasse.)
Datenbankpflege (Vakuummanagement) und Ressourcennutzung	Einfachere Verwaltung.	Mittlere Komplexität. (Könnte zu einem hohen Ressourcenverbrauch führen, da danach für jede Datenbank ein Vakuumarbeiter gestartet werden mussvacuum_naptime, was zu einer hohen CPU-Auslastung des Autovacum-Launchers führt. Möglicherweise ist mit dem Löschen der PostgreSQL-Systemkatalogtabellen für jede Datenbank zusätzlicher Aufwand verbunden.)	Große PostgreSQL-Systemkatalogtabellen (pg_catalogGesamtgröße in mehreren zehn GB, abhängig von der Anzahl der Mieter und Beziehungen. Wahrscheinlich sind Änderungen an den staubsaugenden Parametern erforderlich, um das Aufblähen des Tisches zu kontrollieren.)	Die Tabellen können je nach Anzahl der Mandanten und Daten pro Mandant umfangreich sein. (Wahrscheinlich sind Änderungen an den staubsaugenden Parametern erforderlich, um das Aufblähen des Tisches 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 (einmalig in der gemeinsamen Datenbank).
Bereitstellungsaufwand ändern	erhebliche Anstrengungen. (Connect zu jeder einzelnen Instance her und führen Sie die Änderungen durch.)	erhebliche Anstrengungen. (Connect zu jeder Datenbank und jedem Schema her und führen Sie Änderungen durch.)	Mäßiger Aufwand. (Connect zu einer gemeinsamen Datenbank her und führen Sie Änderungen für jedes Schema durch.)	Minimaler Aufwand. (Connect zu einer gemeinsamen Datenbank her und führen Sie Änderungen durch.)
Einsatz 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	Verwaltbare Abfrageleistung	Verwaltbare Abfrageleistung	Verwaltbare Abfrageleistung	Es ist wahrscheinlich ein erheblicher Aufwand erforderlich, um die Abfrageleistung aufrechtzuerhalten. (Im Laufe der Zeit können Abfragen aufgrund der zunehmenden Größe der 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 zwischen den Mietern.)	Mäßige Auswirkungen. (Mandanten nutzen gemeinsame Ressourcen wie Instanz-CPU und Arbeitsspeicher.)	Mäßige Auswirkungen. (Mandanten nutzen gemeinsame Ressourcen wie Instanz-CPU und Arbeitsspeicher.)	Starke Auswirkungen. (Mieter beeinflussen sich gegenseitig in Bezug auf Ressourcen, Blockkonflikte usw.)
Tuning auf Mandantenebene (z. B. Erstellung zusätzlicher Indizes pro Mandant oder Optimierung von DB-Parametern für einen bestimmten Mandanten)	Mögliche.	Das ist möglich. (Änderungen auf Schemaebene können für jeden Mandanten vorgenommen werden, aber die Datenbankparameter sind global für alle Mandanten.)	Das ist möglich. (Änderungen auf Schemaebene können für jeden Mandanten vorgenommen werden, aber die Datenbankparameter sind global für alle Mandanten.)	Das ist möglich. (Die Tische werden von allen Mietern gemeinsam genutzt.)
Den Aufwand für leistungssensible Mieter wieder ins Gleichgewicht bringen	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 die logische Replikation oderpg_dump um die Datenbank zu exportieren, aber die Ausfallzeiten können je nach Datengröße langwierig sein. Sie können die Funktion für transportable Datenbanken in Amazon RDS for PostgreSQL verwenden, um Datenbanken schneller zwischen Instanzen zu kopieren.)	Mäßig, aber wahrscheinlich mit langen Ausfallzeiten verbunden. (Verwenden Sie die logische Replikation oderpg_dump um das Schema zu exportieren, aber die Ausfallzeiten können je nach Datengröße langwierig sein.)	Signifikant, da sich alle Mieter dieselben Tische teilen. (Die gemeinsame Nutzung der Datenbank erfordert das Kopieren aller Daten auf eine andere Instanz und einen zusätzlichen Schritt zur Bereinigung der Mandantendaten.) Erfordert höchstwahrscheinlich eine Änderung der Anwendungslogik.
Datenbankausfälle für signifikante Upgrades von Hauptversionen	Standardausfallzeiten. (Hängt von der Größe des PostgreSQL-Systemkatalogs ab.)	Längere Ausfallzeiten wahrscheinlich. (Je nach Größe des Systemkatalogs variiert die Zeit. PostgreSQL-Systemkatalogtabellen werden auch datenbankübergreifend dupliziert.	Längere Ausfallzeiten wahrscheinlich. (Abhängig von der Größe des PostgreSQL-Systemkatalogs variiert die Zeit.)	Standardausfallzeiten. (Hängt von der Größe des PostgreSQL-Systemkatalogs ab.)
Administrationsaufwand (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 Mandantenebene	Höchster. (Jeder Mandant schlägt fehl und erholt sich selbstständig.)	Höherer Wirkungsbereich. (Bei Hardware- oder Ressourcenproblemen fallen alle Mandanten zusammen aus und erholen sich gemeinsam.)	Höherer Wirkungsbereich. (Bei Hardware- oder Ressourcenproblemen fallen alle Mandanten zusammen aus und erholen sich gemeinsam.)	Höherer Wirkungsbereich. (Bei Hardware- oder Ressourcenproblemen fallen alle Mandanten zusammen aus und erholen sich gemeinsam.)
Backup- und Recovery-Aufwand auf Mandantenebene	Der geringste Aufwand. (Jeder Mandanten kann unabhängig gesichert und wiederhergestellt werden.)	Mäßiger Aufwand. (Verwenden Sie den logischen Export und Import für jeden Mandanten. Etwas Codierung und Automatisierung sind erforderlich.)	Mäßiger Aufwand. (Verwenden Sie den logischen Export und Import für jeden Mandanten. Etwas Codierung und Automatisierung sind erforderlich.)	erhebliche Anstrengungen. (Alle Mieter teilen sich dieselben Tische.)
point-in-time Wiederherstellungsmaßnahmen auf Mieterebene	Minimaler Aufwand. (Verwenden Sie die Point-in-Zeitwiederherstellung mithilfe von Snapshots oder verwenden Sie Backtracking in Amazon Aurora.)	Mäßiger Aufwand. (Verwenden Sie Snapshot-Wiederherstellung, gefolgt von Export/Import. Dies wird jedoch ein langsamer Vorgang sein.)	Mäßiger Aufwand. (Verwenden Sie 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.	Verschiedene Schemas für jeden Mandanten	Gängige Schemata.
Anpassung pro Mandant (z. B. zusätzliche Tabellenspalten für einen bestimmten Mandanten)	Mögliche.	Mögliche.	Mögliche.	Kompliziert (weil sich alle Mieter dieselben Tische teilen).
Effizienz der Katalogverwaltung auf der Ebene der objektrelationalen Zuordnung (ORM) (z. B. Ruby)	Effizient (weil die Client-Verbindung mandantenspezifisch ist).	Effizient (weil die Client-Verbindung spezifisch für eine Datenbank ist).	Mäßig effizient. (Abhängig vom verwendeten ORM, dem Benutzer-/Rollensicherheitsmodell und dersearch_path Konfiguration speichert der Client manchmal die Metadaten für alle Mandanten im Cache, was zu einer hohen Speichernutzung der DB-Verbindung führt.)	Effizient (weil sich alle Mieter dieselben Tische teilen).
Konsolidierter Aufwand zur Berichterstattung von Mietern	erhebliche Anstrengungen. (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.)	erhebliche Anstrengungen. (Sie müssen FDWs verwenden, um Daten in allen Mandanten oder ETL in einer anderen Berichtsdatenbank zu konsolidieren.)	Mäßiger Aufwand. (Sie können Daten in allen Schemas aggregieren, indem Sie Unionen verwenden.)	Minimaler Aufwand. (Alle Mandantendaten befinden sich in denselben Tabellen, sodass die Berichterstattung einfach ist.)
Mandantenspezifische schreibgeschützte Instanz für Berichte (z. B. basierend auf einem Abonnement)	Der geringste Aufwand. (Erstellen eines Lesereplikats.)	Mäßiger Aufwand. (Sie können die logische Replikation oder denAWS Database Migration Service [AWS DMS] zur Konfiguration verwenden.)	Mäßiger Aufwand. (Sie können die logische Replikation verwenden oderAWS DMS konfigurieren.)	Kompliziert (weil sich alle Mieter dieselben Tische teilen).
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. (Da alle Mandanten dieselben Tabellen verwenden, müssen Sie Funktionen wie Sicherheit auf Zeilenebene [RLS] zur Mandantenisolierung implementieren.)
Mandantenspezifischer Speicherverschlüsselungsschlüssel	Mögliche. (Jeder PostgreSQL-Cluster kann seinen eigenenAWS Key Management Service [AWS KMS] Schlüssel für die Speicherverschlüsselung haben.)	Das ist möglich. (Alle Mandanten verwenden denselben KMS-Schlüssel für die Speicherverschlüsselung.)	Das ist möglich. (Alle Mandanten verwenden denselben KMS-Schlüssel für die Speicherverschlüsselung.)	Das ist möglich. (Alle Mandanten verwenden denselben KMS-Schlüssel für die Speicherverschlüsselung.)
Verwendung vonAWS Identity and Access Management (IAM) für die Datenbankauthentifizierung für jeden Mandanten	Mögliche.	Mögliche.	Möglich (indem separate PostgreSQL-Benutzer für jedes Schema vorhanden sind).	Nicht möglich (weil die Tische von allen Mietern gemeinsam genutzt werden).
Kosten für die Infrastruktur	Am höchsten (weil nichts geteilt wird).	Mäßig.	Mäßig.	Am wenigsten.
Datenduplizierung und Speichernutzung	Höchstes Aggregat für alle Mieter. (Die PostgreSQL-Systemkatalogtabellen und die statischen und gemeinsamen Daten der Anwendung werden für alle Mandanten dupliziert.)	Höchstes Aggregat für alle Mieter. (Die PostgreSQL-Systemkatalogtabellen und die statischen und gemeinsamen Daten der Anwendung werden für alle Mandanten dupliziert.)	Mäßig. (Die statischen und gemeinsamen Daten der Anwendung können sich in einem gemeinsamen Schema befinden und von anderen Mandanten abgerufen werden.)	Minimal. (Keine Vervielfältigung von Daten. Die statischen und allgemeinen Daten der Anwendung können sich im selben Schema befinden.)
Mandantenorientiertes Monitoring (finden Sie schnell heraus, welcher Mandant Probleme verursacht)	Der geringste Aufwand. (Da jeder Mandant separat überwacht wird, ist es einfach, 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.)	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.)	erhebliche Anstrengungen. (Da alle Mandanten alle Ressourcen, einschließlich Tabellen, gemeinsam nutzen, müssen Sie die Bind-Variablenerfassung verwenden, um zu überprüfen, zu welchem Mandanten eine bestimmte SQL-Abfrage gehört.)
Zentrales Management und Gesundheits- und Aktivitätsüberwachung	Erheblicher Aufwand (Einrichtung einer zentralen Überwachung und einer zentralen Kommandozentrale).	Mäßiger Aufwand (weil sich alle Mieter dieselbe Instanz teilen).	Mäßiger Aufwand (weil sich alle Mieter dieselbe Instanz teilen).	Minimaler Aufwand (da sich alle Mandanten dieselben Ressourcen teilen, einschließlich des Schemas).
Wahrscheinlichkeit, dass Object Identifier (OID) und Transaktions-ID (XID) Wraparound	Minimal.	Hoch. (Da es sich bei OID um einen einzelnen clusterweiten PostgreSQL-Zähler handelt, kann es zu Problemen bei der effektiven Datenabsaugung zwischen physischen Datenbanken kommen).	Mäßig. (Weil OID, XID ein einzelner clusterweiter PostgreSQL-Zähler ist).	Hoch. (Beispielsweise kann eine einzelne Tabelle je nach Anzahl der out-of-line Spalten das TOAST-OID-Limit von 4 Milliarden erreichen.)