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

Je pense créer une application multi-locataire à l'aide de MongoDB. Je n'ai aucune estimation du nombre de locataires que j'aurais encore, mais j'aimerais pouvoir passer à des milliers.

Je peux penser à trois stratégies:

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

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

Pensées et implications, quelqu'un?

J'ai le même problème à résoudre et je considère é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 (il y a eu un retour 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é éviter à tout prix les 2e options, ce qui, d'après ce que je comprends, n'est pas particulièrement spécifique à mongodb. J'ai l'impression 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 buckets 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 le SGBDR bien qu'ils se comportent comme des conteneurs pour des 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 des 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 / 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 gérer 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 au moment de l'exécution.
• Si vous souhaitez optimiser l'espace et minimiser l'utilisation des ressources matérielles.
• Si vous comptez avoir des milliers de locataires.
• Si vous souhaitez évoluer rapidement et à bon prix.
• Si vous n'allez PAS sauvegarder les données en fonction des locataires (conservez des sauvegardes distinctes pour chaque locataire). Il est possible de le faire même dans ce scénario, mais l'effort sera énorme.

J'irais pour la variante 3 si:

• Vous allez avoir une petite liste de locataires (plusieurs centaines).
• Les spécificités de l'entreprise vous obligent à être en mesure de supporter de grandes différences dans la structure de la base de données pour différents locataires (par exemple intégration avec des systèmes tiers, import-export de données).
• La conception de votre application permettra aux clients (locataires) d'apporter des modifications significatives au runtime 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 devez 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 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 pourrais peut-être vous donner des conseils plus détaillés.

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/

Fondamentalement, l'option n ° 2 semble être la meilleure voie à suivre.

Citation du commentaire de David Mytton:

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

Le premier fichier pour 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 une taille de 2 Go, chaque fichier successif fait également 2 Go.

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

du manuel.

Au fur et à mesure que les utilisateurs s'inscrivent à l'essai et essaient les choses, nous obtenons de plus en plus de bases de données d'au moins 2 Go, même si l'ensemble du fichier de données n'est pas utilisé. Nous avons constaté que cela utilisait une quantité énorme d'espace disque par rapport au fait d'avoir plusieurs bases de données pour tous les clients où l'espace disque peut être utilisé avec une efficacité maximale.

Le sharding sera sur une base par collection en standard, ce qui pose un problème où la collection n'atteint jamais la taille minimum pour commencer le sharding, comme c'est le cas pour bon nombre d'entre nous (par exemple, les collections ne stockant que les informations de connexion des utilisateurs). Cependant, nous avons demandé que cela puisse également être fait au niveau de chaque base de données. Voir http://jira.mongodb.org/browse/SHARDING-41

Il n'y a pas de compromis sur les performances en utilisant de nombreuses collections. Voir http://www.mongodb.org/display/DOCS/Using+a+Large+Number+of+Collections

Il existe un article raisonnable sur MSDN sur l'architecture de données multi-locataires auquel vous voudrez peut-être vous référer. Quelques sujets clés abordés dans cet article:

• Considérations économiques
• Sécurité
• Considérations relatives aux locataires
• Réglementaire (juridique)
• Problèmes liés à l'ensemble de compétences

Certains modèles de configuration Software as a Service (SaaS) sont également abordés.

De plus, ça vaut le coup d'oeil est un article intéressant des gars de SQL Anywhere .

Ma propre opinion personnelle - à moins que vous ne soyez certain de la sécurité / confiance imposées, j'irais avec l'option 3, ou si les problèmes d'évolutivité interdisent au minimum le retour à l'option 2. Cela dit ... je ne suis pas un pro avec MongoDB. Je deviens assez nerveux en utilisant un "schéma" partagé - mais je m'en remettrai volontiers à des pratiquants plus expérimentés.

J'irais pour l'option 2.

Cependant, vous pouvez définir l'option de ligne de commande mongod.exe --smallfiles. Cela signifie que la plus grande taille de fichier d'une extension 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.

D'après mes recherches dans MongoDB. Trucos y consejos. Aplicaciones 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, imaginez aussi avoir des milliers de collections dans une seule base de données ... Donc dans votre cas ça Il est recommandé d'utiliser la première option. Maintenant, si vous allez avoir un nombre limité d'utilisateurs, c'est déjà différent et oui, vous pouvez utiliser l'option deux comme vous le pensiez.

Bien que la discussion ici porte sur NoSQL et principalement MongoDB, chez Citus , nous utilisons PostgreSQL et créons une base de données multi-locataires distribuée / partagée.

Notre guide de cas d'utilisation parcourt un exemple d'application, couvrant le schéma et diverses fonctionnalités spécifiques à plusieurs locataires.

Pour des données plus non structurées, nous utilisons la colonne JSONB de PostgreSQL pour stocker ces données spécifiques aux locataires.