Les bases de données multi-locataires ont-elles plusieurs bases de données ou tables partagées?

Est une base de données multi-locataire:

Un serveur de base de données qui a une base de données / schéma différent (identique) pour chaque client / locataire ?; ou
Un serveur de base de données qui a une base de données / schéma où les clients / locataires partagent des enregistrements à l'intérieur des mêmes tables?

Par exemple, sous l'option n ° 1 ci-dessus, je pourrais avoir un serveur MySQL sur, disons mydb01.example.com, et il pourrait avoir une customer1base de données à l'intérieur. Cette customer1base de données pourrait avoir, disons, 10 tables qui alimentent mon application pour ce client particulier (client n ° 1). Il peut également customer2contenir une base de données contenant exactement les mêmes 10 tables, mais contenant uniquement des données pour le client n ° 2. Il peut avoir une customer3base de données, une customer4base de données, etc.

Dans l'option n ° 2 ci-dessus, il n'y aurait qu'une seule base de données / schéma, disons, myapp_dbavec encore 10 tables (les mêmes que ci-dessus). Mais ici, les données de tous les clients existent à l'intérieur de ces 10 tableaux, et ils "partagent" donc les tableaux. Et au niveau de la couche application, la logique et le contrôle de sécurité auxquels les clients ont accès à quels enregistrements dans ces 10 tables, et un grand soin est pris pour s'assurer que le client n ° 1 ne se connecte jamais à l'application et voit les données du client n ° 3, etc.

Lequel de ces paradigmes constitue une base de données traditionnelle "multi-tenant"? Et si ni l'un ni l'autre, alors quelqu'un peut-il me fournir un exemple (en utilisant les scénarios décrits ci-dessus) de ce qu'est une base de données multi-tenant?

database-design multitenancy

— smeeb
source

"multi locataire" implique une sécurité forte - implémentée quelque part - de sorte qu'un locataire ne peut pas voir les données des autres, ne peut pas les modifier, ne peut pas lui refuser l'accès, etc. Cette sécurité doit être implémentée d'une manière ou d'une autre. Les options # 1 et # 2 de l'OP fonctionnent toutes les deux mais l'analyse de sécurité et le travail requis pour implémenter la sécurité sont différents. Pour ce que ça vaut, j'ai travaillé dans une startup qui a implémenté l'hébergement multiclient via l'option # 2 où les tables - avec des lignes appartenant à plusieurs locataires - ont été cachées (via des autorisations) à tous les utilisateurs finaux et la sécurité a été entièrement mise en œuvre dans les procédures stockées.

— davidbak

Double possible de multi-location - base de données unique vs base de données multiples

— jeffo

Si cela finit par être fermé en double, je pense que nous devrions signaler de le fusionner avec la cible dupe parce que les deux questions ont de très bonnes réponses.

Réponses:

Lequel de ces paradigmes constitue une base de données traditionnelle "multi-tenant"

Les deux concepts sont appelés multi-locataires, car il s'agit simplement d'un concept logique "dans lequel une seule instance de logiciel s'exécute sur un serveur et sert plusieurs locataires" (de Wikipedia ). Mais la façon dont vous implémentez ce concept "physiquement" dépend de vous.

Bien sûr, l'application a besoin d'un concept de base de données qui permet de séparer les données des différents locataires, et l'idée de la multi-location est de partager certaines ressources du serveur (au moins le matériel) pour une meilleure utilisation des ressources et une administration plus facile. Ainsi, une "base de données multi-locataire" est celle qui prend en charge cela directement , où des parties du modèle ou des tables db sont partagées.

Pour être précis, il est possible de créer une application multi-locataire avec une base de données non multi-locataire, fournissant une instance de base de données individuelle par client. Cependant, cela empêche de partager toutes les ressources de base de données directement entre les locataires, et la couche application doit s'assurer de connecter le bon locataire à la bonne base de données.

— Doc Brown
source

