Die Leistung ist nicht unbedingt schlechter. Wie im Artikel erläutert, gibt es bestimmte Bedingungen, die den Schemaansatz je nach Anwendungsdesign und Arbeitslast verbessern oder verschlechtern. Lassen Sie mich die Kompromisse zwischen den Ansätzen „Tenant-Schema“ und „Shared-Table“ erläutern:
Mandantenschema ist am besten, wenn Sie eine relativ kleine Anzahl ziemlich großer Mieter haben. Ein Beispiel hierfür wäre eine Buchhaltungsanwendung mit nur bezahlten Abonnementbenutzern. Zu den Dingen, die es für Sie zur leistungsstärkeren Option machen, gehören:
- eine kleine Anzahl von Mandanten mit jeweils vielen Daten
- ein relativ einfaches Schema ohne viele Tabellen pro Mandant
- eine Notwendigkeit, die Schemas einiger Mandanten anzupassen
- Möglichkeit, Datenbankrollen pro Mandant zu nutzen
- Mandantendaten von einem Server auf einen anderen migrieren
- Möglichkeit, für jeden Mandanten einen dedizierten Anwendungsserver in Ihrer Cloud einzurichten
Zu den Dingen, die es zu einer leistungsschwachen Option machen, gehören:
- viele Mandanten mit jeweils sehr wenig Daten
- zustandsloser Ansatz für Verbindungen, bei denen jede Anfrage ein beliebiger Mandant sein kann
- Client-Bibliothek oder ORM, die Metadaten für alle Tabellen zwischenspeichert (wie ActiveRecord)
- eine Voraussetzung für effizientes, hochleistungsfähiges Verbindungspooling und/oder Caching
- Probleme mit VACUUM und anderen PostgreSQL-Verwaltungsvorgängen, die sich schlecht über Tausende von Tabellen skalieren lassen.
Ob das Mandantenschema schlecht für Migrationen/Schemaänderungen ist, hängt wirklich davon ab, wie Sie sie durchführen. Es ist schlecht für die schnelle Einführung einer universellen Schemaänderung, aber gut für die Bereitstellung von Schemaänderungen als schrittweise Einführung über Mandanten hinweg.
gemeinsame Tabelle 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 mobile Social-Media-Anwendung, die kostenlose Konten zulässt und daher Tausende von Konten aufgegeben hat. Andere Dinge, die das Shared-Table-Modell vorteilhaft machen, sind:
- besser für Verbindungspooling, da alle Verbindungen denselben Pool verwenden können
- besser für die PostgreSQL-Administration, da insgesamt weniger Tabellen
- besser für Migrationen und Schemaänderungen, da es nur einen "Satz" von Tabellen gibt
Der Hauptnachteil von gemeinsam genutzten Tabellen ist die Notwendigkeit, die Mandantenfilterbedingung an jede einzelne Abfrage in der Anwendungsschicht anzuhängen. Es ist auch problematisch, weil:
- Abfragen, die viele Tabellen verbinden, können eine schlechte Leistung erbringen, weil der Mandantenfilter die Abfrageplanung durcheinander bringt
- Tabellen, die auf 100 Millionen Zeilen anwachsen, können bestimmte Leistungs- und Wartungsprobleme verursachen
- keine Möglichkeit, mandantenspezifische Anwendungsänderungen oder Schema-Upgrades vorzunehmen
- kostspieliger, Mandanten zwischen Servern zu migrieren
Welches Modell „besser abschneidet“, hängt also wirklich davon ab, welche Kompromisse Sie am schlimmsten verletzen.
Es gibt auch ein Hybridmodell, „Mandantenansicht“, bei dem die eigentlichen Daten in gemeinsam genutzten Tabellen gespeichert werden, aber jede Anwendungsverbindung verwendet Ansichten von Sicherheitsbarrieren um die Daten anzuzeigen. Dies hat einige der Kompromisse jedes Modells. In erster Linie bietet es die Sicherheitsvorteile des Tenant-Schema-Modells mit einigen der Leistungsnachteile beider Modelle.
