問題描述

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

比如我們現(xiàn)在有 SampleTable 有大概1億條數(shù)據(jù)，我們根據(jù)邏輯切成了大概16個(gè)不同的表：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？

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

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

stackoverflow 上的一些答案

問題解答

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

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

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

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

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

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

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