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

129

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).

Marcel Jackwerth
la source
1
"Multi-Schema semble être conçu pour avoir des tables légèrement différentes pour chaque locataire" Alors? Quel est le problème avec le multi-schéma et toutes les mêmes tables? Voulez-vous dire que vous ne souhaitez pas recréer des structures de table identiques dans tous les schémas? Ou dites-vous que vous ne pouvez pas créer des structures identiques dans tous les schémas?
S.Lott
+1 pour bonne / question intéressante
AdaTheDev
2
@ S.Lott J'attends plus de 10 000 locataires avec plus de 100 inscriptions par jour. Avoir des millions d'entrées dans une seule définition de table (définition = partagé, données = isolé) me fait me sentir mieux que d'avoir des milliers d'entrées dans des milliers de définitions de table. Comme peu de gens le font de cette façon, je ne suis pas aussi à l'aise avec le multi-schéma.
Marcel Jackwerth
1
Je suis d'accord avec Daniel, la multi-base de données est exclue sur la base de ces chiffres. J'ai mis à jour ma réponse pour refléter cela, mais en la gardant davantage pour l'histoire. L'approche partagée semble certainement l'approche la plus raisonnable.
AdaTheDev
2
de dynjo en réponse: " Grand article de Ryan Bigg sur le sujet exact"
Félix Gagnon-Grenier

Réponses:

95

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:

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)

Daniel Vassallo
la source
1
Oh, j'ai scanné cet article hier et j'ai sauté cette partie d'idée fausse. Besoin de le relire.
Marcel Jackwerth le
1
@Marcel: Cependant, mis à part la perception que les clients ont de la sécurité, je pense que votre décision sur l'approche multi-locataire à adopter doit être basée sur des facteurs tels que les 4 points que j'ai cités dans l'article MSDN: 1. Nombre attendu de locataires . - 2. Besoin de stockage attendu pour chaque locataire. - 3. Nombre prévu d'utilisateurs finaux simultanés. - 4. Addons attendus par locataire.
Daniel Vassallo
1
Merci d'avoir signalé cette section. Number = 10k, Storage = 50mb, Concurrent End-Users = 2 par tenant, Addons = 0. Ainsi, la situation actuelle ayant une approche partagée semble être la plus raisonnable. Je pense que je vais faire quelques appels la semaine prochaine pour savoir ce que les clients ont vraiment besoin / attendent. L'Allemagne et la sécurité des données / informatique est une histoire vraiment difficile.
Marcel Jackwerth
1
Rien que pour les utilisateurs lisant ceci à partir de maintenant, l'article mentionné n'existe plus, quelqu'un en a fait une copie, peut-être?
gmslzr
1
@guillesalazar Je ne suis pas sûr que ce soit le même, mais je suppose que c'est - docs.microsoft.com/en-us/azure/sql-database / ... (@DanielVassallo si c'est le même, envisagez peut-être de mettre à jour le lien dans votre réponse :-))
Shai Kerer
20

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)

AdaTheDev
la source
Ouais, désolé de ne pas avoir clarifié cela plus tôt. Toujours +1. ;)
Marcel Jackwerth
en parlant de sécurité des données, direz-vous que chaque base de données doit être placée sur des serveurs / VM séparés? ou avoir toutes les bases de données sur un serveur unique / en cluster avec différents utilisateurs SQL est suffisamment sécurisé?
Shay
@Shay - Non, vous ne devriez pas avoir besoin de les placer sur des serveurs séparés - imaginez que vous en avez des centaines, c'est-à-dire beaucoup d'instances / licences de serveur dont vous avez besoin pour commencer. Voir la réponse de Daniel plus haut, il y a de bons liens là-dedans.
AdaTheDev
Je dirais que même si le multi-base de données signifie 10000 bases de données séparées et augmente considérablement le coût de maintenance, vous pouvez toujours apprivoiser cette bête en utilisant des scripts d'automatisation sur votre infrastructure cloud de sorte que tout devienne géré par programme, nécessitant peu ou pas d'effort humain du tout.
Korayem
17

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.

Dana
la source
10

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.

CraigKerstiens
la source