Clients multiples ; une application hébergée. Vous décrivez une base de données mutualisée.
Lorsque vous créez une base de données mutualisée, vous devez prendre en compte
- requête
- coût
- isolation et protection des données
- l'entretien, et
- reprise après sinistre.
Les solutions multi-locataires vont d'une base de données par locataire (rien partagé) à une ligne par locataire (tout partagé).
"Rien partagé", "base de données séparée" ou une base de données par locataire
- Le plus cher par client. (Un grand nombre de clients implique un grand nombre de serveurs.)
- Degré d'isolation des données le plus élevé.
- La reprise après sinistre pour un seul locataire est simple et directe.
- La maintenance est théoriquement plus difficile, car des modifications doivent être effectuées dans chaque base de données. Mais votre dbms peut facilement prendre en charge l'exécution de procédures stockées dans chaque base de données. (SQL Server a une procédure stockée système non documentée, sp_msforeachdb, par exemple. Vous pouvez probablement écrire la vôtre.) « Rien partagé » est également la plus facilement personnalisable, mais cela soulève également plus de problèmes de maintenance.
- Nombre minimal de lignes par table. La vitesse d'interrogation est presque optimale.
"Tout partagé", ou "schéma partagé", ou "une base de données par planète"
- Moins cher par locataire.
- Degré le plus faible d'isolement des données. Chaque tableau comporte une colonne qui identifie le locataire auquel appartient une ligne. Étant donné que les lignes des locataires sont mélangées dans chaque table, il est relativement simple d'exposer accidentellement les données d'autres locataires.
- La reprise après sinistre pour un seul locataire est relativement compliquée ; vous devez restaurer des lignes individuelles dans de nombreuses tables.
- La maintenance structurelle est plus simple, étant donné que tous les locataires partagent les tables. Cependant, cela augmente la charge de communication, car vous devez communiquer et coordonner chaque changement avec chaque locataire. Ce n'est pas facilement personnalisable.
- Nombre maximal de lignes par table. L'interrogation rapide est plus difficile, mais cela dépend du nombre de locataires et du nombre de lignes. Vous pourriez facilement basculer sur le territoire VLDB.
Entre "rien partagé" et "tout partagé" se trouve "schéma partagé".
"Schéma partagé"
- Les locataires partagent une base de données, mais chaque locataire a son propre schéma nommé. Le coût se situe entre « rien partagé » et « tout partagé » ; les grands systèmes ont généralement besoin de moins de serveurs que "ne rien partager", de plus de serveurs que de "tout partager".
- Mieux s'isoler que "tout partager". Pas tout à fait autant d'isolement que "ne rien partager". (Vous pouvez accorder et annuler les autorisations sur les schémas.)
- La reprise après sinistre pour un locataire unique nécessite la restauration de l'un des nombreux schémas. C'est soit relativement facile, soit assez difficile, selon votre dbm.
- La maintenance est plus simple que "ne rien partager" ; pas aussi simple que "tout partager". Il est relativement simple d'écrire une procédure stockée qui s'exécutera dans chaque schéma d'une base de données. Il est plus facile de partager des tables communes entre les locataires qu'avec "ne rien partager".
- Généralement plus de locataires actifs par serveur que "ne partageant rien", ce qui signifie qu'ils partagent (dégradent) plus de ressources. Mais pas aussi mauvais que "tout partager".
Microsoft a un bon article sur l'architecture multi-tenant avec plus de détails. (Le lien est vers une seule page d'un document de plusieurs pages.)
