Sharding - Pelaksanaan kod backend Java dan amalan terbaik selepas sharding pangkalan data dan pemotongan jadual
过去多啦不再A梦
过去多啦不再A梦 2017-06-23 09:12:49
0
5
964

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_table

Kini kita perlu melaksanakan pertanyaan ini beberapa kali dan mengagregatkan data sebagai hasil pulangan?

select * from  SampleTable1 join test_table

Adakah 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

过去多啦不再A梦
过去多啦不再A梦

membalas semua(5)
大家讲道理

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

ringa_lee

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

Muat turun terkini
Lagi>
kesan web
Kod sumber laman web
Bahan laman web
Templat hujung hadapan