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

Question

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

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

• Multi-base de données (chaque locataire a la sienne - presque la même chose que 1 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, la création d'un nouveau compte et les migrations semblent être assez pénibles, car je devrais itérer sur tous les schémas et modifier leurs tables/colonnes/définitions.

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

P.S. Par multi, j'entends quelque chose comme ultra-multi (10.000+ locataires).

Answer 1

Toutefois, il existe des entreprises de craignent que leurs données puissent être être compromises, nous évaluons donc d'autres solutions.

C'est regrettable, car les clients ont parfois l'idée fausse que seule l'isolation physique peut offrir une sécurité suffisante.

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

Une idée fausse courante veut que que seule l'isolation physique peut fournir un niveau de sécurité approprié. En réalité, En fait, les données stockées selon une approche partagée peuvent également assurer une forte sécurité des données, mais nécessite l'utilisation de modèles de conception plus sophistiqués.

En ce qui concerne les considérations techniques et commerciales, l'article présente 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 influencent tous votre décision d'architecture de données de différentes manières. Certaines des questions suivantes questions suivantes peuvent vous inciter à adopter une approche plus isolée, tandis que d'autres vous orienter vers une approche plus partagée partagée.

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

• Combien d'espace de stockage pensez-vous que les données d'un locataire moyen occuperont ? Si vous prévoyez que certains ou tous les locataires stockent de très grandes quantités de données, le base de données séparée est probablement meilleure. (En effet, les exigences en matière de stockage de données données peuvent vous obliger à adopter un modèle de base de données séparée. Dans ce cas, il sera beaucoup plus facile de concevoir l'application l'application de cette façon dès le que de passer à un modèle base de données séparée par la suite).

• Combien d'utilisateurs finaux simultanés le locataire moyen doit-il prendre en charge ? Plus ce nombre est élevé, plus le plus appropriée une approche plus isolée pour répondre aux besoins des utilisateurs finaux.

• Prévoyez-vous d'offrir des services à valeur ajoutée par locataire, tels que comme la sauvegarde et la restauration par locataire par locataire ? De tels services sont plus faciles faciles à offrir par une approche plus isolée.

---

UPDATE : Suite à la mise à jour du nombre attendu de locataires.

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

À partir de ce seul paramètre, il semble que l'approche de la base de données partagée et du schéma unique soit la plus appropriée. Le fait que vous ne stockerez qu'environ 50 Mo par locataire, et qu'il n'y aura pas d'add-ons par locataire, rend cette approche encore plus appropriée.

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

• Connexions de base de données fiables
• Filtre de visualisation des locataires
• Cryptage des données des locataires

Lorsque vous aurez confiance dans les mesures de sécurité des données de votre application, vous serez en mesure d'offrir à vos clients un service de qualité. Accord de niveau de service qui offre de solides garanties en matière de sécurité des données. Dans votre ANS, outre les garanties, vous pouvez également décrire les mesures que vous prendrez pour vous assurer que les données ne sont pas compromises.

UPDATE 2 : Apparemment, les responsables de Microsoft ont déplacé / créé un nouvel article à ce sujet. Le lien original a disparu et voici le nouveau : Modèles de location de bases de données SaaS multi-tenant (félicitations à Shai Kerer)

Answer 2

Vous trouverez ci-dessous un lien vers un livre blanc de Salesforce.com sur la manière dont l'entreprise met en œuvre la multilocation :

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

Ils ont une énorme table avec 500 colonnes de chaînes (Value0, Value1, ... Value500). Les dates et les nombres sont stockés sous forme de chaînes de caractères dans un format tel qu'ils peuvent être convertis 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 et qui peuvent être uniques pour chaque locataire. Il existe des tables supplémentaires pour l'indexation, les relations, les valeurs uniques, etc.

Pourquoi ce tracas ?

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

Answer 3

D'après mon expérience (bien qu'il s'agisse de SQL Server), la solution consiste à utiliser plusieurs bases de données, chaque client disposant de sa propre base de données. Ainsi, bien que je n'aie aucune expérience de mySQL ou de Ruby On Rails, j'espère que ma contribution pourra apporter une certaine valeur ajoutée.

Les raisons en sont les suivantes :

1. sécurité des données/récupération après sinistre. Les données de chaque entreprise sont stockées séparément des autres, ce qui réduit le risque de compromission des données (par exemple, si vous introduisez un bogue dans le code qui fait que quelque chose consulte par erreur les données d'un autre client alors qu'il ne devrait pas le faire), minimise les pertes potentielles pour un client si une base de données particulière est corrompue, etc. Les avantages en matière de sécurité perçus par le client sont encore plus importants (effet secondaire supplémentaire !).
2. l'é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 des disques différents, vous pouvez mettre en ligne plusieurs serveurs de bases de données 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 considérablement. Vous pouvez régler/optimiser plus facilement les performances pour chaque client si nécessaire.

J'espère que ces informations vous seront utiles ! Il y a d'autres raisons, mais j'ai l'esprit vide. Si elle revient, je mettrai à jour :)

EDITAR:
Depuis que j'ai posté cette réponse, il est maintenant clair que nous parlons de plus de 10 000 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 soient trop faciles à gérer pour votre scénario, je ne suis donc pas favorable à l'approche multi-bases de données pour votre scénario. D'autant plus qu'il est maintenant clair que vous parlez de petits volumes de données pour chaque locataire !

Je garde ma réponse ici, car elle pourrait être utile à d'autres personnes dans la même situation (avec moins de locataires).

Answer 4

Comme vous le mentionnez, l'option d'une base de données par locataire est une possibilité, mais elle comporte des inconvénients plus importants. Elle peut fonctionner correctement à petite échelle, par exemple avec un nombre de locataires inférieur à 10, mais au-delà, elle devient plus difficile à gérer. Tant pour les migrations que pour le maintien des bases de données en état de fonctionnement.

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

Une approche plus évolutive consiste à répartir les locataires de manière aléatoire, en les stockant dans la même base de données, mais à travers différents shards logiques (ou tableaux ). 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 qui permet d'anticiper la location. acts_as_tenant cela permet de s'assurer que les requêtes des locataires ne récupèrent que ces données. Il y a aussi une perle apartment - Bien qu'il utilise le modèle de schéma, il facilite les migrations à travers tous les schémas. Si vous utilisez Django, il en existe un certain nombre, mais l'une des plus populaires semble être celle qui passe par schémas . Tous ces éléments sont plus utiles au niveau de l'application. Si vous cherchez quelque chose de plus au niveau de la base de données directement, Citus se concentre sur la mise en place de ce type de sharding pour les entreprises. multi-location fonctionnent mieux avec Postgres.

Answer 5

Un excellent article de Ryan Bigg sur le même sujet. http://ryanbigg.com/2013/01/multitenancy-with-rails/