J'ai le même problème à résoudre et j'envisage également des variantes.Comme j'ai des années d'expérience dans la création d'applications SaaS multi-locataires, j'allais également sélectionner la deuxième option en fonction de mon expérience précédente avec les bases de données relationnelles.
En faisant mes recherches, j'ai trouvé cet article sur le site de support de mongodb (ajouté il y a longtemps depuis qu'il est parti):https://web.archive.org/web/20140812091703/http://support.mongohq.com/use-cases/multi -tenant.html
Les gars ont déclaré qu'il fallait éviter à tout prix les deuxièmes options, ce qui, si je comprends bien, n'est pas particulièrement spécifique à mongodb. Mon impression est que cela s'applique à la plupart des bases de données NoSQL que j'ai recherchées (CoachDB, Cassandra, CouchBase Server, etc.) en raison des spécificités de la conception de la base de données.
Les collections (ou les compartiments ou comment ils l'appellent dans différentes bases de données) ne sont pas la même chose que les schémas de sécurité dans RDBMS bien qu'ils se comportent comme un conteneur pour les documents, ils sont inutiles pour appliquer une bonne séparation des locataires. Je n'ai pas trouvé de base de données NoSQL pouvant appliquer des restrictions de sécurité basées sur les collections.
Bien sûr, vous pouvez utiliser la sécurité basée sur les rôles mongodb pour restreindre l'accès au niveau de la base de données/du serveur. (http://docs.mongodb.org/manual/core/authorization/)
Je recommanderais la 1ère option lorsque :
- Vous disposez de suffisamment de temps et de ressources pour faire face à la complexité de la conception, de la mise en œuvre et des tests de ce scénario.
- Si vous n'allez pas avoir beaucoup de différences de structure et de fonctionnalité dans la base de données pour différents locataires.
- La conception de votre application permettra aux locataires de n'effectuer que des personnalisations minimales lors de l'exécution.
- Si vous souhaitez optimiser l'espace et minimiser l'utilisation des ressources matérielles.
- Si vous allez avoir des milliers de locataires.
- Si vous souhaitez évoluer rapidement et à moindre coût
- Si vous n'allez PAS sauvegarder les données en fonction des locataires (conservez des sauvegardes séparées pour chaque locataire). Il est possible de le faire même dans ce scénario, mais l'effort sera énorme.
J'opterais pour la variante 3 si :
- Vous allez avoir une petite liste de locataires (plusieurs centaines).
- Les spécificités de l'entreprise exigent que vous soyez en mesure de prendre en charge de grandes différences dans la structure de la base de données pour différents locataires (par exemple, l'intégration avec des systèmes tiers, l'import-export de données).
- La conception de votre application permettra aux clients (locataires) d'apporter des modifications importantes à l'exécution de l'application (ajout de modules, personnalisation des champs, etc.).
- Si vous disposez de suffisamment de ressources pour évoluer rapidement avec de nouveaux nœuds matériels
- Si vous êtes tenu de conserver des versions/sauvegardes de données par locataire. De plus, la restauration sera facile.
- Il existe des restrictions légales/réglementaires qui vous obligent à conserver différents locataires dans différentes bases de données (même des centres de données).
- Si vous souhaitez utiliser pleinement les fonctionnalités de sécurité prêtes à l'emploi de mongodb telles que les rôles.
- Il existe de grandes différences de taille entre les locataires (vous avez beaucoup de petits locataires et peu de très gros locataires).
Si vous publiez des détails supplémentaires sur votre candidature, je pourrai peut-être vous donner des conseils plus détaillés.
