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

Question

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 on peut facilement déterminer quelles données appartient à quel locataire. Cependant, il y a certaines entreprises bien sûr, qui craignent que leurs données pourraient être compromis, donc nous évaluons d'autres solutions.

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

• Multi-Base de données (chaque locataire obtient son propre - à peu près le même que 1 serveur par client)
• Multi-schéma (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 enregistrement identifiant supplémentaire sur chaque colonne)

Multi-schéma est mon préféré (compte tenu des coûts). Cependant la création d'un nouveau compte et faire des migrations semble être très douloureux, parce que je dois itérer sur tous les schémas et changer leurs tables / colonnes / définitions.

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

P.S. Je veux dire par plusieurs quelque chose comme ultra-Multi (10.000+ locataires).

Answer 1

  

Cependant, il y a des entreprises de   bien sûr, qui craignent que leurs données pourraient   être compromis, donc nous évaluons   d'autres solutions.

Ceci est regrettable, car les clients souffrent parfois d'une idée fausse que seul l'isolement physique peut offrir une sécurité suffisante.

Il y a un article intéressant MSDN, intitulé architecture de données multi-locataires , que vous pouvez vérifier. Voici comment les auteurs ont abordé la conception erronée vers l'approche commune:

  

Une idée fausse commune veut que   que l'isolement physique peut fournir un   niveau de sécurité approprié. Dans   fait, les données stockées au moyen d'un partage   approche peut également fournir des données solides   la sécurité, mais nécessite l'utilisation de plus   modèles de conception sophistiqués.

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

  

Le nombre, la nature et les besoins des   les locataires attendent de vous servir affectent tous   votre décision d'architecture de données   différentes façons. Certains des éléments suivants   Les questions peuvent vous biais vers un plus   approche isolée, tandis que d'autres   biais vous vers une plus partagée   approche.

     

  

• Combien de locataires potentiels comptez-vous cibler? Vous pouvez être nulle part   près d'être en mesure d'estimer   utilisation prospective avec autorité, mais   penser en termes de plusieurs ordres de grandeur:   construisez-vous une demande de   des centaines de locataires? Milliers? Dizaines   de milliers? Plus? Plus vous   attendre votre base de locataire d'être, la   plus vous voudrez considérer   une approche plus partagée.

  

• Quel espace pensez-vous que les données du locataire moyen d'occuper?   Si vous vous attendez à tout ou partie des locataires à   stocker, les très grandes quantités de données   approche base de données séparée est probablement   meilleur. (En effet, le stockage de données   exigences peuvent vous obliger à adopter une   modèle distinct base de données de toute façon. Si c'est le cas,   il sera beaucoup plus facile de concevoir la   l'application de cette façon à partir de la   en commençant que de passer à un   approche base de données séparée par la suite.)

  

• Combien d'utilisateurs finaux en même temps que vous attendez le locataire moyen de soutenir?   Plus le nombre, plus   approprier une approche plus isolée   sera de répondre aux besoins de l'utilisateur final.

  

• Vous attendez-vous à offrir des services à valeur ajoutée par-locataire, tels   comme sauvegarde par-locataire et de restauration   aptitude? Ces services sont plus faciles   d'offrir à travers un plus isolé   approche.

  

---

Mise à jour:. De plus à jour sur le nombre attendu des locataires

Ce nombre attendu des locataires (10k) devrait exclure l'approche multi-base de données, pour la plupart, sinon tous les scénarios. Je ne pense pas que vous envie l'idée de maintenir 10.000 instances de base de données, et d'avoir à créer des centaines de nouveaux chaque jour.

A partir de ce paramètre seul, il ressemble à la base de données partagée, l'approche unique schéma est le plus approprié. Le fait que vous allez stocker à peu près 50 Mo par locataire, et qu'il n'y aura pas d'add-ons par-locataire, rend cette approche 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 base de données partagée:

• Connexions de base de données de confiance
• Locataire Voir filtre
• de chiffrement de données locataire

Lorsque vous êtes à l'aise avec les mesures de sécurité des données de votre application, vous would être en mesure d'offrir à vos clients un niveau de service Agrement qui fournit de solides garanties de sécurité des données. Dans votre SLA, en dehors des garanties, vous pouvez aussi décrire les mesures que vous prenez pour assurer que les données ne soit pas compromise.

Mise à jour 2: Apparemment, les gars Microsoft déplacé / fait un nouvel article sur ce sujet, le lien d'origine a disparu, ce qui est le nouveau: modèles de bail base de données SaaS multi-locataire du (des félicitations à Shai Kerer)

