Was ist der empfohlene Ansatz für mandantenfähige Datenbanken in MongoDB?
Ich denke darüber nach, eine Multi-Tenant-App mit MongoDB zu erstellen. Ich habe keine Vermutung, wie viele Mieter ich noch hätte, aber ich würde gerne in die Tausende gehen.
Ich kann mir drei Strategien vorstellen:
- Alle Mieter in derselben Sammlung, die mieterspezifische Felder für die Sicherheit verwenden
- 1 Sammlung pro Mandant in einer einzelnen gemeinsam genutzten Datenbank
- 1 Datenbank pro Mieter
Die Stimme in meinem Kopf deutet an, dass ich Option 2 nehme.
Gedanken und Implikationen, jemand?
Ich habe das gleiche Problem zu lösen und erwäge auch Varianten. Da ich über jahrelange Erfahrung bei der Erstellung von SaaS - Multi-Tenant-Anwendungen verfügte, wählte ich auch die zweite Option basierend auf meinen vorherigen Erfahrungen mit relationalen Datenbanken.
Während meiner Recherche fand ich diesen Artikel auf der mongodb-Support-Site (seit dem Wegfall der Hinzufügung): https://web.archive.org/web/20140812091703/http://support.mongohq.com /use-cases/multi-tenant.html
Die Jungs erklärten, 2. Optionen um jeden Preis zu vermeiden, was meines Erachtens nicht besonders spezifisch für Mongodb ist. Mein Eindruck ist, dass dies aufgrund der Besonderheiten des Datenbankdesigns für die meisten NoSQL-Datenbanken gilt, die ich recherchiert habe (CoachDB, Cassandra, CouchBase Server usw.).
Sammlungen (oder Buckets oder wie sie in verschiedenen DBs bezeichnet werden) sind nicht dasselbe wie Sicherheitsschemas in RDBMS, obwohl sie sich als Container für Dokumente verhalten, die sie für eine gute Mandantentrennung nicht nutzen. 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 1. Option empfehlen, wenn:
- Sie haben genügend Zeit und Ressourcen, um sich mit der Komplexität von Design, Implementierung und Test dieses Szenarios auseinanderzusetzen.
- Wenn die Struktur und die Funktionalität der Datenbank in der Datenbank für verschiedene Mandanten nicht sehr unterschiedlich sind.
- Ihr Anwendungsdesign ermöglicht es Mandanten, zur Laufzeit nur minimale Anpassungen vorzunehmen.
- Wenn Sie den Speicherplatz optimieren und die Verwendung von Hardware-Ressourcen reduzieren möchten
- Wenn Sie Tausende von Mietern haben werden.
- Wenn Sie schnell und kostengünstig skalieren möchten.
- Wenn Sie KEINE Daten auf Basis von Mandanten sichern möchten, halten Sie für jeden Mandanten separate -Backups bereit. Das ist auch in diesem Szenario möglich, aber der Aufwand wird enorm sein.
Ich würde Variante 3 wählen, wenn:
- Sie werden eine kleine Liste von Mietern haben (mehrere Hundert).
- Aufgrund der Besonderheiten des Unternehmens müssen Sie die großen Unterschiede in der Datenbankstruktur für verschiedene Mandanten unterstützen können (z. B. Integration in Systeme von Drittanbietern, Import/Export von Daten).
- Ihr Anwendungsdesign ermöglicht Kunden (Mandanten), wesentliche Änderungen an der Anwendungslaufzeit vorzunehmen (Hinzufügen von Modulen, Anpassen der Felder usw.).
- Wenn Sie über genügend Ressourcen verfügen, um schnell neue Hardware-Knoten zu skalieren.
- Wenn Sie Versionen/Backups von Daten pro Mandant aufbewahren müssen. Auch die Wiederherstellung wird einfach sein.
- Es gibt gesetzliche/behördliche Auflagen, die Sie zwingen, verschiedene Mieter in verschiedenen Datenbanken (sogar in Rechenzentren) zu halten.
- Wenn Sie die sofort einsatzbereiten Sicherheitsfunktionen von mongodb wie Rollen nutzen möchten.
- Es gibt große Unterschiede in Bezug auf die Größe der Mieter (Sie haben viele kleine Mieter und wenige sehr große Mieter).
Wenn Sie weitere Details zu Ihrer Bewerbung veröffentlichen, kann ich Sie vielleicht ausführlicher beraten.
Ich habe eine gute Antwort in den Kommentaren dieses Links 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 dem Kommentar von David Mytton:
Wir haben uns entschieden, keine Datenbank per .__ zu haben. Kunden wegen der Art und Weise MongoDB ordnet seine Datendateien zu. Jeder Datenbank verwendet einen eigenen Satz von Dateien:
Die erste Datei für eine Datenbank ist Datenbankname.0, dann Datenbankname.1 usw. Datenbankname.0 wird 64 MB, dbname.1 128 MB usw. sein. bis 2 GB. Sobald die Dateien 2 GB in .__ erreichen. Größe ist jede nachfolgende Datei ebenfalls 2 GB.
Wenn also die letzte vorhandene Datei ist sagen wir, 1 GB, diese Datei könnte zu 90% leer sein wenn es kürzlich erreicht wurde.
aus dem Handbuch.
Melden Sie sich als Benutzer für die Testversion an und geben Sie Dinge würden gehen, würden wir mehr und mehr bekommen. Datenbanken mit mindestens 2 GB in Größe, auch wenn die gesamten Daten Datei wurde nicht verwendet. Wir fanden das verwendet ein im Vergleich zu mehrere Datenbanken für alle zu haben Kunden, bei denen der Speicherplatz vorhanden sein kann mit maximaler Effizienz gewöhnt.
Das Sharding wird pro Sammlung angezeigt Basis als Standard, der eine Problem, wo die Sammlung nie erreicht die Mindestgröße zum Starten Scherben, wie es für ein ziemlich .__ der Fall ist. einige von uns (z. B. Sammlungen nur , die Benutzeranmeldedaten speichern). Jedoch, wir haben darum gebeten, dass dies auch in der Lage sein, auf einer pro Datenbank ausgeführt zu werden Niveau. Sehen http://jira.mongodb.org/browse/SHARDING-41
Es gibt keine Kompromisse bei der Leistung viele Sammlungen verwenden. Sehen http://www.mongodb.org/display/DOCS/User+a+Large+Number+of+Collections
Es gibt einen sinnvollen Artikel über MSDN zur Multi-Tenant-Datenarchitektur , auf den Sie sich beziehen möchten. Einige wichtige Themen, die in diesem Artikel angesprochen werden:
- Wirtschaftliche Überlegungen
- Sicherheit
- Überlegungen der Mieter
- Regulatorisch (legal)
- Geschicklichkeitsbelange
Außerdem werden einige Muster für die Konfiguration von Software as a Service (SaaS) angesprochen.
Darüber hinaus ist ein Blick wert ein interessanter Bericht von den SQL Anywhere-Typen .
Meine persönliche Einstellung - Sofern Sie nicht sicher sind, ob erzwungene Sicherheit/Vertrauen erzwungen ist, würde ich Option 3 wählen oder, wenn Bedenken hinsichtlich der Skalierbarkeit einen Fallback von Option 2 mindestens verbieten. Das heißt, ich bin kein Profi mit MongoDB. Mit einem gemeinsamen "Schema" werde ich ziemlich nervös - aber ich werde mich gerne an erfahrene Praktizierende wenden.
Ich würde Option 2 wählen.
Sie können jedoch die Befehlszeilenoption "mongod.exe" --smallfiles festlegen. Dies bedeutet, dass die größte Dateigröße eines Extents 0,5 Gigabyte und nicht 2 Gigabyte beträgt. Ich habe das mit Mongo 1.42 getestet. Option 3 ist also nicht unmöglich.
Während die Diskussion hier über NoSQL und hauptsächlich über MongoDB geht, verwenden wir bei Citus PostgreSQL und bauen eine verteilte/gestaffelte Multi-Tenant-Datenbank auf.
Unser Anwendungsfall-Leitfaden führt durch eine Beispiel-App, die das Schema und verschiedene mandantenfähige Funktionen abdeckt.
Für unstrukturiertere Daten verwenden wir die JSONB-Spalte von PostgreSQL, um diese und mandantenspezifischen Daten zu speichern.
Nach meinen Recherchen in MongoDB. Trucos y consejos. Aplicaciones Multitenant. Diese Option wird nicht empfohlen, wenn Sie nicht wissen, wie viele Mieter Sie haben können, es könnten Tausende sein und es wäre kompliziert, wenn es ums Sharding geht. Stellen Sie sich außerdem vor, Tausende von Sammlungen in einer einzigen Datenbank zu haben ... In Ihrem Fall wird daher empfohlen, die Option 1 zu verwenden. Wenn Sie nun eine begrenzte Anzahl von Benutzern haben, ist dies bereits ein Unterschied. Ja, Sie könnten die Option 2 verwenden, wie Sie es gedacht haben.