Was ist der empfohlene Ansatz für mandantenfähige Datenbanken in MongoDB?

Ich denke darüber nach, eine mandantenfähige App mit MongoDB zu erstellen. Ich habe noch keine Vermutungen darüber, wie viele Mieter ich noch haben würde, aber ich würde gerne in die Tausende skalieren können.

Ich kann mir drei Strategien vorstellen:

1. Alle Mandanten in derselben Sammlung verwenden aus Sicherheitsgründen mandantenspezifische Felder
2. 1 Sammlung pro Mandant in einer einzelnen gemeinsam genutzten Datenbank
3. 1 Datenbank pro Mieter

Die Stimme in meinem Kopf deutet darauf hin, dass ich Option 2 wähle.

Gedanken und Implikationen, jemand?

Ich habe das gleiche Problem zu lösen und auch Varianten in Betracht zu ziehen. Da ich jahrelange Erfahrung in der Erstellung von SaaS-Anwendungen mit mehreren Mandanten habe, wollte ich auch die zweite Option auswählen, basierend auf meinen früheren Erfahrungen mit den relationalen Datenbanken.

Während meiner Recherche habe ich diesen Artikel auf der Mongodb-Support-Website gefunden (vor langer Zeit hinzugefügt, da er weg ist): https://web.archive.org/web/20140812091703/http://support.mongohq.com/use-cases/multi -tenant.html

Die Jungs gaben an, um jeden Preis die 2. Option zu vermeiden, was meines Wissens nicht besonders spezifisch für Mongodb ist. Mein Eindruck ist, dass dies aufgrund der Besonderheiten des Datenbankdesigns für die meisten von mir untersuchten NoSQL-Datenbanken (CoachDB, Cassandra, CouchBase Server usw.) gilt.

Sammlungen (oder Buckets oder wie auch immer sie in verschiedenen DBs aufgerufen werden) sind nicht dasselbe wie Sicherheitsschemata in RDBMS, obwohl sie sich als Container für Dokumente verhalten, die für die Anwendung einer guten Mandantentrennung unbrauchbar sind. Ich konnte keine NoSQL-Datenbank finden, die Sicherheitsbeschränkungen basierend auf Sammlungen anwenden kann.