Merci @Doc Brown (+1) mais alors, comment pourriez-vous avoir une base de données qui n'était pas multi-locataire?!?

— smeeb

@smeeb: la multi-location est une propriété de l'application utilisée par différents locataires, et non de la base de données "derrière" l'application. Bien sûr, le concept db doit prendre en charge la multi-location pour rendre cela possible.

— Doc Brown du

@smeeb: supposons que vous ayez une table User avec une contrainte que le nom d'utilisateur est unique, maintenant un employé d'un locataire ne peut plus utiliser un nom d'utilisateur simplement parce qu'une autre personne travaillant dans un autre locataire l'utilise déjà.

— RemcoGerlich

@smeeb: si la seule façon de servir deux locataires est d'installer et d'exécuter une application deux fois, sur deux serveurs différents, avec deux bases de données distinctes, je pense que l'on n'appellerait pas cette multi-location.

— Doc Brown

Je suis allé à une présentation sur Azure il y a quelque temps qui disait que MYOB exécutait sa solution cloud sur Azure, et chaque locataire obtenait sa propre base de données (et probablement des serveurs Web aussi); ils ont juste d'excellents outils d'automatisation pour gérer les centaines d'instances de base de données qui doivent être utilisées. D'un autre côté, l'organisation pour laquelle je travaille actuellement gère des centaines de clients à partir d'une seule base de données, il y a juste pas mal de travail effectué dans le logiciel pour imposer l'isolement des données des clients. Nous avons également considéré un hybride, où nos plus gros clients obtiendraient leur propre base de données, tandis que d'autres partageaient l'original.

— David Keaveny

Selon Microsoft, le terme a 3 significations potentielles (une base de données pour tous les locataires, ou un databaser par locataire).

Pour utiliser votre exemple, chaque client serait son propre locataire.

Une base de données par locataire (client)
- Chaque locataire est isolé des autres (pas d'accès accidentel aux données des autres locataires)
- L'isolement facilite également la gestion de la restauration des données ainsi que l'adaptation des besoins de stockage aux besoins des locataires.
Une base de données partagée, un schéma séparé.
- Chaque locataire a son propre schéma et leurs données sont dans leurs propres tables.
- La restauration peut prendre plus de temps, car tout le monde est dans la même base de données, vous ne pouvez pas simplement restaurer la base de données dans une sauvegarde antérieure (elle annulerait les données de chaque locataire). Une option consiste à restaurer dans une nouvelle base de données, puis à fusionner / copier uniquement les données des 1 locataires.
Une base de données partagée, un schéma partagé.
- Les données de chaque locataire sont dans les mêmes tableaux. Si vous suivez les commandes par exemple, les commandes de chaque locataire se trouveront dans "dbo.Orders".
- Les données des locataires sont séparées par une colonne dans chaque table (peut être TenantId), qui indique le propriétaire de la ligne.

Il y a des avantages et des inconvénients pour chacun, bien expliqués dans cet article: https://msdn.microsoft.com/en-us/library/aa479086.aspx

Bonus: vous pouvez le considérer comme un logement (grossièrement simplifié).

Chaque locataire a sa propre maison. Ils peuvent faire ce qu'ils veulent, et si ça brûle, cela n'affecte vraiment personne d'autre.
Chaque locataire est dans le même immeuble, mais a son propre appartement.
Tout le monde vit dans le même appartement et toutes les choses sont marquées d'un pense-bête pour montrer à qui il appartient.

— lmms90
source

Merci pour votre réponse. Pourriez-vous expliquer un peu votre réponse? Cela créerait une meilleure réponse.

— Thomas Junk

votre exemple de bonus est génial @ imms90

— Aravin

Microsoft a supprimé la page que vous avez liée à partir de MSDN. La machine de renvoi a toujours une copie.

— Mike Sherrill 'Cat Recall'

Article similaire de MS (peut-être le même qui a déménagé): docs.microsoft.com/en-us/azure/sql-database/…

— Pierre Henry