Est-ce une bonne idée d'utiliser une base de données pour plus de 50 000 magasins?

Je sais que Shopify n'utilise qu'une seule base de données pour tous les magasins. Mais comment peuvent-ils gérer leur base de données avec un si gros volume de données? Est-ce une bonne idée d'utiliser une base de données unique pour plus de 50 000 magasins?

Veuillez noter: je réponds du point de vue de SQL Server, donc je mentionne certains concepts spécifiques à SQL Server, mais je pense que tous ces concepts ont des équivalents dans les autres principales plates-formes SGBDR, avec des avantages et des limitations similaires.

Je vais également continuer à éditer cette réponse car je pense à d'autres avantages / inconvénients potentiels.

Eh bien, cela dépend vraiment du schéma, du volume, etc. Qu'est-ce qu'un magasin stocke exactement? En quoi est-ce différent de stocker des données sur 50 000 chats ou 50 000 produits ou 50 000 noix à ailes?

Il y a plusieurs raisons (autres que le seul aspect de la taille en soi) pour lesquelles vous ne voudrez peut-être pas stocker les données de 50000 clients différents dans une seule base de données, si en effet les données peuvent être complètement séparées par le client (sans compter les tables de recherche comme les codes postaux ou tables spécifiques à l'application, qui peuvent être regroupées dans une seule base de données centrale):

• si un client l'application devient trop, il n'y a pas moyen facile d'extraire seulement leurs données et le déplacer vers une autre instance, serveur, etc. à l' échelle, à moins que vous planifier à l' avance et partition sur quelque chose comme CustomerIDet ont 50.000 groupes de fichiers (vous limité à 15 000 partitions de toute façon, ou 1 000 si vous utilisez une ancienne version de SQL Server, et avoir trop de groupes de fichiers peut être désastreux ). Notez également que le partitionnement nécessite Enterprise Edition.

• s'il s'avère que tous vos clients sont tout simplement trop gros pour cette instance, la mise à l'échelle signifie obtenir un nouveau matériel et y déplacer toute la base de données (et potentiellement le faire à nouveau).

• la suppression d'un client peut être tout aussi pénible, car vous devrez supprimer quelques% de lignes de très grandes tables, et ce ne sera pas bon marché.

• vous aurez probablement une large distribution des données clients (un client avec un milliard de lignes, un autre client avec 5 000). Cela peut conduire à des choses comme le reniflage de paramètres et des performances préjudiciables impliquant la cardinalité et la qualité du plan (car vous réutiliserez probablement les mêmes plans pour les mêmes requêtes contre des ensembles de données très différents).

• tous vos clients sont soumis aux mêmes SLA et plans HA / DR. Soit vous avez l'intégralité de la base de données en mode de récupération complète avec des sauvegardes de journaux de n minutes, soit vous êtes simple et vous vous fiez aux sauvegardes complètes + diff. Si vous devez revenir en arrière en raison d'une erreur client ou si vous devez récupérer la base de données à un moment donné, cela affecte chaque client.

• il peut y avoir des erreurs dans la récupération des données - des bogues dans les clauses where, par exemple, pourraient conduire un client à voir les données d'un autre client, ou toutes les données des autres clients.

• il peut y avoir des implications juridiques (certaines entreprises auront des exigences strictes en place pour que vous ne placiez pas leurs données dans la même base de données que toute autre entreprise, et en particulier celle de leurs concurrents).

• si la sécurité des données d'un client est importante, il est beaucoup plus facile d'y parvenir en utilisant la séparation de base de données que la séparation au sein d'une table.

Quelques avantages d'avoir chaque client dans une base de données distincte (ou au moins d'avoir plusieurs bases de données, chacune pour un groupe de clients):

• en termes de taille, il faudra environ la même taille sur le disque.
• la mise à l'échelle est plus facile, car vous pouvez simplement déplacer une base de données (ou plusieurs) vers un autre serveur.
• la suppression d'un client et de toutes ses données équivaut à peu près à DROP DATABASE.
• vous utilisez plus de mémoire pour les plans (ou vous avez moins de plans dans le cache par client), mais au moins ces plans sont pertinents pour les données dans leurs bases de données respectives et sont moins sujets aux problèmes de reniflement des statistiques / paramètres.
• vous pouvez facilement avoir différents SLA et plans DR, en plaçant certaines bases de données en totalité et d'autres en simple. La restauration ou la restauration d'un point dans le temps n'affecte que ce client.
• vous pouvez facilement placer différentes bases de données (par exemple, vos clients hautement prioritaires) sur des E / S plus rapides. Vous pouvez le faire dans une seule base de données avec des groupes de fichiers, mais c'est beaucoup plus délicat à gérer (au moins à mon humble avis).

Quelques inconvénients:

• En dehors de la taille, vous ne voudrez probablement pas avoir 50 000 bases de données sur une seule instance de SQL Server, ce qui signifie probablement une mise à l'échelle sur plusieurs serveurs.
• le temps de démarrage augmente car il y a une surcharge inhérente au démarrage de chaque base de données.
• l'application doit être un peu plus intelligente - au lieu d'avoir simplement CustomerID sur la clause where, elle doit se connecter dynamiquement à la base de données de CustomerID. Ce n'est pas difficile avec un bon niveau intermédiaire, mais c'est un changement.
• oui, vous disposez de plusieurs copies des mêmes tables et procédures, mais le code et le schéma sont identiques d'une base de données à l'autre, seules les données sont différentes. Ainsi, le déploiement de modifications de code / schéma n'est plus qu'une boucle au lieu d'une seule exécution.
• la maintenance est un peu différente lorsque vous gérez 50000 bases de données - encore une fois, la taille globale est à peu près la même mais le processus doit changer - vous ne pouvez pas simplement défragmenter / réindexer / sauvegarder toutes les 50000 bases de données à la fois. Cela dit, lors de mon travail précédent, j'ai géré des instances avec 500 à 1 000 bases de données identiques, et la différence entre la gestion de 3 bases de données identiques et 750 bases de données identiques est simplement le temps qu'il faut.