À quel moment une base de données par client devient-elle impossible?

Pour l'un de nos systèmes, nous avons des données client sensibles et stockons les données de chaque client dans une base de données distincte. Nous avons environ 10 à 15 clients pour ce système.

Cependant, nous développons un nouveau système qui comptera de 50 à 100 clients, peut-être plus. Je pense qu'il pourrait être impossible d'avoir une base de données par client dans ce cas (pour stocker les enregistrements sensibles et l'historique d'audit). Cependant, je ne sais pas si cela est parfaitement normal ou non, ou s'il existe un autre moyen de maintenir la sécurité.

Des idées à ce sujet?

La gestion de 100 ou 500 bases de données n'est vraiment pas si différente de la gestion de 5 ou 10 - vous devez simplement adopter l'automatisation et avoir un plan d'évolutivité en place (et ne prévoyez pas d'utiliser des fonctionnalités à coût élevé par base de données comme la mise en miroir dans tous clients).

Lors de mon travail précédent, nous avions utilisé cette architecture et je n'aurais jamais pensé à fusionner deux clients en une seule base de données, même si certains des défis peuvent être "difficiles".

Les grands avantages sont les modèles de récupération indépendants ( apeuvent être simples, bpeuvent être complets, etc.), la possibilité de restaurer à un moment donné (ou de supprimer complètement) un client sans perturber les autres, la possibilité de déplacer en toute transparence un client gourmand en ressources à son propre stockage ou à un serveur complètement différent avec très peu de transparence (vous mettez à jour un fichier ou une table de configuration qui indique à l'application où trouver ce client).

J'aborde plusieurs des objections et / ou comment aborder les problèmes dans ces messages:

• Gestion d'un nombre croissant de locataires dans une architecture de base de données multi-locataires

• Base de données multi-locataires utilisant SQL Server 2008?

• Automatisation des sauvegardes d'un grand nombre de bases de données

Cela dit, je pense qu'aucun d'entre nous ne peut vous dire à quel point la gestion devient impraticable pour vous - sachez que quels que soient les défis spécifiques que vous rencontrez, vous pouvez poser des questions sur ces problèmes individuellement.

Je vous recommande de lire Multi-Tenant Data Architecture , un livre blanc qui présente les options dont vous disposez, les avantages et les inconvénients. Pour résumer, il propose trois options:

• DB séparés
• schémas séparés
• schéma partagé

Vous êtes maintenant à l'étape de bases de données distinctes, qui offre la meilleure séparation (isolation entre les locataires), mais est la plus difficile à gérer. En devenant des centaines de locataires, vous vous rendrez compte que la logistique de l'administration de centaines de bases de données est loin d'être anodine. Pensez à la sauvegarde-restauration (emplacement des fichiers sauvegardés, des tâches, des planifications, etc.). Réfléchissez à la façon dont vous allez surveiller et gérer l'allocation des fichiers, l'espace disque utilisé et la croissance de la base de données sur des centaines de bases de données. Vous pensez quel sera votre scénario de haute disponibilité / reprise après sinistre dans un avenir proche avec 1000 locataires? 1000 DB en miroir, 1000 sessions d'envoi de journaux? Pensez à ce que si dans 6 mois votre équipe de développement vient à vous et vous dit "Je sais comment donner cette fonctionnalité géniale à notre produit, nous utiliserons la réplication transactionnelle!", Que direz-vous? "Bien sûr, permettez-moi de créer 500 éditeurs,"! Il n'est pas impossible de gérer des centaines de bases de données, mais si vous prévoyez de le faire, vous feriez mieux de perfectionner vos compétences PowerShell et de cesser d'utiliser les outils de gestion de l'interface utilisateur dès maintenant .

De plus, vous devez considérer que plusieurs (centaines) bases de données ont un impact mesurable sur les performances et les coûts:

• l'espace disque physique est utilisé de manière moins efficace (chaque base de données doit avoir une pièce de rechange, vous aurez cette pièce de rechange multipliée par le nombre de bases de données)
• Il n'y a aucun moyen de créer un disque de journal dédié pour les tâches gourmandes en écriture, vous devrez déplacer tous ces LDF sur un (ou plusieurs) stockage SSD
• les écritures de journal seront moins efficaces lors des validations fréquentes car elles s'étalent sur de nombreux enregistrements de bloc de journaux individuels par rapport à l'agrégation en un (vous obtiendrez des blocs de journaux sous-utilisés). Voir Qu'est-ce qu'un LSN: Numéro de séquence de journal pour comprendre de quoi je parle.

Les bases de données séparées présentent certains avantages, mais en raison de l'isolement, le principal avantage étant la sauvegarde / restauration indépendante.

Un scénario comme le vôtre est un candidat parfait pour les bases de données SQL Azure . Aucune administration d'espace disque, pas besoin de fournir HA / DR, passer à des centaines / milliers de bases de données, etc.

Lors de mon travail précédent, nous n'avions pas hébergé une seule base de données par client - dans la plupart des cas, c'était plus que cela! À mon départ, il y avait plus de 4 500 bases de données en cours d'exécution dans un cluster MariaDB, près de 7 000 dans un autre cluster (ironiquement plus petit) et 4 "fragments" (serveurs Web et de base de données complètement séparés et indépendants, même dans un centre de données entièrement séparé) chaque hébergement 200 à 500 bases de données sur un seul serveur MySQL. Et cette entreprise se développe toujours à un bon clip.

Le long et le court est que le succès de cette entreprise prouve qu'une telle architecture est en effet réalisable. (Mise en garde: contrairement aux gains apparents dans l'isolement en utilisant des bases de données distinctes, toutes les données ont été accessibles via un trio d'applications étroitement couplées qui utilisaient toutes le même utilisateur / passe de base de données! Je soupçonne que les performances peuvent avoir été si légèrement diminuées si chaque client avait un utilisateur / pass séparé - mais seulement légèrement.)

D'après mes expériences de travail en étroite collaboration avec les administrateurs système (techniquement j'étais programmeur dans l'entreprise, mais en réalité j'étais le meilleur DBA qu'ils avaient, et la seule personne qu'ils avaient qui savait comment mettre en place un pare-feu!), Liée aux performances les préoccupations se résumaient aux accès simultanés, à la complexité / temps des requêtes, aux performances des index, etc. - tous les suspects habituels, en d'autres termes, et le nombre de bases de données sur le serveur ne jouaient aucun rôle perceptible, une conclusion affirmée par le spécialiste hautement rémunéré consultants que nous avons consultés régulièrement.

En fin de compte, vous devez concentrer vos préoccupations sur votre application, sur votre infrastructure et non sur le nombre de bases de données que vous possédez. Tous ces autres facteurs seront plus que suffisants pour vous aider à résoudre les problèmes de performances et les goulots d'étranglement.