數(shù)據(jù)庫分庫策略請(qǐng)教

最近在設(shè)計(jì)新系統(tǒng)的分庫，計(jì)劃在jdbc-shading, cobar 和 mycat三者之中選一個(gè)，想看看社區(qū)里面大神的意見。

jdbc-shading對(duì)單個(gè)簡單應(yīng)用比較友好，通過引入jar包，設(shè)置好規(guī)則，就可以了。但如果是一個(gè)服務(wù)群的話，是不是設(shè)計(jì)數(shù)據(jù)源的管理問題。另一方面，客戶端工具要連上去找數(shù)據(jù)的話，是不是還得一個(gè)節(jié)點(diǎn)一個(gè)節(jié)點(diǎn)的去連。

而cobar和mycat，通過代理的方式，隱藏了后端數(shù)據(jù)庫節(jié)點(diǎn)的細(xì)節(jié)，對(duì)外提供統(tǒng)一的數(shù)據(jù)源。對(duì)應(yīng)用和客戶端都比較友好，但是設(shè)計(jì)中間件，又要多一個(gè)高可用的考慮。

另外，在具體的分庫策略上也想請(qǐng)教一下，我的應(yīng)用是一個(gè)倉管應(yīng)用，數(shù)據(jù)權(quán)限通過倉庫編號(hào)做，大部分業(yè)務(wù)表都是帶有倉庫編號(hào)的，這種場景是不是比較適合采用mycat的ER分區(qū)策略。但是如果采用ER分區(qū)的話，會(huì)涉及一個(gè)熱點(diǎn)倉庫問題，個(gè)別倉庫的業(yè)務(wù)量大導(dǎo)致的IO和數(shù)據(jù)量在各個(gè)節(jié)點(diǎn)中的不均衡。

或者我采用一致性hash的分區(qū)方案，但是這樣，就基本放棄表連接了。

請(qǐng)教下各位，幫我想想怎么分比較合適，或者提供下各位所在系統(tǒng)的分區(qū)策略，以激發(fā)一下我的想象：）