Comment créer une base de données multi-tenant avec des structures de table partagées?

Notre logiciel fonctionne actuellement sur MySQL. Les données de tous les locataires sont stockées dans le même schéma. Puisque nous utilisons Ruby on Rails, nous pouvons facilement déterminer quelles données appartiennent à quel locataire. Cependant, certaines entreprises craignent bien sûr que leurs données ne soient compromises, nous évaluons donc d'autres solutions.

Jusqu'à présent, j'ai vu trois options:

• Multi-Database (chaque locataire a le sien - presque la même chose qu'un serveur par client)
• Multi-Schema (non disponible dans MySQL, chaque locataire obtient son propre schéma dans une base de données partagée)
• Schéma partagé (notre approche actuelle, peut-être avec un enregistrement d'identification supplémentaire sur chaque colonne)

Multi-Schema est mon préféré (compte tenu des coûts). Cependant, créer un nouveau compte et effectuer des migrations semble être assez pénible, car je devrais parcourir tous les schémas et modifier leurs tables / colonnes / définitions.

Q: Multi-Schema semble être conçu pour avoir des tables légèrement différentes pour chaque locataire - je ne veux pas de cela. Existe-t-il un SGBDR qui me permet d'utiliser une solution multi-tenant multi-schémas, où la structure de la table est partagée entre tous les locataires?

PS Par multi, je veux dire quelque chose comme ultra-multi (plus de 10 000 locataires).

Cependant, certaines entreprises craignent bien sûr que leurs données ne soient compromises, nous évaluons donc d'autres solutions.

C'est malheureux, car les clients souffrent parfois d'une idée fausse selon laquelle seul l'isolement physique peut offrir une sécurité suffisante.

Il existe un article MSDN intéressant, intitulé Architecture de données multi-locataires , que vous voudrez peut-être vérifier. C'est ainsi que les auteurs ont abordé l'idée fausse de l'approche partagée:

Une idée fausse courante veut que seul l'isolement physique peut fournir un niveau de sécurité approprié. En fait, les données stockées à l'aide d'une approche partagée peuvent également fournir une forte sécurité des données, mais nécessitent l'utilisation de modèles de conception plus sophistiqués.

En ce qui concerne les considérations techniques et commerciales, l'article fait une brève analyse des cas où une certaine approche pourrait être plus appropriée qu'une autre:

Le nombre, la nature et les besoins des locataires que vous prévoyez de servir ont tous une incidence sur votre décision d'architecture de données de différentes manières. Certaines des questions suivantes peuvent vous orienter vers une approche plus isolée, tandis que d'autres peuvent vous orienter vers une approche plus partagée.

• Combien de locataires potentiels prévoyez-vous cibler? Vous êtes peut-être loin de pouvoir estimer l'utilisation potentielle avec autorité, mais pensez en termes d'ordres de grandeur: construisez-vous une application pour des centaines de locataires? Milliers? Des dizaines de milliers? Plus? Plus vous vous attendez à ce que votre base de locataires soit grande, plus vous souhaiterez probablement envisager une approche plus partagée.

• Combien d'espace de stockage pensez-vous que les données du locataire moyen occuperont? Si vous prévoyez que certains ou tous les locataires stockent de très grandes quantités de données, l'approche de base de données séparée est probablement la meilleure. (En effet, les exigences de stockage des données peuvent vous forcer à adopter de toute façon un modèle de base de données distincte. Si tel est le cas, il sera beaucoup plus facile de concevoir l'application de cette façon dès le début que de passer à une approche de base de données distincte plus tard.)

• Combien d'utilisateurs finaux simultanés pensez-vous que le locataire moyen prendra en charge? Plus le nombre est élevé, plus une approche plus isolée sera appropriée pour répondre aux besoins des utilisateurs finaux.

• Pensez-vous offrir des services à valeur ajoutée par locataire, tels que la sauvegarde et la restauration par locataire? Ces services sont plus faciles à offrir grâce à une approche plus isolée.

MISE À JOUR: Suite à la mise à jour sur le nombre prévu de locataires.

Ce nombre attendu de locataires (10 000) devrait exclure l'approche multi-bases de données, pour la plupart, sinon pour tous les scénarios. Je ne pense pas que vous aimerez l'idée de maintenir 10 000 instances de base de données et de devoir en créer des centaines de nouvelles chaque jour.

À partir de ce seul paramètre, il semble que l'approche de base de données partagée à schéma unique est la plus appropriée. Le fait que vous stockerez environ 50 Mo par locataire et qu'il n'y aura pas de modules complémentaires par locataire rend cette approche encore plus appropriée.

L'article MSDN cité ci-dessus mentionne trois modèles de sécurité qui abordent les considérations de sécurité pour l'approche de base de données partagée:

• Connexions de base de données fiables
• Filtre d'affichage des locataires
• Chiffrement des données des locataires

Lorsque vous êtes sûr des mesures de sécurité des données de votre application, vous serez en mesure d'offrir à vos clients un accord de niveau de service qui offre de solides garanties de sécurité des données. Dans votre SLA, outre les garanties, vous pouvez également décrire les mesures que vous prendriez pour garantir que les données ne sont pas compromises.

MISE À JOUR 2: Apparemment, les gars de Microsoft ont déplacé / fait un nouvel article sur ce sujet, le lien d'origine a disparu et c'est le nouveau: Modèles de location de bases de données SaaS multi-locataires (félicitations à Shai Kerer)

Mon expérience (bien que SQL Server) est que la multi-base de données est la voie à suivre, où chaque client a sa propre base de données. Donc, même si je n'ai aucune expérience mySQL ou Ruby On Rails, j'espère que mes commentaires pourront ajouter de la valeur.

Les raisons pour lesquelles comprennent:

1. sécurité des données / reprise après sinistre. Les données de chaque entreprise sont stockées entièrement séparément des autres, ce qui réduit le risque de compromission des données (penser à des choses comme si vous introduisez un bogue de code qui signifie que quelque chose regarde par erreur d'autres données client alors qu'il ne le devrait pas), minimise la perte potentielle pour un client si un une base de données particulière est corrompue, etc. Les avantages de sécurité perçus pour le client sont encore plus importants (effet secondaire supplémentaire!)
2. évolutivité. Essentiellement, vous partitionnez vos données pour permettre une plus grande évolutivité - par exemple, les bases de données peuvent être placées sur différents disques, vous pouvez mettre plusieurs serveurs de bases de données en ligne et déplacer les bases de données plus facilement pour répartir la charge.
3. l'optimisation des performances. Supposons que vous ayez un très gros client et un très petit. Les modèles d'utilisation, les volumes de données, etc. peuvent varier énormément. Vous pouvez régler / optimiser plus facilement pour chaque client si vous en avez besoin.

J'espère que cela offre une contribution utile! Il y a plus de raisons, mais mon esprit est devenu vide. Si ça revient, je vais mettre à jour :)

EDIT:
Depuis que j'ai publié cette réponse, il est maintenant clair que nous parlons de plus de 10000 locataires. Mon expérience porte sur des centaines de bases de données à grande échelle - je ne pense pas que 10 000 bases de données distinctes seront trop gérables pour votre scénario, je ne suis donc pas en faveur de l'approche multi-db pour votre scénario. D'autant qu'il est maintenant clair que vous parlez de petits volumes de données pour chaque locataire!

Garder ma réponse ici car elle peut avoir une certaine utilité pour d'autres personnes dans un bateau similaire (avec moins de locataires)

Vous trouverez ci-dessous un lien vers un livre blanc sur Salesforce.com sur la manière dont ils mettent en œuvre la multi-location:

http://www.developerforce.com/media/ForcedotcomBookLibrary/Force.com_Multitenancy_WP_101508.pdf

Ils ont 1 énorme table avec 500 colonnes de chaînes (Value0, Value1, ... Value500). Les dates et les nombres sont stockés sous forme de chaînes dans un format tel qu'ils peuvent être convertis dans leurs types natifs au niveau de la base de données. Il existe des tables de métadonnées qui définissent la forme du modèle de données qui peut être unique par locataire. Il existe des tables supplémentaires pour l'indexation, les relations, les valeurs uniques, etc.

Pourquoi les tracas?

Chaque locataire peut personnaliser son propre schéma de données au moment de l'exécution sans avoir à apporter de modifications au niveau de la base de données (modifier la table, etc.). C'est certainement le moyen le plus difficile de faire quelque chose comme ça, mais c'est très flexible.

Comme vous le mentionnez, une base de données par locataire est une option et comporte des compromis plus importants. Il peut bien fonctionner à une plus petite échelle, comme un seul chiffre ou des dizaines de locataires, mais au-delà, il devient plus difficile à gérer. À la fois juste pour les migrations, mais aussi simplement pour maintenir les bases de données opérationnelles.

Le modèle par schéma n'est pas seulement utile pour les schémas uniques pour chacun, bien que l'exécution de migrations sur tous les locataires devienne difficile et à des milliers de schémas, Postgres peut commencer à avoir des problèmes.

Une approche plus évolutive consiste à avoir des locataires distribués de manière aléatoire, stockés dans la même base de données, mais sur différents fragments logiques (ou tables ). En fonction de votre langue, il existe un certain nombre de bibliothèques qui peuvent vous aider. Si vous utilisez Rails, il existe une bibliothèque pour activer la location acts_as_tenant, cela permet de garantir que vos requêtes de client ne récupèrent que ces données. Il y a aussi un joyau apartment- bien qu'il utilise le modèle de schéma, il facilite les migrations entre tous les schémas. Si vous utilisez Django, il y en a un certain nombre, mais l'un des plus populaires semble être dans les schémas . Tous ces éléments aident davantage au niveau de l'application. Si vous recherchez quelque chose de plus au niveau de la base de données directement, l' Citus se concentre sur la création de ce type de partitionnement pourla multi-location fonctionne plus directement avec Postgres.