Answer 2

Voici un lien vers un livre blanc sur Salesforce.com sur la façon dont ils mettent en oeuvre multi-location:

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

Ils ont une grande table w / 500 colonnes de chaîne (value0, valeur1, ... Value500). Les dates et les numéros sont stockés sous forme de chaînes dans un format de telle sorte qu'ils peuvent être convertis en leurs types natifs au niveau de la base de données. Il y a des tables de méta-données qui définissent la forme du modèle de données qui peut être unique par locataire. Il y a des tables supplémentaires pour l'indexation, les relations, les valeurs uniques etc.

Pourquoi les tracas?

Chaque locataire peut personnaliser leur propre schéma de données à l'exécution sans avoir à apporter des modifications au niveau de la base de données (alter table, etc.). Ceci est sans aucun doute la façon difficile de faire quelque chose comme ça, mais est très flexible.

Answer 3

Mon expérience (bien que SQL Server) est que multi-base de données est le chemin à parcourir, où chaque client a sa propre base de données. Ainsi, bien que je ne mySQL ou de l'expérience Ruby On Rails, j'espère que mon entrée pourrait ajouter une certaine valeur.

Les raisons pour lesquelles comprennent:

1. la sécurité des données / de reprise après incident. Chaque donnée de sociétés sont entièrement stockées séparément des autres donnant un risque réduit de compromettre vos données (les choses à penser comme si vous introduisez un bug de code qui signifie quelque chose semble par erreur à d'autres données client quand il ne devrait pas), minimise la perte potentielle d'un client si l'on base de données particulière est corrompue, etc. les prestations de sécurité perçues au client sont encore plus (ajouté effet secondaire bonus!)
2. évolutivité. Essentiellement, vous seriez le partitionnement des données pour permettre à une plus grande évolutivité - par exemple bases de données peuvent être mis sur des disques différents, vous pouvez apporter plusieurs serveurs de bases de données en ligne et déplacer des bases autour plus facile de répartir la charge.
3. l'optimisation des performances. Supposons que vous avez un très grand client et un très petit. modèles d'utilisation, les volumes de données, etc. peuvent varier énormément. Vous pouvez régler / Optimiser plus facile pour chaque client, si vous devez.

J'espère que cela offre une certaine contribution utile! Il y a plus de raisons, mais mon esprit était vide. Si elle donne le coup revenir, je mettrai à jour:)

EDIT: Depuis que j'ai posté cette réponse, il est maintenant clair que nous parlons locataires 10,000+. Mon expérience est dans des centaines de grandes bases de données à grande échelle - Je ne pense pas que 10.000 bases de données distinctes va être trop facile à gérer pour votre scénario, donc je suis maintenant qui ne favorise pas l'approche multi-db pour votre scénario. D'autant plus que c'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 il peut avoir une certaine utilité pour d'autres personnes dans un bateau similaire (avec moins de locataires)

Answer 4

Comme vous le mentionnez une base de données par locataire est une option et a quelques compromis plus grandes avec elle. Il peut bien fonctionner à plus petite échelle, comme un seul chiffre ou bas 10 de des locataires, mais au-delà, il devient plus difficile à gérer. Les deux seulement les migrations, mais aussi juste garder les bases de données et en cours d'exécution.

Le modèle par schéma est non seulement utile pour des schémas uniques pour chaque, bien que les migrations en cours d'exécution encore dans tous les locataires devient difficile et 1000 des schémas Postgres peut commencer à avoir des ennuis.

Une approche plus évolutive est tout à fait d'avoir des locataires répartis de façon aléatoire, stockées dans la même base de données, mais à travers différents tessons logiques (ou tables ). En fonction de votre langue, il y a un certain nombre de bibliothèques qui peuvent aider. Si vous utilisez Rails il y a une bibliothèque à la location enfore acts_as_tenant , il contribue à assurer que tirer vos requêtes des locataires retour ces données. Il y a aussi un petit bijou apartment - si elle utilise le modèle de schéma, il ne permet aux migrations à travers tous les schémas. Si vous utilisez Django, il y a un certain nombre, mais l'un des plus populaires semble être à travers schémas . Toutes ces initiatives contribuent plus au niveau de l'application. Si vous cherchez quelque chose de plus au niveau de la base de données directement, Citus concentre sur la fabrication de ce type de sharding pour multi-tenancy travailler plus sur la boîte avec Postgres.