Bases de données multiples vs base de données unique avec des données partitionnées logiquement

Question

Je réfléchis à un problème de conception de base de données. Toute aide serait très appréciée.

Nous concevons une application qui comprend 20 tables (qui peuvent atteindre environ 30 maximum au cours du développement de nouvelles fonctionnalités)

La pile technologique

MVC4, .NET 4.X, Entity Framework 5, SQL Server 2012, framework d'adhésion ASP.NET

Nombre d'utilisateurs

Nous avons l'intention de répondre à environ 1000 clients qui auraient en moyenne 20 utilisateurs.

La question

Si nous concevons la base de données et l'application de manière à ce que les tables soient logiquement partitionnées, c'est-à-dire que tous les clients utilisent les mêmes tables avec un guide de partition pour séparer les données.

OR

Optez pour plusieurs bases de données qui pourraient s'avérer difficiles lors du lancement de nouvelles fonctionnalités et de la correction de bogues. MAIS pourrait potentiellement permettre une mise à l'échelle?

Avertissements: l'une des tables a une colonne binaire qui stocke les fichiers (maximum 5 Mo par enregistrement)

En plus de cela, nous devons prendre en compte les tables de structure d'adhésion, que nous étendrons à une autre table personnalisée et mapperons logiquement les utilisateurs à un guide de partition.

ErikE · Accepted Answer

Vous souhaiterez avoir utilisé des bases de données distinctes:

Si vous souhaitez accorder des autorisations aux bases de données elles-mêmes à des clients ou à des superutilisateurs.
Si jamais vous souhaitez restaurer la base de données d'un seul client sans affecter les données des autres.
S'il existe des problèmes réglementaires régissant vos données et les violations de données, et que vous découvrez tardivement que ces réglementations ne peuvent être respectées qu'en ayant des bases de données distinctes.
Si jamais vous souhaitez déplacer facilement vos données client vers plusieurs serveurs de base de données ou autrement évoluer, ou déplacer des clients plus importants/plus importants vers un matériel différent. Dans une autre partie du monde.
Si jamais vous souhaitez archiver et retirer facilement les anciennes données client.
Si vos clients se soucient que leurs données soient cloisonnées et découvrent que vous avez fait autrement.
Si vos données sont assignées à comparaître et que vous devez produire l'intégralité de la base de données au lieu des seules données pour un seul client.
Lorsque vous oubliez de rester vigilant et qu'une seule requête passe à travers qui n'inclut pas AND CustomerID = @CustomerID. Astuce: utilisez un outil d'autorisations scripté, ou des schémas, ou encapsulez toutes les tables avec des vues qui incluent WHERE CustomerID = SomeUserReturningFunction(), ou une combinaison de celles-ci.
Lorsque vous obtenez des autorisations incorrectes au niveau de l'application et que les données client sont exposées au mauvais client.
Lorsque vous souhaitez avoir différents niveaux de protection de sauvegarde et de récupération pour différents clients.
Une fois que vous vous rendez compte que la construction d'une infrastructure pour créer, approvisionner, configurer, déployer et autrement faire monter/descendre de nouvelles bases de données vaut l'investissement car cela vous oblige à vous perfectionner.
Lorsque vous ne permettiez pas à une certaine catégorie de personnes d'avoir besoin d'accéder aux données de plusieurs clients, et vous avez besoin d'une couche d'abstraction au-dessus de Customer parce que WHERE CustomerID = @CustomerID Ne le coupera pas maintenant.
Lorsque les pirates ciblent vos sites ou systèmes et que vous leur facilitiez la tâche d'obtenir toutes les données d'un seul coup après avoir obtenu les informations d'identification d'administrateur dans la base de données un.
Lorsque la sauvegarde de votre base de données prend 5 heures pour s'exécuter, puis échoue.
Lorsque vous devez obtenir l'édition Enterprise de votre SGBD afin de pouvoir effectuer des sauvegardes compressées afin que la copie du fichier de sauvegarde sur le réseau prenne moins de 5 heures plus.
Lorsque vous devez restaurer la base de données entière tous les jours sur un serveur de test, ce qui prend 5 heures, et exécuter des scripts de validation qui prennent 2 heures.
Lorsque seuls quelques-uns de vos clients ont besoin d'une réplication et que vous devez l'appliquer à tous vos clients au lieu de quelques-uns seulement.
Lorsque vous souhaitez prendre un client gouvernemental et découvrir qu'il vous oblige à utiliser un serveur et une base de données distincts, mais votre écosystème a été construit autour d'un serveur et d'une base de données uniques et c'est tout simplement trop difficile ou prendra trop de temps à changer.

