問題描述

現(xiàn)在業(yè)務中由于一些表越來越大，read的時候壓力很大（write的需求比較小），所以在數(shù)據(jù)庫端決定把一些數(shù)據(jù)量特別大的表切表， 但是在后端代碼中有很多代碼／query需要做join這些表，請問這樣的情況下大家是怎么樣解決的？

比如我們現(xiàn)在有 SampleTable 有大概1億條數(shù)據(jù)，我們根據(jù)邏輯切成了大概16個不同的表：SampleTable 1,SampleTable2...SampleTable31,以前代碼中有query 類似于:

select * from SampleTable join test_table

現(xiàn)在需要執(zhí)行這樣的query 多次然后把數(shù)據(jù)聚合起來做為返回結(jié)果嗎?

select * from SampleTable1 join test_table

有沒有更好的方法或者library推薦?有沒有什么beset practice或者sample code？

如果之后我們要多個表拆分到不同的database server上,是否在后端代碼得加上不同db 的數(shù)據(jù)庫連接?

數(shù)據(jù)庫Sharding的基本思想和切分策略這篇文章更多的是數(shù)據(jù)庫切分的策略,是否有人能提供下實際的項目code sample?Database sharding and JPAwhat-to-do-instead-of-sql-joins-while-scaling-horizontally

stackoverflow 上的一些答案

問題解答

可以考慮引入數(shù)據(jù)庫中間件sharding-jdbc client級別mycat-server server級別

朋友介紹 Spark 不錯，支持 SQl 式的查詢，1 億條數(shù)據(jù) 0.5 秒左右返回結(jié)果

只針對目前我們項目中的情況： 在分表時根據(jù)hash算法落到特定表，然后取的時候先根據(jù)算法獲取數(shù)據(jù)的分布位置，然后就是正常的select了

不建議連表查詢1.數(shù)據(jù)庫資源比較寶貴，連表查詢會占用大量的內(nèi)存，導致數(shù)據(jù)庫性能下降2.不支持數(shù)據(jù)在多個數(shù)據(jù)庫實例，分庫情況無法處理，擴展性較差

通用做法是將連表查詢，查分成多個單表查詢，然后將結(jié)果在應用中匯總。1.能夠上述連表查詢的問題2.多次查詢也可以在程序中對每一次查詢的中間結(jié)果做處理，這是一個靈活性。3.應用也可以隨時擴展，更加靈活

如果是離線場景，建議使用MR(mapreduce)框架來處理，例如：hadoop等，相應的，需要將數(shù)據(jù)寫入到hdfs上。

http://blog.csdn.net/tianyale...詳解分庫分表