Da jetzt im Geschäftsleben einige Tabellen immer größer werden, ist der Druck beim Lesen sehr hoch (der Schreibbedarf ist relativ gering). Daher haben wir uns auf der Datenbankseite entschieden, einige Tabellen mit besonders großen Datenmengen aufzuteilen Tabellen, aber es gibt viele im Back-End-Code. Der Code/die Abfrage muss mit diesen Tabellen verknüpft werden.
Zum Beispiel haben wir jetzt SampleTable mit etwa 100 Millionen Daten. Wir haben es basierend auf der Logik in etwa 16 verschiedene Tabellen unterteilt: SampleTable 1, SampleTable2...SampleTable31,
Im vorherigen Code gab es eine Abfrage, die ähnlich war an:
select * from SampleTable join test_tableJetzt müssen wir diese Abfrage mehrmals ausführen und die Daten als Rückgabeergebnis aggregieren?
select * from SampleTable1 join test_tableGibt es eine bessere Methode oder Bibliotheksempfehlung? Gibt es eine bewährte Praxis oder einen Beispielcode?
Wenn wir in Zukunft mehrere Tabellen auf verschiedene Datenbankserver aufteilen möchten, müssen wir dann Datenbankverbindungen verschiedener DBs zum Back-End-Code hinzufügen
Die Grundidee und Sharding-Strategie des Datenbank-Shardings
In diesem Artikel geht es mehr um die Strategie des Datenbank-Shardings. Kann jemand ein tatsächliches Projektcode-Beispiel bereitstellen?
Datenbank-Sharding und JPA
Was kann man anstelle von SQL-Joins tun? -während-horizontaler Skalierung
Einige Antworten zum Stackoverflow
![[Web-Frontend] Node.js-Schnellstart](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
可以考虑引入数据库中间件
sharding-jdbc client级别
mycat-server server级别
朋友介绍 Spark 不错，支持 SQl 式的查询，1 亿条数据 0.5 秒左右返回结果
只针对目前我们项目中的情况： 在分表时根据hash算法落到特定表，然后取的时候先根据算法获取数据的分布位置，然后就是正常的select了
不建议连表查询
1.数据库资源比较宝贵，连表查询会占用大量的内存，导致数据库性能下降
2.不支持数据在多个数据库实例，分库情况无法处理，扩展性较差
通用做法是将连表查询，查分成多个单表查询，然后将结果在应用中汇总。
1.能够上述连表查询的问题
2.多次查询也可以在程序中对每一次查询的中间结果做处理，这是一个灵活性。
3.应用也可以随时扩展，更加灵活
如果是离线场景，建议使用MR(mapreduce)框架来处理，例如：hadoop等，相应的，需要将数据写入到hdfs上。
http://blog.csdn.net/tianyale...
详解分库分表