Ich habe das gleiche Problem zu lösen und erwäge auch Varianten. Da ich jahrelange Erfahrung in der Erstellung von mandantenfähigen SaaS-Anwendungen habe, wollte ich auch die zweite Option auswählen, basierend auf meinen bisherigen Erfahrungen mit relationalen Datenbanken.
Während meiner Recherche habe ich diesen Artikel auf der Mongodb-Support-Website gefunden (vor langer Zeit hinzugefügt, seit er weg ist):https://web.archive.org/web/20140812091703/http://support.mongohq.com/use-cases/multi -Mandant.html
Die Jungs gaben an, 2. Optionen um jeden Preis 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 der von mir recherchierten NoSQL-Datenbanken (CoachDB, Cassandra, CouchBase Server usw.) gilt.
Sammlungen (oder Buckets oder wie auch immer sie es in verschiedenen DBs nennen) sind nicht dasselbe wie Sicherheitsschemas in RDBMS, obwohl sie sich als Container für Dokumente verhalten, sind sie für die Anwendung einer guten Mandantentrennung nutzlos. Ich konnte keine NoSQL-Datenbank finden, die Sicherheitseinschrä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 sich mit der Komplexität des Designs, der Implementierung und des Testens dieses Szenarios auseinanderzusetzen.
- Wenn Sie keine großen Unterschiede in Struktur und Funktionalität in der Datenbank für verschiedene Mandanten haben werden.
- Ihr Anwendungsdesign ermöglicht Mandanten nur minimale Anpassungen zur Laufzeit.
- Wenn Sie Speicherplatz optimieren und die Nutzung von Hardwareressourcen minimieren möchten.
- Wenn Sie Tausende von Mietern haben werden.
- Wenn Sie schnell und kostengünstig skalieren möchten.
- Wenn Sie Daten NICHT basierend auf Mandanten sichern möchten (halten Sie getrennte Sicherungen für jeden Mandanten). Das ist auch in diesem Szenario möglich, aber der Aufwand ist enorm.
Ich würde Variante 3 wählen, wenn:
- Sie werden eine kleine Liste von Mietern haben (mehrere hundert).
- Die Besonderheiten des Unternehmens erfordern, dass Sie in der Lage sein müssen, große Unterschiede in der Datenbankstruktur für verschiedene Mandanten zu unterstützen (z. B. Integration mit Systemen von Drittanbietern, Import/Export von Daten).
- Ihr Anwendungsdesign wird es Kunden (Mandanten) ermöglichen, wesentliche Änderungen in der Anwendungslaufzeit vorzunehmen (Module hinzufügen, Felder anpassen usw.).
- Wenn Sie über genügend Ressourcen verfügen, um schnell mit neuen Hardwareknoten aufzuskalieren.
- Wenn Sie Versionen/Sicherungen von Daten pro Mandant aufbewahren müssen. Auch die Wiederherstellung wird einfach sein.
- Es gibt gesetzliche/regulatorische Einschränkungen, die Sie dazu zwingen, verschiedene Mandanten in verschiedenen Datenbanken (sogar Rechenzentren) zu halten.
- Wenn Sie die sofort einsatzbereiten Sicherheitsfunktionen von mongodb wie 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 weitere Details zu Ihrer Anwendung posten, kann ich Ihnen vielleicht genauere Ratschläge geben.
