Sharding - Implémentation du code backend Java et meilleures pratiques après le partitionnement de la base de données et la découpe des tables

Question

Maintenant en entreprise, comme certaines tables deviennent de plus en plus grandes, la pression est très forte lors de la lecture (la demande d'écriture est relativement faible), donc côté base de données, nous avons décidé de découper certaines tables contenant des quantités de données particulièrement importantes en tables, mais il y en a beaucoup dans le code back-end. Le code/requête doit être joint à ces tables. Comment résolvez-vous cette situation ?

Par exemple, nous avons maintenant SampleTable avec environ 100 millions de données. Nous l'avons divisé en environ 16 tables différentes en fonction de la logique : SampleTable 1, SampleTable2...SampleTable31,
Il y avait une requête dans le code précédent, qui était similaire. à :

select * from  SampleTable join test_table

Nous devons maintenant exécuter cette requête plusieurs fois et agréger les données comme résultat de retour ?

select * from  SampleTable1 join test_table

Existe-t-il une meilleure méthode ou une recommandation de bibliothèque ? Existe-t-il une pratique difficile ou un exemple de code ?

Si nous souhaitons diviser plusieurs tables en différents serveurs de base de données à l'avenir, devons-nous ajouter des connexions de base de données de différentes bases de données au code back-end ?

L'idée de base et la stratégie de partitionnement du partage de base de données

Cet article porte davantage sur la stratégie de partage de base de données. Quelqu'un peut-il fournir un exemple de code de projet réel ?
Partage de base de données et JPA
que faire à la place des jointures SQL. -pendant-une-mise à l'échelle-horizontale

Quelques réponses sur stackoverflow

Answer 1

Vous pouvez envisager d'introduire un middleware de base de données
au niveau client sharding-jdbc
au niveau du serveur mycat-server

Answer 2

Un ami m'a recommandé Spark, qui prend en charge les requêtes de style SQL et renvoie les résultats en 0,5 seconde environ pour 100 millions de données

Answer 3

Uniquement pour la situation actuelle de notre projet : lors de la division des tables, elle tombe sur une table spécifique selon l'algorithme de hachage, puis lors de la récupération, obtenez d'abord la position de distribution des données selon l'algorithme, puis la sélection normale est terminé

Answer 4

La requête de jointure de table n'est pas recommandée
1. Les ressources de la base de données sont relativement précieuses et la requête de jointure de table occupera beaucoup de mémoire, ce qui entraînera une réduction des performances de la base de données
2 Les données ne sont pas prises en charge dans plusieurs instances de base de données et la situation de sous-base de données. la base de données ne peut pas être gérée et l'évolutivité est médiocre

L'approche courante consiste à diviser la requête de jointure de table en plusieurs requêtes de table unique, puis à résumer les résultats dans l'application.
1. Capable de résoudre les problèmes ci-dessus de jointure de requêtes de table
2 Pour les requêtes multiples, les résultats intermédiaires de chaque requête peuvent également être traités dans le programme, ce qui est une flexibilité.
3. L'application peut également être étendue à tout moment, la rendant plus flexible

S'il s'agit d'un scénario hors ligne, il est recommandé d'utiliser le framework MR (mapreduce) pour le gérer, tel que hadoop, etc. En conséquence, les données doivent être écrites sur HDFS.

Answer 5

http://blog.csdn.net/tianyale...
Explication détaillée de la sous-base de données et de la table