Multi-tenancy - base de données unique vs base de données multiple

20

Nous avons un certain nombre de clients, dont les systèmes partagent certaines fonctionnalités, mais ont également un certain degré de diversité. Le nombre de clients augmente - toujours une chose saine! - et la diversité entre leurs entreprises augmente également.

À l'heure actuelle, il existe un seul site Web ASP.Net (formulaires Web) (par opposition au projet Web), qui a des sous-dossiers pour chaque locataire, avec les pages non standard de ce locataire. Il existe un projet de modèle distinct, qui traite de l'accès aux bases de données et de la logique métier.

Ce qui est préférable - et surtout, pourquoi - entre avoir (a) 1 base de données par client, avec seulement les fonctionnalités associées à ce client; ou (b) une base de données unique partagée par tous les clients, où seul un sous-ensemble de tables est utilisé par un même client.

Les principales préoccupations au sein de l'entreprise sont dépassées:

maintenance de plusieurs actifs - sauvegardes, contrôle de version, etc.
promouvoir autant que possible la réutilisation

Comment garantiriez-vous que ces préoccupations soient prises en compte, quelle solution est préférable et pourquoi? (J'ai également compilé des réponses à des questions similaires)

database-design projects-and-solutions multitenancy

— RichardW1001
source

Y a-t-il une chance que cela passe à un environnement cloud PaaS comme Azure? Si c'est le cas, vous voudrez également prendre en compte les meilleures pratiques pour l'environnement. La dernière fois que j'ai regardé, MS a recommandé plusieurs bases de données pour les logiciels multi-locataires sur Azure.

— Harper Shelby

Merci d'avoir posé la question. Je me demandais des choses similaires, mais je n'ai pas pu mettre en forme de question aussi éloquemment que vous.

— MathAttack

Vous devriez lire la série de blogs multi-locations d'Ayende. Il fait de très bons points sur la base de données multi vs single.

— Sebazzz

12

Voici les points saillants de la recherche provenant d'autres sources (à l'origine de la révision 2 de la question ):

Dois-je utiliser une base de données par application ou partager une seule base de données entre plusieurs applications
Prise en charge de la mutualisation
Architecture de données multi-locataires MSDN
SO Comment créer une base de données multi-tenant avec des structures de tables partagées?
CloudExpo SaaS - Options de conception de bases de données multi-locataires
Blogs MSDN Passer au modèle de base de données multi-locataires en toute simplicité avec les fédérations SQL Azure
Demander une base de données SQL Server Central One ou plusieurs?
SQL Server Central Mixing tables de différentes bases de données / applications dans une seule base de données
Blog Ayende @ Rahien Multi Tenancy - Le modèle de données physiques
Architecture du projet de code Multi Tenants Database
Joel sur la conception de bases de données logicielles multi-locataires
DONC Application multiple utilisant une seule base de données?
DONC Bases de données uniques ou multiples
Code Rant - Multi-tenancy Part 1, Strategy and Part 2, Components and Context

— utilisateur40980
source

10

Si vous utilisez SQL Server, utilisez une base de données mais utilisez des schémas. Utilisez dbo pour les éléments généraux à tous les clients et créez un schéma pour chaque client et faites-en le schéma par défaut pour les utilisateurs de ce client. Vous pouvez maintenant avoir un objet général (par exemple un proc getBudget) dans le schéma dbo et un objet personnalisé pour le client dans leur schéma avec le même nom.

— HLGEM
source

+1 Cela vous permettra également d'éviter d'avoir à configurer MSDTC et à assumer les frais généraux associés (validations en deux phases)

— brian

Et j'espère que vous éviterez le piège d'avoir des colonnes comme CustomField1 à CustomField30 et / ou des tables comme Budget, BudgetEx, BudgetCustom, BudgetCustomerName, BudgetAnotherCustomerName, etc.

— jfrankcarr

Il existe une couche d'accès aux données qui utilise beaucoup de procédures stockées - 190 tables, 5 procédures générées par code par table, plus certaines personnalisées - alors que l'objectif à moyen terme est d'introduire Entity Framework, serait-il nécessaire de répliquer les données stockées procédures pour chaque schéma?

— RichardW1001

@ RichardW1001: dépend. vous pouvez faire du SQL dynamique dans le sp, afin de le rendre générique, mais cela dépend bien sûr de leur structure au moins quelque peu similaire. Une alternative possible pour sql dynamique, serait les synonymes , malheureusement, si je comprends bien, ils sont à l'échelle du système et ne sont pas contenus dans une transaction, donc ne conviennent pas pour une utilisation simultanée avec des valeurs différentes.

— jmoreno

Si nous utilisons plusieurs schémas, en utilisant EF Code First, sera-t-il possible de migrer tous les schémas vers la dernière version après la mise en service du système?

— Yashvit

4

Étant donné que les bases de données et les fonctionnalités des clients divergent, cela signifie qu'à un moment donné, ils finiront par être des systèmes différents, donc dans ce cas, je recommanderais des systèmes distincts, car les coûts de maintenance des personnalisations pour chaque client l'emporteront sur les avantages d'un seul. système de base de données.

Les systèmes de base de données uniques sont mieux adaptés lorsque les changements entre différents clients ne sont que des configurations mais pas des fonctionnalités supplémentaires pour chaque client.

— Stephen Senkomago Musoke
source

Quelle serait votre suggestion sur la façon de gérer la fonctionnalité commune avec un minimum de douleur?

— RichardW1001

1

Dans votre système de contrôle de version, maintenez une tête pour l'application principale et créez une branche principale pour chaque client, avec des sous-branches pour les nouvelles fonctionnalités dont ils ont besoin pour maintenir. Développer des fonctionnalités spécifiques de la clientèle dans les branches, avec des options pour mettre à jour le tronc , etc. Vous pouvez alors des environnements spécifiques à la clientèle SpinUp avec facilité chaque fois que vous les avez besoin

— Stephen Senkomago Musoke

3

Vous manquez quelques inquiétudes. Les problèmes viendront avec la croissance. Si vous pouvez supposer qu'un jour vous deviendrez plus gros qu'un serveur DB - une base de données complexe vous causera certainement des maux de tête. À moins que vous n'investissiez à l'avance dans l'architecture. Mais c'est aussi une étape coûteuse)

N'oubliez donc pas qu'il est à la fois beaucoup moins cher et beaucoup plus facile de faire évoluer quelques bases de données différentes que d'énormes)

— stim
source

Avez-vous des données qui confirment la facilité de mise à l'échelle? Si c'est le cas, cela constituerait un argument très convaincant. Pourriez-vous nous expliquer les autres préoccupations manquantes? J'essaie de construire un argument aussi complet que possible des deux côtés.

— RichardW1001

1

Un problème que je n'ai pas vu abordé dans les réponses est le problème de la sécurisation correcte d'une application DB multi-locataire. Les applications multi-locataires doivent être très soigneusement conçues pour éviter les problèmes de sécurité. La plupart des bases de données et des applications fournissent une isolation, mais pas complète - il existe généralement des moyens d'inférer directement ou indirectement des données sur les schémas de base de données. Et pas mal de ressources partagées (journaux et autres fichiers, tables DBA, curseurs ...) qui peuvent, à tout le moins, mener à des attaques de déni de service faciles sur d'autres locataires, et généralement beaucoup plus.

— Aigrette
source