數(shù)據(jù)庫sharding有幾個(gè)主要的優(yōu)點(diǎn)：

1. Database sharding提供了近似線性擴(kuò)展的架構(gòu)?？梢噪S著應(yīng)用的增長線性的增加更多的服務(wù)器。

2. 提高了數(shù)據(jù)庫的可用性。如果只有一個(gè)數(shù)據(jù)庫，一旦down掉的話，對其所提供的service影響是100%，如果拆成10臺數(shù)據(jù)庫，那么一臺數(shù)據(jù)庫down掉的影響只有10%。

3. 小的數(shù)據(jù)庫壓力比較小，風(fēng)險(xiǎn)更小，性能更好。做過DBA的都知道，管理一臺3000 TPS的數(shù)據(jù)庫和一臺300 TPS的數(shù)據(jù)庫的壓力是完全不一樣的。

其缺點(diǎn)在于：

1. 首先要業(yè)務(wù)邏輯支持，并不是任何類型的數(shù)據(jù)庫都支持拆分。如果業(yè)務(wù)邏輯不支持拆成幾個(gè)不相干的數(shù)據(jù)的話，拆開后各個(gè)數(shù)據(jù)庫之間數(shù)據(jù)join會帶來額外的開銷，而且隨著數(shù)據(jù)庫的增多，開銷越來越大。

2. 更多的數(shù)據(jù)庫也帶來一些維護(hù)上的開銷，例如升級數(shù)據(jù)庫，打patch等。

3. 因?yàn)閿?shù)據(jù)分散了，所以要提供機(jī)制能夠找到所需數(shù)據(jù)所在的數(shù)據(jù)庫。這也是本篇文章討論的重點(diǎn)，即數(shù)據(jù)的lookup技術(shù)。

下面重點(diǎn)討論lookup技術(shù)。數(shù)據(jù)被分散在不同的數(shù)據(jù)庫中，當(dāng)應(yīng)用需要查詢數(shù)據(jù)時(shí)，要能夠定位到相應(yīng)的數(shù)據(jù)庫中查詢。如果沒有Lookup機(jī)制，則需要到每一個(gè)數(shù)據(jù)庫中查詢，這樣的話就不可能做到線性擴(kuò)展，數(shù)據(jù)庫Sharding也就失去了其主要的優(yōu)勢。

Lookup技術(shù)主要從以下幾個(gè)方面來考慮：

1. 成本

2. 效率

3. 再次拆分的難度

4. 是否支持在線拆分

我接觸到或者想到的Lookup技術(shù)有以下幾種，下面分別討論其優(yōu)缺點(diǎn)。

1. 建立Lookup數(shù)據(jù)庫

這是很自然想到的一種方法。Lookup數(shù)據(jù)庫中記錄 (ID, Server)的對應(yīng)關(guān)系。
其優(yōu)點(diǎn)在于靈活性很高，數(shù)據(jù)可以存放在任何一個(gè)數(shù)據(jù)庫中，可以在不同的數(shù)據(jù)庫之間在線遷移數(shù)據(jù)來平衡數(shù)據(jù)庫壓力，遷移數(shù)據(jù)時(shí)同時(shí)更新Lookup數(shù)據(jù)庫中相應(yīng)的記錄。

缺點(diǎn)也很明顯，就是需要一套Lookup數(shù)據(jù)庫來支持，有不小的額外開銷。Lookup數(shù)據(jù)庫的數(shù)據(jù)必須集中存放，不好再做水平切割。雖然其數(shù)據(jù)結(jié)構(gòu)簡單，存放的數(shù)據(jù)量并不大，但是所有的應(yīng)用都需要到Lookup數(shù)據(jù)庫上查找數(shù)據(jù)，其查詢的頻率很高。而且Lookup數(shù)據(jù)庫在這個(gè)方案中也成為了一個(gè)故障節(jié)點(diǎn)。所以不能用一臺數(shù)據(jù)庫做Lookup DB，否則前面提到的sharding數(shù)據(jù)庫可用性的優(yōu)勢又失去了。我們可以用Master/Slave的方式來實(shí)現(xiàn)Lookup數(shù)據(jù)庫的scalability和availability。Master數(shù)據(jù)庫提供寫操作，Slave數(shù)據(jù)庫提供讀的操作。

