Vor- und Nachteile der Verwendung vieler Schemas in PostgreSQL im Gegensatz zu nur einem?

Was sind für eine große SAAS-Anwendung (unterstützt durch PostgreSql 9.4) mit über 300.000 Konten (und wachsenden Konten) die Vor- und Nachteile der Verwendung eines Schemas pro Konto zum Partitionieren der Daten im Vergleich zum Einfügen aller Daten in ein Schema und Verwenden von Fremdschlüsseln für Partitionieren Sie es in den Abfragen?

Ich weiß, dass pg_dump in der Vergangenheit bei der Arbeit mit vielen Schemata schmerzhaft langsam war, aber nicht sicher, ob dies heute der Fall ist. Mir ist auch bewusst, dass jede Änderung in der Datenbankstruktur für alle Schemas vorgenommen werden muss. Und ich weiß, dass es auf der positiven Seite einfach ist, ein Schema von einem physischen Server auf einen anderen zu verschieben und ein Schema aus der Sicherung wiederherzustellen, ganz zu schweigen davon, dass es sinnvoll ist, Daten auf diese Weise zu partitionieren.

Was sind die Vor- und Nachteile, die mir fehlen?

— Harel
quelle

Weder sieht gut aus. Eine einzelne große Tabelle ("vertikales Wachstum") ist schwer zu verwalten, und eine große Anzahl von Schemata ("horizontales Wachstum") ist ebenfalls schwer zu verwalten.

— Daniel Vérité

Ich baue ein altes System mit dieser Anzahl von Konten (und noch mehr Benutzern) neu auf. Es verwendet einen gemeinsamen Ansatz (mit mySql) und funktioniert in Bezug auf die Leistung einwandfrei. Mein Anliegen ist es, dieses Leistungsniveau beizubehalten, aber die Wartbarkeit zu verbessern.

— Harel

@ Harel Ich bin neugierig, haben Sie es mit 400k-Schemata versucht oder auf eine andere Architektur / Technologie umgestellt?

— sthzg

Ich gab die Idee auf, nachdem ich sie genauer untersucht hatte. Die Anzahl der Schemata, die ich erstellen wollte, würde jede praktische Verwendung davon zunichte machen. Ich habe in jedem Datensatz das gute alte Konto-ID-Feld verwendet. Was ich aber auch getan habe, war, numerische Auto-Inkrement-IDs zugunsten von UUIDs zu löschen, was bedeutet, dass ich ganz einfach ein ganzes Konto von einer Datenbank zur anderen übertragen kann, ohne mir Sorgen um die Integrität machen zu müssen.

— Harel

Offensichtlich haben Sie es in jedem Benutzerschema mit denselben Tabellen zu tun. Haben Sie dafür eine Vererbung in Betracht gezogen ? Es kann Ihnen für einige Anwendungsfälle das Beste aus beiden Welten bieten. Es gibt auch einige Einschränkungen . Sie können für jeden Benutzer ein eigenes Schema erstellen und trotzdem alle Benutzertabellen gleichzeitig sehr bequem durchsuchen.

Verbunden:

Abgesehen davon muss zumindest das Gewähren / Widerrufen von Berechtigungen erwähnt werden, was mit separaten Schemas viel einfacher ist.

— Erwin Brandstetter
quelle

Ich werde mich mit der Vererbung befassen. Mein Anliegen ist jedoch die Skala hier. Überall, wo ich lese, sprechen die Leute über eine mandantenfähige Schema-Strategie, beziehen sich aber auf Zehn-, Hundert- oder Tausend-Schemas. Ein Ort erwähnte 20K-Schemata. Die Frage ist - sind 400K-Schemata zu viel? Wird es einen Dateideskriptor-Wahnsinn verursachen und den Server töten? Schiebe ich es?

— Harel

Außerdem wollte ich die Mandantendaten (Konten und Benutzer) im öffentlichen Schema behalten und gleichzeitig die Schemas selbst als tatsächliche Benutzerdaten beibehalten. Diese Daten werden und werden niemals zwischen Schemata geteilt.

— Harel

Vererbung hilft mir hier nicht, glaube ich nicht. Der gemeinsame Ansatz verwendet ein einzelnes Schema mit obligatorischen Fremdschlüsseln für den Benutzer oder Mandanten, sodass ich befürchte, dass durch das Erben nichts gewonnen wird.

— Harel

Aus diesem Artikel einflussreich.io/… Ich denke, der Multi-Schema-Modus ist kein guter Weg für eine große Anzahl von Mandanten. Die Spalte tenant_id (der alte Weg) wird besser.

— Xiaohui Zhang