Ce n'est pas une réponse facile, car cela dépend beaucoup de l'architecture de votre application, des modèles d'utilisation et de requête, de la répartition entre les clients (c'est-à-dire :les niveaux d'utilisation seront-ils à peu près les mêmes pour tous les clients, ou pourriez-vous avoir 10 % des clients utilisant 90 % du ressources), combien vous pouvez dépenser pour le code par rapport à la gestion des opérations et toute une série d'autres problèmes. Voici quelques éléments à prendre en compte :
1) Avoir une base de données facilitera la gestion de vos opérations, nécessitera moins de ressources informatiques et peut vous permettre de mieux évoluer, mais coder la couche d'accès sera plus difficile et vous devrez vraiment bien concevoir votre couche de sécurité pour des raisons évidentes. Vous consommerez également moins de ressources côté client/serveur Web puisqu'il y aura beaucoup moins de connexions.
Il existe deux options de schéma populaires lorsqu'on aborde une base de données monolithique :
- Vous pouvez mettre toutes les données similaires dans une seule collection (c'est-à-dire :les profils de tous les comptes vont dans la même collection) et donner à chaque document une clé ID client pour identifier quelles données appartiennent à quel compte. Cela peut vous fournir les meilleures options (en fonction de l'architecture de votre schéma) pour évoluer avec le moins de ressources informatiques.
- Une autre option consiste à séparer les données client par collections - chaque client aura ses propres collections dans la base de données identifiée par un préfixe clientid (c'est-à-dire :clientid_userprofiles).
2) l'option base de données par client vous donnera plus de maux de tête pour la gestion des opérations et coûtera plus cher car vous aurez besoin de plus de ressources informatiques. D'un autre côté, vos coûts de codage devraient être moindres car le code sera plus facile à écrire. Cela vous permettra également de mieux répartir vos ressources entre gros et petits utilisateurs. Par exemple, vous pouvez déplacer les clients à utilisation intensive vers des machines plus puissantes et fournir un partitionnement par client.
3) vous pouvez fournir une combinaison des deux options - des bases de données dédiées pour les utilisateurs haut de gamme (comptes qui paient plus), puis une base de données partagée avec des données séparées par collecte pour les clients bas de gamme et les comptes test/freemium.
Notez que si vous utilisez la route de plusieurs bases de données, vous devriez regarder dans l'option de démarrage --smallfiles. Cela vous aidera dans les situations où de nombreuses personnes configurent des "comptes de test" mais qui n'en font pas grand-chose.
Quoi qu'il en soit, j'espère que ce qui précède vous donne matière à réflexion. Faites une recherche sur https://groups.google.com /forum/?fromgroups#!searchin/mongodb-user/multitenant car il y a eu un certain nombre de discussions dans les forums Mongo sur cette question spécifique.
En ce qui concerne les implications de l'audit, cela dépend du niveau de conformité d'audit auquel vous devez vous conformer. Si vous vous attendez à des clients Fortune 1000, vos exigences de conformité seront beaucoup plus élevées (et beaucoup plus coûteuses - pensez à 10 $ à 100 $ de milliers de dollars), que si vos clients sont des startups qui n'ont peut-être jamais entendu parler de SAS70, etc. La réponse dépend également du type de données que vous stockez - s'agit-il de données financières d'utilisateurs ou s'agit-il simplement de forums d'utilisateurs ? Fondamentalement, si vous craignez de devoir passer des audits de sécurité pour les grandes entreprises à l'avenir, ne pensez même pas à l'approche de la base de données partagée.