Vous serez heureux d'avoir utilisé des bases de données distinctes:

Lorsqu'un déploiement pilote sur un client explose complètement et que les 999 autres clients ne sont pas du tout affectés. Et vous pouvez restaurer à partir d'une sauvegarde pour résoudre le problème.
Lorsqu'une de vos sauvegardes de base de données échoue et que vous pouvez corriger celle-ci en 25 minutes au lieu de recommencer l'intégralité du processus de 10 heures.

Vous souhaiteriez avoir utilisé une seule base de données:

Lorsque vous découvrez un bogue qui affecte tous les 1000 clients et que le déploiement du correctif sur 1000 bases de données est difficile.
Lorsque vous obtenez des autorisations incorrectes au niveau de la base de données et que les données client sont exposées au mauvais client.
Lorsque vous ne permettiez pas à une certaine catégorie de personnes d'avoir accès à un sous-ensemble de toutes les bases de données (peut-être deux clients fusionnent).
Quand vous ne pensiez pas à quel point il serait difficile de fusionner deux bases de données différentes.
Lorsque vous avez fusionné deux bases de données différentes et que vous vous rendez compte que l'une était incorrecte, et que vous n'aviez pas prévu de récupérer à partir de ce scénario.
Lorsque vous essayez de dépasser 32 767 clients/bases de données sur un seul serveur et découvrez que c'est le maximum dans SQL Server 2012.
Lorsque vous réalisez que gérer plus de 1000 bases de données est un cauchemar plus grand que vous ne l'auriez jamais imaginé.
Lorsque vous réalisez que vous ne pouvez pas intégrer un nouveau client simplement en ajoutant des données dans une table et que vous devez exécuter un tas de scripts effrayants et compliqués pour créer, remplir et définir des autorisations sur une nouvelle base de données.
Lorsque vous devez exécuter 1000 sauvegardes de base de données chaque jour, assurez-vous qu'elles réussissent toutes, copiez-les sur le réseau, restaurez-les toutes dans une base de données de test et exécutez des scripts de validation sur chacune d'elles, signalant tout échec d'une manière qui garantira être vu, et qui sont facilement et rapidement exploitables. Et puis 150 d'entre eux échouent à divers endroits et doivent être réparés un à la fois.
Lorsque vous découvrez que vous devez configurer la réplication pour 1000 bases de données.

Ce n'est pas parce que j'ai énuméré plus de raisons pour cela que c'est mieux.

Certains lecteurs peuvent tirer profit de MSDN: Multi-Tenant Data Architecture . Ou peut-être modèles de conception d'applications SaaS Tenancy . Ou même Developing Multi-tenant Applications for the Cloud, 3rd Edition

Fendy · Answer

Si vous référez votre architecture comme "multi locataire", Microsoft a un bon article qui vaut la peine d'être lu ici . Il montre une comparaison entre "isolated" (multiple db) et "shared" (single db). En général, le partage gagne lorsque le nombre de locataires (client) est important, mais lorsque la taille de chaque locataire est importante, une approche isolée est recommandée.

Cependant, ces considérations ne peuvent être calculées que par des développeurs expérimentés.

Néanmoins, si vous avez réussi à utiliser l'architecture isolated (multiple db), vous avez toujours vous n'obtiendrez pas d'avantages directs en termes de performances lorsqu'ils sont toujours exécutés sur la même instance . Et si vous utilisez l'architecture shared (single db), pensez à utiliser int au lieu de guid, ou sequential guid si vous devez encore l'utiliser.