建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
數(shù)據(jù)庫(kù)sharding有幾個(gè)主要的優(yōu)點(diǎn)：
在成都網(wǎng)站設(shè)計(jì)、網(wǎng)站建設(shè)中從網(wǎng)站色彩、結(jié)構(gòu)布局、欄目設(shè)置、關(guān)鍵詞群組等細(xì)微處著手，突出企業(yè)的產(chǎn)品/服務(wù)/品牌，幫助企業(yè)鎖定精準(zhǔn)用戶(hù)，提高在線(xiàn)咨詢(xún)和轉(zhuǎn)化，使成都網(wǎng)站營(yíng)銷(xiāo)成為有效果、有回報(bào)的無(wú)錫營(yíng)銷(xiāo)推廣。創(chuàng)新互聯(lián)公司專(zhuān)業(yè)成都網(wǎng)站建設(shè)十年了，客戶(hù)滿(mǎn)意度97.8%，歡迎成都創(chuàng)新互聯(lián)客戶(hù)聯(lián)系。
1. Database sharding提供了近似線(xiàn)性擴(kuò)展的架構(gòu)。可以隨著應(yīng)用的增長(zhǎng)線(xiàn)性的增加更多的服務(wù)器。
2. 提高了數(shù)據(jù)庫(kù)的可用性。如果只有一個(gè)數(shù)據(jù)庫(kù)，一旦down掉的話(huà)，對(duì)其所提供的service影響是100%，如果拆成10臺(tái)數(shù)據(jù)庫(kù)，那么一臺(tái)數(shù)據(jù)庫(kù)down掉的影響只有10%。
3. 小的數(shù)據(jù)庫(kù)壓力比較小，風(fēng)險(xiǎn)更小，性能更好。做過(guò)DBA的都知道，管理一臺(tái)3000 TPS的數(shù)據(jù)庫(kù)和一臺(tái)300 TPS的數(shù)據(jù)庫(kù)的壓力是完全不一樣的。
其缺點(diǎn)在于：
1. 首先要業(yè)務(wù)邏輯支持，并不是任何類(lèi)型的數(shù)據(jù)庫(kù)都支持拆分。如果業(yè)務(wù)邏輯不支持拆成幾個(gè)不相干的數(shù)據(jù)的話(huà)，拆開(kāi)后各個(gè)數(shù)據(jù)庫(kù)之間數(shù)據(jù)join會(huì)帶來(lái)額外的開(kāi)銷(xiāo)，而且隨著數(shù)據(jù)庫(kù)的增多，開(kāi)銷(xiāo)越來(lái)越大。
2. 更多的數(shù)據(jù)庫(kù)也帶來(lái)一些維護(hù)上的開(kāi)銷(xiāo)，例如升級(jí)數(shù)據(jù)庫(kù)，打patch等。
3. 因?yàn)閿?shù)據(jù)分散了，所以要提供機(jī)制能夠找到所需數(shù)據(jù)所在的數(shù)據(jù)庫(kù)。這也是本篇文章討論的重點(diǎn)，即數(shù)據(jù)的lookup技術(shù)。
下面重點(diǎn)討論lookup技術(shù)。數(shù)據(jù)被分散在不同的數(shù)據(jù)庫(kù)中，當(dāng)應(yīng)用需要查詢(xún)數(shù)據(jù)時(shí)，要能夠定位到相應(yīng)的數(shù)據(jù)庫(kù)中查詢(xún)。如果沒(méi)有Lookup機(jī)制，則需要到每一個(gè)數(shù)據(jù)庫(kù)中查詢(xún)，這樣的話(huà)就不可能做到線(xiàn)性擴(kuò)展，數(shù)據(jù)庫(kù)Sharding也就失去了其主要的優(yōu)勢(shì)。
Lookup技術(shù)主要從以下幾個(gè)方面來(lái)考慮：
1. 成本
2. 效率
3. 再次拆分的難度
4. 是否支持在線(xiàn)拆分
我接觸到或者想到的Lookup技術(shù)有以下幾種，下面分別討論其優(yōu)缺點(diǎn)。
1. 建立Lookup數(shù)據(jù)庫(kù)
這是很自然想到的一種方法。Lookup數(shù)據(jù)庫(kù)中記錄 (ID, Server)的對(duì)應(yīng)關(guān)系。
其優(yōu)點(diǎn)在于靈活性很高，數(shù)據(jù)可以存放在任何一個(gè)數(shù)據(jù)庫(kù)中，可以在不同的數(shù)據(jù)庫(kù)之間在線(xiàn)遷移數(shù)據(jù)來(lái)平衡數(shù)據(jù)庫(kù)壓力，遷移數(shù)據(jù)時(shí)同時(shí)更新Lookup數(shù)據(jù)庫(kù)中相應(yīng)的記錄。
缺點(diǎn)也很明顯，就是需要一套Lookup數(shù)據(jù)庫(kù)來(lái)支持，有不小的額外開(kāi)銷(xiāo)。Lookup數(shù)據(jù)庫(kù)的數(shù)據(jù)必須集中存放，不好再做水平切割。雖然其數(shù)據(jù)結(jié)構(gòu)簡(jiǎn)單，存放的數(shù)據(jù)量并不大，但是所有的應(yīng)用都需要到Lookup數(shù)據(jù)庫(kù)上查找數(shù)據(jù)，其查詢(xún)的頻率很高。而且Lookup數(shù)據(jù)庫(kù)在這個(gè)方案中也成為了一個(gè)故障節(jié)點(diǎn)。所以不能用一臺(tái)數(shù)據(jù)庫(kù)做Lookup DB，否則前面提到的sharding數(shù)據(jù)庫(kù)可用性的優(yōu)勢(shì)又失去了。我們可以用Master/Slave的方式來(lái)實(shí)現(xiàn)Lookup數(shù)據(jù)庫(kù)的scalability和availability。Master數(shù)據(jù)庫(kù)提供寫(xiě)操作，Slave數(shù)據(jù)庫(kù)提供讀的操作。
對(duì)于oracle來(lái)說(shuō)，可以采用復(fù)制軟件來(lái)實(shí)現(xiàn)master和slave之間的同步，例如shareplex，也可以采用oracle logical standby或者oracle active physical standby（11g）來(lái)實(shí)現(xiàn)。
MySQL數(shù)據(jù)庫(kù)的話(huà)，memory engine很適合做Slave服務(wù)器，因?yàn)長(zhǎng)ookup表的數(shù)據(jù)庫(kù)不大，可以放在內(nèi)存中，而且hash index很適合等式查找。Memory engine可以支持大并發(fā)量的查詢(xún)。Mater數(shù)據(jù)庫(kù)可以采用Innodb，文檔中提到在高版本的MySQL中支持不同storage engine之間的復(fù)制。實(shí)際應(yīng)用中不知道有沒(méi)有公司這么使用。
2. 采用劃分區(qū)間的方式
將數(shù)據(jù)按照range來(lái)劃分。比方說(shuō)以1萬(wàn)為一個(gè)區(qū)間長(zhǎng)度，ID在1~10000的在數(shù)據(jù)庫(kù)D1中，10001~20000的在數(shù)據(jù)庫(kù)D2中，20001~30000在數(shù)據(jù)庫(kù)D3中，依此類(lèi)推。當(dāng)分配的ID用完或者新增服務(wù)器時(shí)，繼續(xù)分配后面的ID供其使用?？梢酝ㄟ^(guò)sequence來(lái)實(shí)現(xiàn)。
其優(yōu)點(diǎn)在于不需要額外的開(kāi)銷(xiāo)，應(yīng)用通過(guò)簡(jiǎn)單的映射就可以得知數(shù)據(jù)存放于哪個(gè)數(shù)據(jù)庫(kù)中，缺點(diǎn)在于各個(gè)數(shù)據(jù)庫(kù)之間很難實(shí)現(xiàn)在線(xiàn)的數(shù)據(jù)遷移。如果應(yīng)用的增長(zhǎng)不是因?yàn)閿?shù)據(jù)量增長(zhǎng)而增長(zhǎng)，而是因?yàn)閳?zhí)行次數(shù)的增加的話(huà)，很難做到在線(xiàn)的壓力平衡。另外當(dāng)區(qū)間內(nèi)分配的ID數(shù)用完了，需要DBA手工分配新的區(qū)間。
3. 采用hash函數(shù)的方式
比方說(shuō)最簡(jiǎn)單的hash函數(shù)—mod函數(shù)。將數(shù)據(jù)進(jìn)行mod(ID, 13860) (13860= 2*3*5*6*7*11)，如果有十臺(tái)數(shù)據(jù)庫(kù)，每個(gè)數(shù)據(jù)庫(kù)中存放1386個(gè)mod。將mod和數(shù)據(jù)庫(kù)之間的mapping關(guān)系存放于數(shù)據(jù)庫(kù)中，應(yīng)用服務(wù)器可以將其load進(jìn)自己的內(nèi)存中（這個(gè)表很?。?。當(dāng)新增服務(wù)器時(shí)，從各個(gè)數(shù)據(jù)庫(kù)中轉(zhuǎn)移一部分mod到新的服務(wù)器上。
其優(yōu)點(diǎn)在于不需要額外的開(kāi)銷(xiāo)，可以通過(guò)查找應(yīng)用端很小的內(nèi)存鏈表就能獲知數(shù)據(jù)存放的位置，缺點(diǎn)在于當(dāng)新增服務(wù)器后轉(zhuǎn)移數(shù)據(jù)過(guò)程中要保持?jǐn)?shù)據(jù)的同步，需要同步機(jī)制。
4. 采用hash函數(shù)和Lookup數(shù)據(jù)庫(kù)相結(jié)合的方式
基本劃分的方法和第三種一樣，但是多了一套Lookup數(shù)據(jù)庫(kù)來(lái)提供miss查詢(xún)。這套Lookup數(shù)據(jù)庫(kù)解決了方法三中新增服務(wù)器數(shù)據(jù)同步的問(wèn)題。新增服務(wù)器轉(zhuǎn)移數(shù)據(jù)時(shí)就不需要同步了，而是采用move的方式，這樣在舊的服務(wù)器中miss了，但可以通過(guò)Lookup數(shù)據(jù)庫(kù)來(lái)定位到新的服務(wù)器，當(dāng)單個(gè)mod完全轉(zhuǎn)移了，可以更新mapping表，這樣就可以直接定位到新的服務(wù)器上。
不知道大家是如何實(shí)現(xiàn)Lookup機(jī)制的，有什么好的方法或想法非常歡迎大家來(lái)分享。
文章題目：數(shù)據(jù)庫(kù)shardingLookup技術(shù)探討
文章轉(zhuǎn)載：http://fisionsoft.com.cn/article/dpsedis.html