對于oracle來說，可以采用復(fù)制軟件來實(shí)現(xiàn)master和slave之間的同步，例如shareplex，也可以采用oracle logical standby或者oracle active physical standby（11g）來實(shí)現(xiàn)。

MySQL數(shù)據(jù)庫的話，memory engine很適合做Slave服務(wù)器，因?yàn)長ookup表的數(shù)據(jù)庫不大，可以放在內(nèi)存中，而且hash index很適合等式查找。Memory engine可以支持大并發(fā)量的查詢。Mater數(shù)據(jù)庫可以采用Innodb，文檔中提到在高版本的MySQL中支持不同storage engine之間的復(fù)制。實(shí)際應(yīng)用中不知道有沒有公司這么使用。

2. 采用劃分區(qū)間的方式

將數(shù)據(jù)按照range來劃分。比方說以1萬為一個(gè)區(qū)間長度，ID在1~10000的在數(shù)據(jù)庫D1中，10001~20000的在數(shù)據(jù)庫D2中，20001~30000在數(shù)據(jù)庫D3中，依此類推。當(dāng)分配的ID用完或者新增服務(wù)器時(shí)，繼續(xù)分配后面的ID供其使用。可以通過sequence來實(shí)現(xiàn)。
其優(yōu)點(diǎn)在于不需要額外的開銷，應(yīng)用通過簡單的映射就可以得知數(shù)據(jù)存放于哪個(gè)數(shù)據(jù)庫中，缺點(diǎn)在于各個(gè)數(shù)據(jù)庫之間很難實(shí)現(xiàn)在線的數(shù)據(jù)遷移。如果應(yīng)用的增長不是因?yàn)閿?shù)據(jù)量增長而增長，而是因?yàn)閳?zhí)行次數(shù)的增加的話，很難做到在線的壓力平衡。另外當(dāng)區(qū)間內(nèi)分配的ID數(shù)用完了，需要DBA手工分配新的區(qū)間。

3. 采用hash函數(shù)的方式

比方說最簡單的hash函數(shù)—mod函數(shù)。將數(shù)據(jù)進(jìn)行mod(ID, 13860) (13860= 2*3*5*6*7*11)，如果有十臺數(shù)據(jù)庫，每個(gè)數(shù)據(jù)庫中存放1386個(gè)mod。將mod和數(shù)據(jù)庫之間的mapping關(guān)系存放于數(shù)據(jù)庫中，應(yīng)用服務(wù)器可以將其load進(jìn)自己的內(nèi)存中（這個(gè)表很小）。當(dāng)新增服務(wù)器時(shí)，從各個(gè)數(shù)據(jù)庫中轉(zhuǎn)移一部分mod到新的服務(wù)器上。
其優(yōu)點(diǎn)在于不需要額外的開銷，可以通過查找應(yīng)用端很小的內(nèi)存鏈表就能獲知數(shù)據(jù)存放的位置，缺點(diǎn)在于當(dāng)新增服務(wù)器后轉(zhuǎn)移數(shù)據(jù)過程中要保持?jǐn)?shù)據(jù)的同步，需要同步機(jī)制。

4. 采用hash函數(shù)和Lookup數(shù)據(jù)庫相結(jié)合的方式

基本劃分的方法和第三種一樣，但是多了一套Lookup數(shù)據(jù)庫來提供miss查詢。這套Lookup數(shù)據(jù)庫解決了方法三中新增服務(wù)器數(shù)據(jù)同步的問題。新增服務(wù)器轉(zhuǎn)移數(shù)據(jù)時(shí)就不需要同步了，而是采用move的方式，這樣在舊的服務(wù)器中miss了，但可以通過Lookup數(shù)據(jù)庫來定位到新的服務(wù)器，當(dāng)單個(gè)mod完全轉(zhuǎn)移了，可以更新mapping表，這樣就可以直接定位到新的服務(wù)器上。

不知道大家是如何實(shí)現(xiàn)Lookup機(jī)制的，有什么好的方法或想法非常歡迎大家來分享。

【編輯推薦】

1. 如何在DB2中提高IMPORT性能
2. 使用DB2必須了解的幾個(gè)知識點(diǎn)
3. DB2下數(shù)據(jù)轉(zhuǎn)移任務(wù)操作實(shí)例