Sekarang dalam perniagaan, memandangkan sesetengah jadual semakin besar dan besar, tekanan sangat tinggi apabila membaca (permintaan untuk menulis agak kecil), jadi dari segi pangkalan data, kami memutuskan untuk memotong beberapa jadual dengan jumlah data yang besar ke dalam jadual, tetapi terdapat banyak dalam kod bahagian belakang Kod/pertanyaan perlu digabungkan dengan jadual ini.
Sebagai contoh, kami kini mempunyai SampleTable dengan kira-kira 100 juta keping data Kami membahagikannya kepada kira-kira 16 jadual berbeza berdasarkan logik: SampleTable 1, SampleTable2...SampleTable31,
Terdapat pertanyaan dalam kod sebelumnya, yang serupa. kepada:
select * from SampleTable join test_tableKini kita perlu melaksanakan pertanyaan ini beberapa kali dan mengagregatkan data sebagai hasil pulangan?
select * from SampleTable1 join test_tableAdakah terdapat kaedah atau cadangan perpustakaan yang lebih baik?
Jika kita ingin membahagikan berbilang jadual kepada pelayan pangkalan data yang berbeza pada masa hadapan, adakah kita perlu menambah sambungan pangkalan data DB yang berbeza pada kod bahagian belakang
Idea asas dan strategi sharding pangkalan data Sharding
Artikel ini lebih lanjut mengenai strategi sharding pangkalan data Bolehkah sesiapa memberikan sampel kod projek sebenar?
Sarding pangkalan data dan JPA
what-to-do-bukan-sql-joins. -sambil-sambil-skala-mendatar
Beberapa jawapan pada stackoverflow
![[Web front-end] Permulaan pantas Node.js](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
Anda boleh mempertimbangkan untuk memperkenalkan perisian tengah pangkalan data
sharding-jdbc tahap klien
mycat-server tahap pelayan
Seorang rakan mengesyorkan Spark, yang menyokong pertanyaan gaya SQL dan mengembalikan hasil dalam kira-kira 0.5 saat untuk 100 juta keping data
Hanya untuk situasi semasa dalam projek kami: apabila membahagikan jadual, ia jatuh ke jadual tertentu mengikut algoritma cincang, dan kemudian apabila mengambil, mula-mula dapatkan kedudukan pengedaran data mengikut algoritma, dan kemudian pemilihan biasa ialah selesai
Sertai pertanyaan jadual tidak digalakkan
1 Sumber pangkalan data adalah agak berharga, dan pertanyaan gabungan jadual akan menduduki banyak memori, mengakibatkan prestasi pangkalan data berkurangan
2 Data tidak disokong dalam berbilang contoh pangkalan data, dan situasi sub- pangkalan data tidak dapat dikendalikan, dan skalabiliti adalah lemah
Pendekatan biasa adalah untuk membahagikan pertanyaan jadual gabungan kepada berbilang pertanyaan jadual tunggal, dan kemudian meringkaskan keputusan dalam aplikasi.
1. Dapat menyelesaikan masalah menyertai pertanyaan jadual di atas
2 Untuk pertanyaan berbilang, hasil perantaraan setiap pertanyaan juga boleh diproses dalam program, yang merupakan fleksibiliti.
3 Aplikasi ini juga boleh dikembangkan pada bila-bila masa, menjadikannya lebih fleksibel
Jika ia adalah senario luar talian, adalah disyorkan untuk menggunakan rangka kerja MR (mapreduce) untuk mengendalikannya, seperti hadoop, dll. Sehubungan itu, data perlu ditulis ke HDFS.
http://blog.csdn.net/tianyale...
Penjelasan terperinci sub-pangkalan data dan jadual