Comment créer une base de données multi-locataires 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 sur Rails, nous pouvons facilement déterminer quelles données appartiennent à quel locataire. Cependant, certaines entreprises craignent que leurs données ne soient compromis, nous évaluons donc d’autres solutions.
Jusqu'à présent, j'ai vu trois options:
- Multi-base de données (chaque locataire obtient le sien - à peu près le même 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, avec éventuellement 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-locataires multi-schémas, dans laquelle la structure de la table est partagée entre tous les locataires?
P.S. Par multi, je veux dire quelque chose comme ultra-multi (plus de 10 000 locataires).
Cependant, certaines entreprises craignant que leurs données ne soient compromises, nous évaluons d’autres solutions.
Cela est regrettable, car les clients souffrent parfois d’une idée fausse selon laquelle seul l’isolation physique peut offrir une sécurité suffisante.
Il existe un article intéressant sur MSDN, intitulé Multi-Tenant Data Architecture , que vous pouvez vérifier. Voici comment les auteurs ont abordé l’idée fausse vers une approche partagée:
Une idée fausse commune est que seul l'isolation physique peut fournir un niveau de sécurité approprié. En fait, les données stockées en utilisant une approche partagée peuvent également offrir une sécurité élevée 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 analyse brièvement où une approche peut être plus appropriée qu’une autre:
Le nombre, la nature et les besoins des locataires que vous comptez desservir affectent tous 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 n’êtes peut-être pas en mesure d’estimer l’utilisation potentielle potentielle avec autorité, mais pensez en termes d’ordre de grandeur: créez-vous une application pour des centaines de locataires? Milliers? Des dizaines de milliers? Plus? Plus votre base de locataires sera grande, plus vous voudrez probablement envisager une approche plus partagée.
Combien d'espace de stockage pensez-vous que les données du locataire moyen vont occuper? Si vous vous attendez à ce que certains ou tous les locataires stockent de très grandes quantités de données, l'approche par base de données séparée est probablement la meilleure. (En effet, les exigences en matière de stockage des données peuvent vous obliger de toute façon à adopter un modèle de base de données distinct. Si c'est le cas, il sera beaucoup plus facile de concevoir l'application de cette façon dès le début que de passer ultérieurement à une approche de base de données séparée.)
Combien d'utilisateurs finaux simultanés pensez-vous que le locataire moyen prendra en charge? Plus le nombre est élevé, plus une approche isolée sera appropriée pour répondre aux besoins de l'utilisateur final.
Vous attendez-vous à proposer des services à valeur ajoutée par locataire, tels que des fonctions de sauvegarde et de restauration par locataire? Ces services sont plus faciles à offrir grâce à une approche plus isolée.
UPDATE: Suite à la mise à jour du nombre de locataires prévu.
Le nombre prévu de locataires (10k) devrait exclure l'approche multi-bases de données, pour la plupart des scénarios, voire tous. Je ne pense pas que vous ayez envie de gérer 10 000 instances de base de données et de devoir en créer des centaines chaque jour.
À partir de ce seul paramètre, il semble que l'approche de la base de données partagée, à schéma unique soit la plus appropriée. Le fait que vous stockez à peu près 50 Mo par locataire et qu'il n'y aura pas d'ajouts par locataire rend cette approche encore plus appropriée.
L'article MSDN cité ci-dessus mentionne trois modèles de sécurité qui abordent des considérations de sécurité pour l'approche de base de données partagée:
- Connexions sécurisées à la base de données
- Filtre de vue de locataire
- cryptage des données du locataire
Lorsque vous maîtriserez les mesures de sécurité des données de votre application, vous pourrez offrir à vos clients un Service Level Agrement offrant de solides garanties en matière de sécurité des données. Dans votre contrat de niveau de service, outre les garanties, vous pouvez également décrire les mesures que vous prendriez pour vous assurer que les données ne sont pas compromises.
UPDATE 2: Apparemment, les gars de Microsoft ont déplacé/fait un nouvel article sur ce sujet, le lien d'origine a disparu et il s'agit du nouveau: Multi-tenant SaaS (bravo à Shai Kerer)
Vous trouverez ci-dessous un lien vers un livre blanc sur Salesforce.com sur la manière dont ils mettent en œuvre la colocation multiple:
http://www.developerforce.com/media/ForcedotcomBookLibrary/Force.com_Multitenancy_WP_101508.pdf
Ils ont 1 table énorme avec 500 colonnes de chaîne (Value0, Value1, ... Value500). Les dates et les nombres sont stockés sous forme de chaînes dans un format permettant de les convertir en 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 ces tracas?
Chaque client hébergé 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 (alter table, etc.). C'est certainement le moyen difficile de faire quelque chose comme ça, mais c'est très flexible.
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, bien que je n’ai pas d’expérience mySQL ou Ruby on Rails), j’espère que mes commentaires apporteront une valeur ajoutée.
Les raisons pour lesquelles comprennent:
- 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, par exemple, si vous introduisez un bogue de code qui signifie que quelque chose regarde par erreur les données d'un autre client alors qu'il ne devrait pas l'être), minimise la perte potentielle d'un client. Une base de données particulière est corrompue, etc. Les avantages de sécurité perçus par le client sont encore plus importants (effet secondaire de bonus ajouté!)
- l'évolutivité. Essentiellement, vous partitionneriez vos données pour permettre une plus grande évolutivité, par exemple. Les bases de données peuvent être mises sur différents disques, vous pouvez mettre en ligne plusieurs serveurs de base de données et déplacer les bases de données plus facilement pour répartir la charge.
- 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 chaque client si vous en avez besoin.
J'espère que cela offre des informations utiles! Il y a plus de raisons, mais mon esprit est devenu vide. Si cela se produit, je mettrai à jour :)
EDIT:
Depuis que j'ai posté cette réponse, il est maintenant clair que nous parlons de plus de 10 000 locataires. Mon expérience concerne des centaines de bases de données à grande échelle. Je ne pense pas que 10 000 bases de données distinctes soient trop gérables pour votre scénario. Je ne privilégie donc pas l'approche multi-base de données pour votre scénario. Surtout qu'il est maintenant clair que vous parlez de petits volumes de données pour chaque locataire!
Garder ma réponse ici de toute façon car cela pourrait avoir une utilité pour d'autres personnes dans un bateau similaire (avec moins de locataires)
Comme vous le mentionnez, une base de données par locataire est une option et comporte des compromis plus importants. Cela peut fonctionner à petite échelle, par exemple un locataire à un chiffre ou moins de 10 locataires, mais au-delà, il devient plus difficile à gérer. À la fois les migrations mais aussi pour garder 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 les migrations en cours sur tous les locataires deviennent difficiles et que des milliers de schémas commencent à poser problème.
Une approche plus évolutive consiste à faire en sorte que les locataires soient répartis de manière aléatoire, stockés dans la même base de données, mais à travers différents fragments logiques (ou tables ). Selon votre langue, plusieurs bibliothèques peuvent vous aider. Si vous utilisez Rails, il existe une bibliothèque pour appliquer la location acts_as_tenant , cela permet de s’assurer que vos requêtes de locataire ne récupèrent que ces données. Il existe également une gemme apartment - bien qu’elle utilise le modèle de schéma, elle facilite les migrations entre tous les schémas. Si vous utilisez Django, il y en a un nombre, mais l'un des plus populaires semble être schémas . Tous ces éléments sont plus utiles au niveau de l'application. cherchez quelque chose de plus directement au niveau de la base de données, Citus se concentre sur la fabrication de ce type de sharding pour multi-tenant fonctionne mieux avec Postgres.