Y a-t-il une limite au nombre de bases de données que vous pouvez mettre sur un serveur SQL?
Je mets en place un système SaaS, où nous prévoyons de donner à chaque client sa propre base de données. Le système est déjà configuré de sorte que nous pouvons facilement évoluer vers des serveurs supplémentaires si la charge devient trop grand, nous espérons avoir des milliers, voire des dizaines de milliers de clients.
Des questions
- Existe-t-il une limitation pratique du nombre de micro-bases de données que vous pouvez/devez avoir sur un serveur SQL?
- Peut-il affecter les performances du serveur?
- Est-il préférable d'avoir 10 000 bases de données de 100 Mo chacune, ou une base de données de 1 To?
Information additionnelle
Quand je dis "micro-bases de données", je ne veux pas vraiment dire "micro"; Je veux simplement dire que nous visons des milliers de clients, de sorte que chaque base de données individuelle ne représenterait qu'un millième ou moins du stockage total de données. En réalité, chaque base de données se situerait autour de la barre des 100 Mo, en fonction de son utilisation.
La principale raison d'utiliser 10 000 bases de données est l'évolutivité. Le fait est que la V1 du système a une base de données, et nous avons eu des moments inconfortables lorsque la DB se tendait sous la charge.
Il sollicitait le processeur, la mémoire, les E/S - tout cela. Même si nous avons résolu ces problèmes, ils nous ont fait comprendre qu'à un moment donné, même avec la meilleure indexation au monde, si nous réussissons aussi bien que nous l'espérons, nous ne pouvons tout simplement pas mettre toutes nos données dans un seul grand honkin ' base de données. Donc, pour V2, nous partageons, nous pouvons donc répartir la charge entre plusieurs serveurs de base de données.
J'ai passé l'année dernière à développer cette solution fragmentée. C'est une licence par serveur, mais de toute façon cela est pris en compte puisque nous utilisons des machines virtuelles sur Azure. La raison pour laquelle la question se pose maintenant est que, auparavant, nous ne proposions que de grandes institutions et que nous les installions nous-mêmes. Notre prochain ordre du jour est un modèle de libre-service où toute personne disposant d'un navigateur peut s'inscrire et créer sa propre base de données. Leurs bases de données seront beaucoup plus petites et beaucoup plus nombreuses que les grandes institutions.
Nous avons essayé Azure SQL Database Elastic Pools . Les performances ont été très décevantes, nous sommes donc revenus aux machines virtuelles habituelles.
J'ai travaillé sur des serveurs SQL avec 8 à 10 000 bases de données sur une seule instance. Ce n'est pas joli.
Le redémarrage du serveur peut prendre jusqu'à une heure ou plus. Pensez au processus de récupération de 10 000 bases de données.
Vous ne pouvez pas utiliser SQL Server Management Studio pour localiser de manière fiable une base de données dans l'Explorateur d'objets.
Les sauvegardes sont un cauchemar, car pour que les sauvegardes en valent la peine, vous devez disposer d'une solution de récupération après sinistre fonctionnelle. J'espère que votre équipe est excellente en script tout.
Vous commencez à faire des choses comme nommer des bases de données avec des nombres, comme M01022, et T9945. Essayer de vous assurer que vous travaillez dans la bonne base de données, par exemple M001022 au lieu de M01022, peut être exaspérant.
L'allocation de mémoire pour autant de bases de données peut être atroce; SQL Server finit par faire beaucoup d'E/S, ce qui peut être un véritable frein aux performances. Prenons un système qui enregistre les détails de l'utilisation du carbone sur 4 tableaux pour 10 000 entreprises. Si vous faites cela dans une base de données, vous n'avez besoin que de 4 tables; si vous faites cela dans 10 000 bases de données, vous avez soudainement besoin de 40 000 tables en mémoire. La surcharge de traitement de ce nombre de tables en mémoire est considérable. Toute requête que vous concevez qui sera exécutée sur ces tables nécessitera au moins 10 000 plans dans le cache de plan si 10 000 bases de données sont utilisées.
La liste ci-dessus n'est qu'un petit échantillon des problèmes que vous devrez planifier lorsque vous opérez à ce type d'échelle.
Vous rencontrerez probablement des choses comme le service SQL Server qui prend beaucoup de temps pour démarrer, ce qui peut provoquer des erreurs Service Controller. Vous pouvez augmenter le temps de démarrage du service vous-même, créez l'entrée de registre suivante:
Sous-clé: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control Nom: ServicesPipeTimeout Type: REG_DWORD Données: nombre de millisecondes avant l'expiration du délai pendant le démarrage du service
Par exemple, pour attendre 600 secondes (10 minutes) avant l'expiration du service, tapez 600000.
Depuis que j'ai écrit ma réponse, j'ai réalisé que la question parlait d'Azure. Peut-être que faire cela sur SQL Database n'est pas si problématique; c'est peut-être plus problématique. Personnellement, je concevrais probablement un système utilisant une seule base de données, peut-être répartie verticalement sur plusieurs serveurs, mais certainement pas une base de données par client.
Il y a donc des avantages et des inconvénients dans les deux méthodes. Sans en savoir plus sur votre candidature ou les services que vous cherchez à fournir, je ne serai pas en mesure de donner une réponse définitive mais je vais vous faire part de mes réflexions à ce sujet.
Mon cas pour lequel vous devriez utiliser 1 base de données pour tous les clients.
Avantages
Maintenance facile. Le fait d'avoir une seule base de données signifie que vous n'avez qu'à effectuer votre tâche de maintenance sur un seul emplacement au lieu de plusieurs. Imaginez le cauchemar de gérer 1000 bases de données différentes à sauvegarder. Que diriez-vous de mettre à jour des statistiques sur 1000 bases de données ou de reconstruire des index ou
DBCC CHECKDB?Deploying Code. Supposons que vous ayez un problème avec une procédure stockée dans votre code d'application ou de génération de rapports. Vous devez effectuer un changement rapide ... Vous devez maintenant déployer ce changement sur plus de 1000 bases de données. Non, merci, je préfère ne pas.
Visibilité facile. Imaginez simplement SSMS essayant d'ouvrir plus de 1000 bases de données (frémissement) . Cela rendrait pratiquement le problème inutile et prendrait un temps surprenant pour simplement ouvrir et rendre SSMS. Gardez à l'esprit que c'est si vous êtes en mesure de trouver une convention de dénomination décente.
Les inconvénients
Sécurité. Il serait plus facile d'empêcher les gens de consulter les données d'autres clients si vous les aviez en tant que bases de données distinctes. Cependant, vous pouvez prendre des mesures très simples pour éviter que cela ne se produise.
Performance. On pourrait faire valoir que le limiter à une base de données par client signifie que le serveur SQL devra parcourir moins de données pour obtenir les informations que vous interrogez. Cependant, avec une structure de données appropriée et une bonne indexation (et un partitionnement possible), vous pouvez probablement éliminer cela comme un problème tous ensemble si cela est fait avec soin. Je recommanderais de donner à chaque table contenant des données spécifiques au client une sorte de
CompanyIDde tête pour réduire cette surcharge.
En fin de compte, je pense que votre meilleur pari est d'avoir une base de données pour votre application et de diviser simplement les données client à l'intérieur de la base de données elle-même. Les problèmes qu'il vous causera ne seront rien comparés au cauchemar de gérer plus de 1000 bases de données.
Spécifications de capacité maximale pour SQL Server indique qu'il existe une limite de 32 767.
Quant à savoir si cela affectera les performances, la réponse est oui, mais les manières dont elles affecteront les performances, et si elles seraient substantielles, dépendraient d'une myriade de facteurs.
J'irais avec la seule base de données à moins qu'il n'y ait une bonne raison de la diviser en 10 000 bases de données. Une sauvegarde ou 10 000 sauvegardes? Un contrôle d'intégrité, ou 10 000? Il peut y avoir une bonne raison d'utiliser 10 000 petites bases de données, mais vous n'avez pas donné suffisamment de détails pour le déterminer. La question que vous avez posée est assez large et il n'y a tout simplement pas assez d'informations pour que quiconque sache quelle est la meilleure réponse.
Ce dont vous parlez ici est multi-locataire vs multi-instance architecture. J'évoque simplement ces termes car vous ne les utilisez pas dans votre question, mais c'est ainsi que vous discutez et si vous branchez simplement "l'architecture multi-locataire" dans Google, vous trouverez une multitude de ressources et de discussions à ce sujet, des livres entiers ont été écrits dessus.
Quelques bonnes ressources concernant SQL Server spécifiquement ici:
https://msdn.Microsoft.com/en-us/library/ff966499.aspx
Je serais avec d'autres réponses, en ce sens que je pencherais fortement vers le multi-tenant par défaut, sauf si vous avez des raisons impérieuses de favoriser le multi-instance.
Vous n'avez pas besoin de vous diviser en milliers de bases de données clientes individuelles pour évoluer, il existe de nombreuses autres façons de le faire, qui sont probablement préférables. Comme le clustering, la réplication, le sharding, le partitionnement, etc. Ne réinventez pas la roue. Il n'y a rien d'inhérent qui dit que vous devez diviser cela vous-même manuellement au niveau d'un client individuel et, en fait, cela augmentera probablement considérablement les coûts d'ajout de chaque nouveau client.
Vous parlez de "millions" de clients, pensez à n'importe quel logiciel basé sur le cloud à grande échelle comme un service, Gmail, peu importe, vous pensez à peine qu'ils créent une base de données entièrement nouvelle pour chaque nouvelle inscription, maintenant?
Il peut y avoir des raisons pour lesquelles vous souhaitez faciliter cela, par exemple, si vous vendez votre produit à un client qui DOIT l'avoir hébergé en interne sur sa propre infrastructure. Mais en règle générale SAAS, s'appuyer par défaut sur une architecture multi-locataire.
L'un des inconvénients que je peux voir dans la suggestion d'une base de données unique est de faire reculer les données - si vous avez une base de données par configuration de locataire, vous pouvez restaurer les données de chaque client indépendamment (et à un moment donné). S'ils sont tous dans une seule base de données, cela devient beaucoup plus difficile (et beaucoup plus sujet aux erreurs car cela devrait probablement être fait via les instructions INSERT/UPDATE/DELETE).
Merci à tous ceux qui ont répondu - appréciez vraiment les points sur lesquels vous m'avez donné à réfléchir. Le sentiment général que j'ai eu est qu'une seule base de données est préférable, mais je voudrais ajouter quelques points compensatoires en faveur de l'architecture fragmentée et répondre à certaines des préoccupations que d'autres ont mentionnées.
Motivation pour le sharding
Comme mentionné dans la question (mise à jour), nous visons des ventes massives dans le monde entier, avec littéralement des millions d'utilisateurs. Avec le meilleur matériel et l'indexation au monde, un seul serveur DB ne prendra pas la charge, nous devons donc être en mesure de distribuer sur plusieurs serveurs. Et une fois que vous devez rechercher sur quel serveur se trouvent les données d'un client donné, ce n'est pas beaucoup plus de leur fournir une base de données dédiée, ce qui simplifie les choses en termes de conservation des données des personnes.
Réponse aux préoccupations
- Le redémarrage du serveur prend beaucoup de temps: OK, mais en fonctionnement normal, nous n'avons pas l'intention de redémarrer les serveurs. Le système doit finalement être en ligne 24 heures sur 24, 7 jours sur 7, donc si nous devons avoir un temps d'arrêt, il devra être programmé de toute façon.
- Sauvegardes/reprise après sinistre: Nous utilisons CloudBerry, qui automatise tout. Pas de problème.
- Nommer les bases de données/les localiser dans SSMS: La convention de dénomination est facile, simplement basée sur le nom du client. Ajoutez des chiffres de série si les noms sont partagés.
- Maintenance: Si chaque base de données est aussi petite que j'envisage, il ne devrait pas être nécessaire de reconstruire les index manuellement.
- Déploiement du code: Nous utilisons Entity Framework, donc chaque modification de schéma sera automatiquement déployée dans chaque base de données avec les nouvelles versions. Il est vrai, cependant, que si nous découvrons un problème de performances en production qui peut être résolu avec un simple index Tweak, il n'est pas si facile de le pousser là-bas. D'un autre côté, avec chaque base de données étant si petite, il est peu probable qu'il y aura des problèmes de performances showstopper sur les fragments de production. Et la base de données commune reste une base de données unique, à laquelle ces préoccupations ne s'appliquent pas.
Je serai heureux de vous entendre dans les commentaires si vous pensez que je manque quelque chose!