Natürlich können Sie die rollenbasierte Sicherheit von Mongodb verwenden, um den Zugriff auf Datenbank- / Serverebene einzuschränken. ( http://docs.mongodb.org/manual/core/authorization/ )

Ich würde die erste Option empfehlen, wenn:

• Sie haben genügend Zeit und Ressourcen, um die Komplexität des Entwurfs, der Implementierung und des Testens dieses Szenarios zu bewältigen.
• Wenn Sie keine großen Unterschiede in Struktur und Funktionalität in der Datenbank für verschiedene Mandanten haben.
• Mit Ihrem Anwendungsdesign können Mandanten zur Laufzeit nur minimale Anpassungen vornehmen.
• Wenn Sie den Speicherplatz optimieren und den Verbrauch von Hardwareressourcen minimieren möchten.
• Wenn Sie Tausende von Mietern haben wollen.
• Wenn Sie schnell und kostengünstig skalieren möchten.
• Wenn Sie KEINE Daten basierend auf Mandanten sichern möchten (führen Sie separate Sicherungen für jeden Mandanten durch). Dies ist auch in diesem Szenario möglich, aber der Aufwand wird enorm sein.

Ich würde mich für Variante 3 entscheiden, wenn:

• Sie werden eine kleine Liste von Mietern haben (mehrere hundert).
• Die Besonderheiten des Geschäfts erfordern, dass Sie in der Lage sind, große Unterschiede in der Datenbankstruktur für verschiedene Mandanten zu unterstützen (z. B. Integration in Systeme von Drittanbietern, Import-Export von Daten).
• Durch Ihr Anwendungsdesign können Kunden (Mandanten) wesentliche Änderungen an der Anwendungslaufzeit vornehmen (Hinzufügen von Modulen, Anpassen der Felder usw.).
• Wenn Sie über genügend Ressourcen verfügen, um schnell mit neuen Hardwareknoten skalieren zu können.
• Wenn Sie Versionen / Sicherungen von Daten pro Mandant aufbewahren müssen. Auch die Wiederherstellung wird einfach sein.
• Es gibt gesetzliche / behördliche Einschränkungen, die Sie dazu zwingen, verschiedene Mandanten in verschiedenen Datenbanken (sogar Rechenzentren) zu halten.
• Wenn Sie die sofort einsatzbereiten Sicherheitsfunktionen von Mongodb, z. B. Rollen, vollständig nutzen möchten.
• Es gibt große Größenunterschiede zwischen den Mietern (Sie haben viele kleine Mieter und wenige sehr große Mieter).

Wenn Sie zusätzliche Details zu Ihrer Bewerbung veröffentlichen, kann ich Ihnen möglicherweise detailliertere Ratschläge geben.

Ich habe in den Kommentaren in diesem Link eine gute Antwort gefunden:

http://blog.boxedice.com/2010/02/28/notes-from-a-production-mongodb-deployment/

Grundsätzlich scheint Option 2 der beste Weg zu sein.

Zitat aus David Myttons Kommentar:

Wir haben uns entschieden, keine Datenbank pro Kunde zu haben, da MongoDB seine Datendateien zuordnet. Jede Datenbank verwendet ihre eigenen Dateien:

Die erste Datei für eine Datenbank ist Datenbankname.0, dann Datenbankname.1 usw. Datenbankname.0 ist 64 MB, Datenbankname.1 128 MB usw. bis zu 2 GB. Sobald die Dateien eine Größe von 2 GB erreichen, beträgt jede aufeinanderfolgende Datei ebenfalls 2 GB.

Wenn also die letzte vorhandene Datendatei 1 GB lautet, ist diese Datei möglicherweise zu 90% leer, wenn sie kürzlich erreicht wurde.

aus dem Handbuch.

Wenn Benutzer sich für die Testversion anmelden und die Dinge ausprobieren, erhalten wir immer mehr Datenbanken mit einer Größe von mindestens 2 GB, selbst wenn nicht die gesamte Datendatei verwendet wird. Wir haben festgestellt, dass dies eine enorme Menge an Speicherplatz beansprucht, verglichen mit mehreren Datenbanken für alle Kunden, bei denen der Speicherplatz mit maximaler Effizienz genutzt werden kann.

Das Sharding erfolgt standardmäßig pro Sammlung, was ein Problem darstellt, bei dem die Sammlung nie die Mindestgröße erreicht, um mit dem Sharding zu beginnen, wie dies bei einigen unserer Sammlungen der Fall ist (z. B. bei Sammlungen, in denen nur Benutzeranmeldedaten gespeichert sind). Wir haben jedoch darum gebeten, dass dies auch auf Datenbankebene möglich ist. Sehen http://jira.mongodb.org/browse/SHARDING-41

Es gibt keine Leistungskompromisse bei Verwendung vieler Sammlungen. Siehe http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections

Es gibt einen vernünftigen Artikel über MSDN über die mandantenfähige Datenarchitektur, auf den Sie möglicherweise verweisen möchten. Einige Schlüsselthemen, die in diesem Artikel angesprochen werden:

• Wirtschaftliche Überlegungen
• Sicherheit
• Überlegungen zum Mieter
• Regulatory (legal)
• Bedenken hinsichtlich der Fähigkeiten

Ebenfalls angesprochen werden einige Muster für die SaaS-Konfiguration (Software as a Service).

Ein Blick wert ist außerdem eine interessante Zusammenfassung der SQL Anywhere-Leute .

Meine persönliche Einstellung - es sei denn, Sie sind sich der erzwungenen Sicherheit / des erzwungenen Vertrauens sicher, würde ich Option 3 wählen oder wenn Bedenken hinsichtlich der Skalierbarkeit ein Zurückgreifen auf Option 2 zumindest verhindern. Das heißt ... ich bin kein Profi mit MongoDB. Ich werde ziemlich nervös, wenn ich ein gemeinsames "Schema" verwende - aber ich werde mich gerne erfahreneren Praktizierenden unterwerfen.

Ich würde mich für Option 2 entscheiden.

Sie können jedoch die Befehlszeilenoption mongod.exe --smallfiles festlegen. Dies bedeutet, dass die größte Dateigröße eines Bereichs 0,5 Gigabyte und nicht 2 Gigabyte beträgt. Ich habe das mit mongo 1.42 getestet. Option 3 ist also nicht unmöglich.

Nach meinen Recherchen in MongoDB. Trucos y consejos. Aplicaciones Multitenant. Diese Option wird nicht empfohlen, wenn Sie nicht wissen, wie viele Mandanten Sie haben können. Es können Tausende sein, und es wäre kompliziert, wenn es um das Sharding geht. Stellen Sie sich auch vor, Sie hätten Tausende von Sammlungen in einer einzigen Datenbank ... Also in Ihrem Fall wird empfohlen, Option eins zu verwenden. Wenn Sie nun eine begrenzte Anzahl von Benutzern haben, ist dies bereits anders und ja, Sie können Option zwei verwenden, wie Sie dachten.

Während die Diskussion hier über NoSQL und hauptsächlich MongoDB geführt wird, verwenden wir bei Citus PostgreSQL und erstellen eine verteilte / gesplittete Datenbank mit mehreren Mandanten.

Unser Anwendungsfallhandbuch führt Sie durch eine Beispiel-App, die das Schema und verschiedene mandantenfähige spezifische Funktionen abdeckt.

Für unstrukturiertere Daten verwenden wir die JSONB-Spalte von PostgreSQL, um solche und mandantenspezifische Daten zu speichern.