Multi-Tenant Rails-Anwendung: Was sind die Vor- und Nachteile der verschiedenen Techniken?

8

Ich habe ursprünglich meine Ruby on Rails-Anwendung für einen Client geschrieben. Jetzt ändere ich es, damit es für verschiedene Kunden verwendet werden kann. Mein Endziel ist, dass ein Benutzer (nicht ich) auf eine Schaltfläche klicken und ein neues Projekt erstellen kann. Dann werden alle notwendigen Änderungen (neues Schema, neue Tabellen, Code-Bearbeitung) generiert, ohne dass ich eine database.yml-Datei bearbeiten oder neue Schemadefinitionen hinzufügen muss. Ich verwende derzeit den SCOPED-Zugang. Also habe ich ein Projektmodell und andere zugeordnete Modelle haben eine Spalte project_id.

Ich habe mir andere Beiträge zu Multi-Tenant-Anwendungen in Rails angeschaut. Viele Leute empfehlen anscheinend, für jeden neuen Client in Postgres ein anderes Schema zu erstellen. Für mich ist es jedoch nicht sehr hilfreich, wenn ein neuer Kunde ein anderes Schema in Bezug auf das Datenmodell hat. Jeder Client hat dieselben Tabellen, Zeilen, Spalten usw.

Meine Vision für jeden Kunden ist, dass meine Produktionsdatenbank zuerst eine Tabelle mit verschiedenen Projekten / Kunden hat. Und jede dieser Tabellen verweist auf eine Reihe von Tabellen, die mit verschiedenen Daten ziemlich identisch sind. Mit anderen Worten eine Tabelle von Tabellen. Oder anders gesagt, die erste Tabelle wird einem anderen Datensatz für jeden Client mit derselben Struktur zugeordnet.

Hat ich meine Vision überhaupt so erklärt, wie Postgres verschiedene "Schemata" implementiert? Sieht es wie verschachtelte Tabellen aus? Oder muss Postgres trotzdem alle Informationen in der Datenbank abfragen? Ich benutze derzeit kein Postgres, aber ich würde gerne lernen, wenn es zum Design passt. Wenn Sie Datenbanksoftware kennen, die mit Rails arbeitet, die meinen Anforderungen entsprechen, lassen Sie es mich bitte wissen.

Momentan verwende ich Bereiche, um Multi-Tenant-Anwendungen zu erstellen, aber es fühlt sich nicht skalierbar oder sauber an. Es macht es jedoch für einen nicht-technischen Benutzer sehr leicht, ein neues Projekt zu erstellen, vorausgesetzt, ich gebe ihnen ausfüllbare Informationen. Wissen Sie, ob es mit der Multi-Schema-Postgres-Definition möglich ist, dass es automatisch funktioniert, nachdem ein Benutzer auf eine Schaltfläche geklickt hat? Und ich würde es vorziehen, dass dies von Rails und nicht von einem externen Skript, wenn möglich, behandelt wird? (bitte beraten Sie sich in beiden Fällen)

Am wichtigsten, empfehlen Sie irgendwelche Plugins oder dass ich ein anderes Framework für diese Aufgabe annehmen sollte? Ich habe festgestellt, dass Rails in einigen Abstraktionsfällen wie oben beschrieben begrenzt ist und dies ist das erste Mal, dass ich auf ein Problem mit der Rails-Skalierung stoße.

Jegliche Beratung in Bezug auf Multi-Tenant-Anwendungen oder meine Situation ist willkommen. Fragen zur Klärung oder zusätzliche Beratung sind ebenfalls willkommen.

Danke, --Dave

    
David Groff 09.08.2011, 21:08
quelle

3 Antworten

1

Vergessen Sie nicht, Standardbereiche zu verwenden, während Sie benannte Bereiche so erstellen, wie Sie jetzt arbeiten, es fühlt sich an, als könnte es besser gemacht werden. Ich stieß auf diesen Leitfaden von Samuel Kadolph, der dieses Thema vor ein paar Monaten aufgriff sieht so aus, als könnte es gut für Ihre Situation funktionieren und den Vorteil haben, Ihre Anwendung frei von einigen PgSQL-Funktionen zu halten.

Grundsätzlich beschreibt er die Einstellung der Anwendung wie folgt: Er fügt der Anwendung die Konzepte von tennants hinzu und verwendet diese dann, um die Daten zur Abfragezeit mithilfe der Datenbank zu erfassen.

    
Devin M 09.08.2011, 21:19
quelle
8

MSDN bietet eine gute Einführung in die mandantenfähige Datenarchitektur .

An einem Ende des Spektrums haben Sie eine Datenbank pro Mandant ("shared nothing"). "Shared Nothing" macht Disaster Recovery sehr einfach und hat den höchsten Grad an Isolation zwischen den Mandanten. Aber es hat auch die höchsten durchschnittlichen Kosten pro Mandant und es unterstützt die wenigsten Mandanten pro Server.

Am anderen Ende des Spektrums speichern Sie eine Mandanten-ID-Nummer in jeder Zeile jeder gemeinsam genutzten Tabelle ("shared everything"). "Alles freigegeben" macht Disaster Recovery sehr schwierig - für einen einzelnen Mandanten müssten Sie nur einige Zeilen in jeder gemeinsam genutzten Tabelle wiederherstellen - und es hat den geringsten Isolationsgrad. (Schlecht geformte Abfragen können private Daten offenlegen.) Aber es hat die niedrigsten Kosten pro Mandant und es unterstützt die höchste Anzahl von Mandanten pro Server.

  

Meine Vision für jeden Kunden ist, dass meine Produktionsdatenbank zuerst eine hat   Tabelle mit verschiedenen Projekten / Kunden. Und jede dieser Tabellen   Links zu einer Reihe von Tabellen, die mit verschiedenen ziemlich identisch sind   Daten. Mit anderen Worten eine Tabelle von Tabellen. Oder mit anderen Worten, der erste   Die Tabelle wird einem anderen Datensatz für jeden Client zugeordnet, der über die   gleiche Struktur.

Dies klingt , als würden Sie über ein Schema pro Mandant sprechen. Achten Sie genau auf die Berechtigungen (SQL GRANT und REVOKE Statements. Und ALTER DEFAULT PRIVILEGES .)

    
quelle
5

Es gibt zwei Railscasts im Multitenancy-Modus, die Bereiche und Subdomains verwenden, und einen weiteren, der die Handhabung von mehrere Schemata .

Es gibt auch das mandantenfähige Juwel , das bei Ihren Bereichen helfen könnte und Apartment Juwel für die Handhabung mehrerer Schemata.

Hier ist auch eine gute Präsentation auf multitenancy-with-rails .

    
cwadding 23.10.2012 23:51
quelle