PostgreSQL-Schemas für mandantenfähige Anwendungen
Ich lerne mandantenfähige Anwendungen und wie die PostgreSQL-Schemata dafür verwendet werden können.
Als ich mich mit dem Thema befasste, fand ich einen Artikel , in dem der Autor eine schlechte Erfahrung bei der Verwendung von PostgreSQL-Schemas in Anwendungen mit mehreren Mandanten beschreibt. Die Hauptprobleme wären eine schlechte Leistung bei Migrationen und eine hohe Auslastung der Datenbankressourcen.
Es scheint, als würde ein einziges Schema (das die Tabellen unter den Mandanten teilt) zu einer besseren Leistung führen als ein getrenntes Schema für jeden Mandanten. Aber mir kommt es komisch vor. Ich würde das Gegenteil vermuten, da Indizes für kleinere Tabellen in der Regel leichter sind als Indizes für größere Tabellen.
Warum ist die Leistung schlechter, wenn Daten in vielen kleinen Tabellen (in mehreren Schemas) getrennt sind, als wenn Daten in einigen großen Tabellen (in einem einzelnen Schema) getrennt sind?
Leistung ist nicht unbedingt schlechter. Wie im Artikel erläutert, gibt es bestimmte Bedingungen, die den Schemaansatz je nach Anwendungsdesign und Arbeitsauslastung verbessern oder verschlechtern. Lassen Sie mich die Kompromisse zwischen den Ansätzen "Tenant-Schema" und "Shared-Table" erläutern:
Tenant-Schema ist am besten geeignet, wenn Sie eine relativ kleine Anzahl relativ großer Tenants haben. Ein Beispiel hierfür wäre eine Buchhaltungsanwendung mit nur bezahlten Abonnementbenutzern. Dinge, die es für Sie zur leistungsstärksten Option machen, sind:
- eine kleine Anzahl von Mietern mit jeweils vielen Daten
- ein relativ einfaches Schema ohne viele Tabellen pro Mandant
- die Schemata einiger Mandanten müssen angepasst werden
- fähigkeit, Datenbankrollen pro Mandant zu nutzen
- anforderung, die Daten eines Mandanten von einem Server auf einen anderen zu migrieren
- möglichkeit, für jeden Mandanten einen dedizierten App-Server in Ihrer Cloud einzurichten
Dinge, die es zu einer leistungsschwachen Option machen, sind:
- viele Mieter mit jeweils sehr wenig Daten
- zustandsloser Ansatz für Verbindungen, bei denen jede Anforderung ein beliebiger Mandant sein kann
- client-Bibliothek oder Orm, die Metadaten für alle Tabellen zwischenspeichert (wie ActiveRecord)
- eine Anforderung für effizientes, leistungsfähiges Verbindungspooling und/oder -caching
- probleme mit VACUUM und anderen PostgreSQL-Verwaltungsvorgängen, die über Tausende von Tabellen schlecht skaliert werden.
Ob das Mandantenschema für Migrationen/Schemaänderungen schlecht ist, hängt davon ab, wie Sie sie durchführen. Es ist schlecht, um eine universelle Schemaänderung schnell einzuführen, aber gut, um Schemaänderungen als schrittweise Einführung für mehrere Mandanten bereitzustellen.
Shared Table funktioniert besser in Situationen, in denen Sie viele Mandanten haben und viele Ihrer Mandanten nur sehr wenige Daten haben. Ein Beispiel hierfür wäre eine Social Media-Mobilanwendung, die kostenlose Konten zulässt und daher Tausende von aufgegebenen Konten hat. Weitere Vorteile des Shared Table-Modells sind:
- besser für das Verbindungs-Pooling, da alle Verbindungen denselben Pool verwenden können
- besser für die PostgreSQL-Administration, da insgesamt weniger Tabellen vorhanden sind
- besser für Migrationen und Schemaänderungen, da es nur einen "Satz" von Tabellen gibt
Der Hauptnachteil von Shared Table besteht darin, dass die Tenant-Filterbedingung an jede einzelne Abfrage in der Anwendungsebene angehängt werden muss. Es ist auch problematisch, weil:
- abfragen, die mit vielen Tabellen verknüpft sind, weisen möglicherweise eine schlechte Leistung auf, da der Mandantenfilter die Abfrageplanung deaktiviert
- tabellen, die auf 100 Millionen Zeilen anwachsen, können bestimmte Leistungs- und Wartungsprobleme verursachen
- keine Möglichkeit, mandantenabhängige Anwendungsänderungen oder Schema-Upgrades durchzuführen
- teurer, um Mandanten zwischen Servern zu migrieren
Welches Modell "besser abschneidet", hängt also davon ab, welche Kompromisse Sie am schlimmsten treffen.
Es gibt auch ein Hybridmodell, "Tenant-View", bei dem die tatsächlichen Daten in gemeinsam genutzten Tabellen gespeichert werden. Jede Anwendungsverbindung verwendet jedoch Sicherheitsbarrierenansichten , um die Daten anzuzeigen. Dies hat einige der Nachteile jedes Modells. In erster Linie bietet es die Sicherheitsvorteile des Tenant-Schema-Modells mit einigen der Leistungsnachteile beider Modelle.