Quelle est l'approche recommandée pour les bases de données multi-tenant dans MongoDB ?

Question

J'envisage de créer une application multi-tenant en utilisant MongoDB. Je ne sais pas encore combien de locataires j'aurai, mais j'aimerais pouvoir m'étendre à des milliers de personnes.

Je peux penser à trois stratégies :

1. Tous les locataires dans la même collection, en utilisant des champs spécifiques aux locataires pour la sécurité.
2. 1 Collection par locataire dans une seule BD partagée
3. 1 base de données par locataire

La voix dans ma tête me suggère de choisir l'option 2.

Réflexions et implications, quelqu'un ?

Answer 1

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-tenant, j'allais également choisir la deuxième option sur la base de mon expérience antérieure avec les bases de données relationnelles.

En faisant mes recherches, j'ai trouvé cet article sur le site de support de mongodb (il a été ajouté il y a longtemps car il a disparu) : 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 la deuxième option, ce qui, d'après ce que j'ai compris, n'est pas particulièrement spécifique à mongodb. J'ai l'impression que cela s'applique à la plupart des bases de données NoSQL sur lesquelles j'ai fait des recherches (CoachDB, Cassandra, CouchBase Server, etc.) en raison des spécificités de leur conception.

Les collections (ou les seaux ou tout autre nom utilisé dans les différentes bases de données) ne sont pas la même chose que les schémas de sécurité dans les SGBDR. Bien qu'elles se comportent comme des conteneurs pour les documents, elles sont inutiles pour appliquer une bonne séparation des locataires. Je n'ai pas trouvé de base de données NoSQL qui puisse 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 de mongodb pour restreindre l'accès au niveau de la base de données ou du serveur. ( http://docs.mongodb.org/manual/core/authorization/ )

Je recommande la première option quand :

• 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 dans la structure et la fonctionnalités de la base de données pour les différents locataires.
• La conception de votre application doit permettre aux locataires de n'effectuer que des personnalisations minimales au moment de l'exécution.
• Si vous voulez optimiser l'espace et minimiser l'utilisation du matériel ressources matérielles.
• Si vous avez des milliers de locataires.
• Si vous voulez changer d'échelle rapidement et à bon prix.
• Si vous n'avez PAS l'intention de sauvegarder les données en fonction des locataires (gardez des données séparées sauvegardes distinctes pour chaque locataire). Il est possible de le faire même dans ce scénario mais l'effort sera énorme.

Je choisirais la variante 3 si :

• Vous allez avoir une petite liste de locataires (plusieurs centaines).
• Les spécificités de l'entreprise exigent que vous puissiez 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 au cours de son exécution (ajout de modules, personnalisation des champs, etc.).
• Si vous disposez de suffisamment de ressources pour évoluer rapidement vers de nouveaux nœuds matériels.
• Si vous êtes tenu de conserver des versions/sauvegardes des données par locataire. La restauration sera également facile.
• Il existe des restrictions légales/réglementaires qui vous obligent à conserver des locataires différents dans des bases de données différentes (voire des centres de données).
• Si vous souhaitez utiliser pleinement les fonctions de sécurité prêtes à l'emploi de mongodb, telles que les rôles.
• Il existe de grandes différences en termes de taille entre les locataires (vous avez beaucoup de petits locataires et peu de très grands locataires).

Si vous postez des détails supplémentaires sur votre demande, je pourrai peut-être vous donner des conseils plus détaillés.

Answer 2

J'ai trouvé une bonne réponse dans les commentaires de ce lien :

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

En fait, l'option n° 2 semble être la meilleure solution.

Citation du commentaire de David Mytton :

Nous avons décidé de ne pas avoir une base de données par client en raison de la manière dont MongoDB alloue ses fichiers de données. Chaque base de données base de données utilise son propre ensemble de fichiers :

Le premier fichier d'une base de données est dbname.0, puis dbname.1, etc. dbname.0 sera de 64 Mo, dbname.1 de 128 Mo, etc. jusqu'à 2 Go. Une fois que les fichiers atteignent 2GB 2GB, chaque fichier successif est également 2 GO.

Ainsi, si le dernier fichier de données présent est disons, 1GB, ce fichier pourrait être vide à 90%. s'il a été atteint récemment.

du manuel.

Lorsque les utilisateurs s'inscrivent à l'essai et donnent les choses, nous aurions de plus en plus de bases de données d'au moins 2 Go, même même si l'ensemble du fichier de données n'était pas utilisé. Nous avons constaté que cela utilisait une quantité massive d'espace disque par rapport d'avoir plusieurs bases de données pour tous les clients où l'espace disque peut être être utilisé de manière optimale.

Le partage se fera par collection par collection, ce qui pose un problème problème où la collection n'atteint jamais n'atteint jamais la taille minimale pour commencer le partage, comme c'est le cas pour plusieurs de nos quelques-unes des nôtres (par exemple, les collections qui ne les détails de connexion des utilisateurs). Cependant, nous avons demandé que cela puisse également être fait au niveau de chaque base de données base de données. Voir http://jira.mongodb.org/browse/SHARDING-41

Il n'y a pas de compromis sur les performances en utilisant beaucoup de collections. Voir http://www.mongodb.org/display/DOCS/Using+un+grand+nombre+de+collections

Answer 3

Je choisirais l'option 2.

Cependant, vous pouvez définir l'option de ligne de commande de mongod.exe --smallfiles. Cela signifie que la plus grande taille de fichier d'un extent sera de 0,5 gigaoctet et non de 2 gigaoctets. J'ai testé cela avec mongo 1.42 . L'option 3 n'est donc pas impossible.

Answer 4

Il y a un article raisonnable sur MSDN sur l'architecture de données multi-tenant auquel vous pouvez vous référer. Quelques sujets clés abordés par cet article :

• Considérations économiques
• Sécurité
• Considérations relatives aux locataires
• Réglementation (juridique)
• Préoccupations concernant les compétences

Certains modèles de configuration de logiciels en tant que service (SaaS) sont également abordés.

En outre, il convient de jeter un coup d'œil sur un article intéressant des gars de SQL Anywhere .

Mon avis personnel : à moins d'être certain de la sécurité et de la confiance renforcées, je choisirais l'option 3 ou, si des problèmes d'évolutivité l'interdisent, l'option 2 au minimum. Cela dit... Je ne suis pas un pro de MongoDB. L'utilisation d'un "schéma" partagé me rend assez nerveux, mais je m'en remets volontiers aux praticiens plus expérimentés.

Answer 5

D'après mes recherches dans MongoDB. Conseils et astuces. Applications multitenant. Cette option n'est pas recommandée si vous ne savez pas combien de locataires vous pouvez avoir, cela pourrait être des milliers et ce serait compliqué quand il s'agit de sharding, aussi imaginez avoir des milliers de collections dans une seule base de données ... Donc, dans votre cas, il est recommandé d'utiliser l'option 1. Maintenant si vous allez avoir un nombre limité d'utilisateurs, c'est déjà différent et oui, vous pourriez utiliser l'option deux comme vous le pensiez.