Affinage des données utilisateur sur plusieurs bases de données sur un même serveur de base de données

Question

Je suis un programmeur autodidacte et j'ai toujours suivi certains paramètres de conception qui reposaient plus sur le bon sens que sur la recherche pour construire des systèmes évolutifs. Cependant, je viens de réaliser qu'un composant de mon système pourrait ne pas être nécessaire.

De manière générale, je casse les données utilisateur en groupes et les affecte à des serveurs mysql spécifiques. Lorsqu'un serveur de contenu derrière un équilibreur de charge reçoit une requête, j'utilise les données de la requête (comme un ID utilisateur) pour résoudre la base de données où les données des utilisateurs sont stockées en interrogeant une table centrale stockée sur DynamoDB qui peut gérer une charge folle.

Cependant, j'attribue également les données utilisateur aux bases de données du serveur. Comme j'ai 100 bases de données dans chaque serveur qui ont toutes la même structure de table, et j'affecterai 250 utilisateurs à chaque base de données. La logique était à l'origine qu'une table où chaque utilisateur a 2k entrées va courir beaucoup plus vite avec 500k entrées de 50 millions. Cependant, il m'est apparu que le découpage des données utilisateur de cette façon pourrait ne pas avoir de sens du tout. Les index sont plutôt efficaces. Je suis sûr que la base de données avait en fait une sorte de logique interne qui lui permet d'accéder aux données à peu près la même vitesse, n'est-ce pas? Cela fait dix ans que je le fais, et je viens de me rendre compte que cela pourrait ne pas être nécessaire du tout. Des pensées? Puis-je simplement créer une base de données avec toutes mes tables ou dois-je continuer à faire les choses comme je l'ai toujours fait, en partageant 100 bases de données sur un serveur?

Answer 1

Ceci est un peu théorique, donc il pourrait être utile de comprendre l'idée de Big-O complexity aka Time Complexity.

Une recherche d'index B-Tree en cluster pour un seul élément est O (log (n)) où n est le nombre de lignes dans la table. DynamoDB est une implémentation basée sur le hachage, qui le rapproche beaucoup de O (1), ce qui signifie que ses performances ne changent pas sensiblement avec la taille du contenu. Maintenant pour les maths, log (500k) = 5.7, où log (50mil) = 7.7 Les recherches sur une seule ligne évoluent très bien, tant que vous évitez les hits sur le disque pour charger l'index dans la mémoire. Donc, vous parlez d'une différence de 25% pour une recherche sur une seule ligne. Ce qui est important, mais probablement moins que l'overhead d'un aller-retour vers un autre système db (comme DynamoDB).

Bien sûr, votre kilométrage peut varier, car il y a des soucis comme conserver l'index en mémoire, etc ... Il est donc possible que vous voyiez une différence dans un environnement de production. Je recommande fortement de configurer un test et de vérifier vos performances.