Nous avions exactement cette question il y a quelques mois dans un produit qui est souvent utilisé par des organisations qui, à leur tour, servent plusieurs clients. Ils sont venus nous demander de modifier notre système SaaS afin qu'ils puissent créer des sites Web complets et discrets pour chacun de leurs clients (nous construisons un outil de construction de site Web en ligne spécifique à un domaine).
Un bref résumé: il peut sembler évident de mettre tout le monde sur une seule base de données, mais vous constaterez que ce n'est pas toujours évident. Il y a quelques défis que vous voudrez garder à l'esprit au fur et à mesure que vous progresserez. Quelques points:
D'abord, il ne suffit pas d'ajouter simplement "Company_id" à quelques tables. En effet, malgré les commentaires de Sai sur le fait qu'il est ridicule d'avoir une base de données/application pour chaque entreprise, il y a des cas où cela est logique en raison de la complexité inhérente à l'hébergement de systèmes SaaS pour plusieurs clients discrets. Si vous êtes simplement servant quelques sociétés différentes (par exemple créer des factures pour eux) alors le commentaire de Sai est tout à fait vrai. Cependant, si vous fournissez une application logicielle à plusieurs organisations, la complexité est un peu plus élevée et les bases de données discrètes peuvent être en ordre. Ensuite, préparez-vous à un effort d'interrogation et de création de rapports beaucoup plus complexe pour les utilisateurs dans une base de données multi-clients. Par exemple, lors de la création de nos capacités d'interrogation des utilisateurs, nous devions être absolument certains qu'il n'y aurait pas de "fond perdu" entre les organisations car il y avait des données protégées par HIPAA. Cela signifiait que les capacités d'interrogation et de génération de rapports exigeaient un niveau d'ingénierie bien supérieur à ce qui s'était passé auparavant.Dans notre cas, nos capacités d'interrogation étaient très flexibles et permettaient essentiellement aux utilisateurs de construire des requêtes à la volée (sous réserve de contraintes assez rigoureuses, évidemment - nous n'acceptons pas SQL!). Ainsi, nous devions nous assurer que chaque requête était automatiquement modifiée pour utiliser la contrainte "Company_ID", selon le cas, quelle que soit l'origine des données ou les permissions du membre de l'équipe soumettant la requête. La ride? Notre compte d'analyse 'super-utilisateur' devait être capable d'exécuter les requêtes sans une telle contrainte ...
Troisièmement, vous n'avez probablement pas encore anticipé le nombre de choses à séparer. Par exemple, j'avais construit un objet "Settings" assez sophistiqué dans le site qui tirait les paramètres de la base de données au démarrage et les maintenait dans l'objet "Application" (il s'agit d'une application .NET). Tout cela devait être flotté pour gérer plusieurs organisations.
Pour un autre exemple, les champs utilisés pour être unique pour nous (par exemple les connexions) ont maintenant à faire dans le cadre d'une clé Company_id, LoginID. Si vous construisez à partir de zéro, ce n'est pas une si grande idée, mais nous étions en train de rééquiper.
Quoi qu'il en soit, au fur et à mesure que je progressais dans la construction, j'ai été surpris de découvrir à quel point le travail était nécessaire pour bien faire. Quatrièmement, je construis toujours des logiciels en utilisant une approche de «méta-programmation». En d'autres termes, je construis rarement une page à usage unique, mais je construis souvent un framework hautement personnalisable afin de faciliter la personnalisation de l'utilisateur final et la réutilisation du code interne. Même si je prévoyais que cela faciliterait la transition vers des bases de données multi-organisations, cela n'a souvent pas été le cas! Parce qu'un tel codage est souvent assez complexe au départ, il était souvent plus difficile de faire flotter l'organisation que si j'avais simplement une page Web vanillée.
Enfin, s'il n'y a pas besoin criant de partager des données (par exemple l'analyse des modèles d'utilisation globale), vous pouvez coller simplement avec des bases de données distinctes pour faciliter l'échelle. Alors que vous ajoutez de nouvelles bases de données multi-org (un second système discret), notre mise à l'échelle impliquait souvent clients existants qui subissaient soudainement une augmentation de leur croissance. Les supprimer d'une base de données existante et sur un nouveau serveur est un peu plus difficile que de simplement passer à un nouveau serveur avec une base de données existante. Avec toutes ces mises en garde, vous pourriez penser que je vous déconseille de construire un système capable de gérer plusieurs organisations sur une seule base de données. Cependant, ce n'est pas le cas: il y a de vraies victoires en adoptant une approche multi-org. L'analyse de l'utilisation, le reporting inter-organisationnel, le déploiement des applications, etc. sont tous significativement améliorés. Je veux simplement vous faire profiter de notre expérience dans l'espoir que cela vous aidera à anticiper certaines des difficultés que vous pouvez anticiper. Lorsque vous exécutez un logiciel en tant que service, il y a toujours quelques éléments à prendre en compte lors du choix d'une stratégie de base de données:
Non, je ne cherche pas à exposer la base de données directement. Mon souci était juste la performance à long terme. Et oui, il semble maintenant stupide de répliquer les DB - tout changement dans le schéma, les sauvegardes seraient horribles. –
Cela dépend entièrement de la quantité de données par entreprise dont nous parlons.Dans un cas général, company_id peut bien fonctionner, bien que si vous êtes, disons, Salesforce, il n'y a pas d'architecture maître/esclave qui puisse vous retenir, et vous avez quand même besoin d'une mise à l'échelle horizontale (1 DB par entreprise)). Si vous êtes sur Facebook, vous créez une nouvelle instance MySQL par université, ce qui vous permet d'effectuer une mise à l'échelle dès le départ, même si elle introduit des casse-têtes de requêtes cross-db. – SquareCog
En fait, je ne suis pas sûr de Salesforce. Étant donné sa lenteur, il se peut qu'il fonctionne sur une seule instance Oracle RAC géante et tente de brûler les données de tout le monde lors de la génération de vos rapports :-). – SquareCog