定義

分區(qū):在Mongo/ES和Solr被稱(chēng)為分片(shard),在HBase中稱(chēng)為區(qū)域(Region),Bigtable中是表塊(tablet),Cassandra和Riak中是虛節(jié)點(diǎn)(vnode),Counchbase中叫做虛桶(vBucket).
分區(qū)主要是為了可擴(kuò)展性,不同的分區(qū)可以放在非共享集群的不同節(jié)點(diǎn)上,每個(gè)節(jié)點(diǎn)可以獨(dú)立執(zhí)行對(duì)自己的查詢(xún).
分區(qū)通常與復(fù)制結(jié)合,使得每個(gè)分區(qū)副本存儲(chǔ)在多個(gè)節(jié)點(diǎn)上.即每條記錄雖然只屬于一個(gè)分區(qū),但是可以存儲(chǔ)在不同的節(jié)點(diǎn)上(復(fù)制)獲得容錯(cuò)能力.
偏斜(skew):分區(qū)不平衡,導(dǎo)致一些分區(qū)比其他分區(qū)有更多數(shù)據(jù)或者查詢(xún).偏斜會(huì)使數(shù)據(jù)分區(qū)效率下降,高負(fù)載分區(qū)稱(chēng)為熱點(diǎn)(hot spot).

如何分區(qū)

1. 根據(jù)鍵的范圍分區(qū)
   為每個(gè)分區(qū)指定一塊連續(xù)的鍵范圍.鍵的范圍不一定均勻分布,分區(qū)邊界需要依據(jù)數(shù)據(jù)調(diào)整.Bigtable和HBase使用了這種策略.
   優(yōu)點(diǎn):范圍掃描簡(jiǎn)單
   缺點(diǎn): 特定訪(fǎng)問(wèn)模式會(huì)導(dǎo)致熱點(diǎn),所以鍵值選取需要特殊考慮.
2. 根據(jù)鍵的散列值分區(qū)
   根據(jù)合適的鍵散列函數(shù),為每個(gè)分區(qū)分配一個(gè)散列范圍.分區(qū)邊界可以是均勻間隔的,也可以是偽隨機(jī)選擇的(一致性哈希).Cassandra和Mongo的散列分區(qū)模式使用這種策略.
   優(yōu)點(diǎn):減少熱點(diǎn)問(wèn)題.
   缺點(diǎn):不支持范圍查詢(xún).但是組合索引可以解決部分問(wèn)題,例如社交媒體網(wǎng)站上,基于(user_id, update_timestamp)建立索引,不同用戶(hù)在不同分區(qū)上,同一個(gè)用戶(hù)更新時(shí)間存儲(chǔ)在單個(gè)分區(qū)上.這樣可以有效檢索特定用戶(hù)在某個(gè)時(shí)間段內(nèi)的按時(shí)間戳排序的所有更新(使用鍵的一部分來(lái)標(biāo)識(shí)分區(qū)，而使用另一部分作為排序順序).
   雖然如此,哈希也不能完全消除熱點(diǎn)問(wèn)題.極端情況下,對(duì)于同一個(gè)鍵的大量讀寫(xiě),都會(huì)被路由到同一個(gè)分區(qū).可以采用鍵值加上隨機(jī)數(shù),從而存儲(chǔ)在不同分區(qū)中.但是讀時(shí),需要手動(dòng)合并.并且需要判斷是哪些鍵值才有必要進(jìn)行這項(xiàng)操作.

如何對(duì)二級(jí)索引分區(qū)

根據(jù)主鍵可以確定分區(qū),并且將請(qǐng)求路由到該分區(qū).而次級(jí)索引在分區(qū)中的問(wèn)題是不能整齊地映射到分區(qū).

1. 根據(jù)文檔的二級(jí)索引分區(qū)
   每個(gè)分區(qū)獨(dú)立維護(hù)自己的二級(jí)索引,僅覆蓋該分區(qū)中的文檔,因此也被稱(chēng)為本地索引.因此二級(jí)索引會(huì)被分散到各個(gè)分區(qū)上,利用其進(jìn)行查詢(xún)時(shí),需要將查詢(xún)發(fā)送到所有分區(qū)上再進(jìn)行合并.Mongo/Riak/Cassandra/ES/SolrCloud和VoltDB都使用這種方式.最好采用能在單個(gè)分區(qū)上提供二級(jí)索引查詢(xún)的分區(qū)方案.
2. 根據(jù)詞條的二級(jí)索引分區(qū)
   以待查找的關(guān)鍵字本身作為索引,建立覆蓋所有分區(qū)數(shù)據(jù)的全局索引,對(duì)關(guān)鍵詞進(jìn)行分區(qū).Riak的搜索功能和Oracle采用此種方式.
   優(yōu)點(diǎn): 對(duì)關(guān)鍵詞自身進(jìn)行分區(qū)利于范圍查詢(xún);對(duì)關(guān)鍵字哈希后進(jìn)行分區(qū)可以提供負(fù)載均衡.無(wú)需查詢(xún)所有分區(qū),只需要向包含關(guān)鍵詞的分區(qū)發(fā)出請(qǐng)求.
   缺點(diǎn): 寫(xiě)入比較慢.因?yàn)閱蝹€(gè)文檔可能會(huì)包含多個(gè)關(guān)鍵詞,從而影響多個(gè)分區(qū).同時(shí)也需要跨分區(qū)的分布式事務(wù)支持.

再平衡

當(dāng)現(xiàn)有的節(jié)點(diǎn)不能滿(mǎn)足實(shí)際情況時(shí),諸如查詢(xún)吞吐量增加,數(shù)據(jù)集變大,機(jī)器故障,需要將數(shù)據(jù)和請(qǐng)求從一個(gè)節(jié)點(diǎn)移動(dòng)到另一個(gè)節(jié)點(diǎn).

平衡策略

當(dāng)使用hash mod N,其中N是節(jié)點(diǎn)數(shù),節(jié)點(diǎn)發(fā)生變化,大量數(shù)據(jù)都要重新移動(dòng),并不是一種好的方案.如何只移動(dòng)必需數(shù)據(jù)?

1. 固定數(shù)量的分區(qū)
   為每個(gè)節(jié)點(diǎn)分配更多的分區(qū),分區(qū)總數(shù)量是固定的.當(dāng)有新節(jié)點(diǎn)加入時(shí),從其他節(jié)點(diǎn)獲取一些分區(qū),當(dāng)節(jié)點(diǎn)刪除時(shí),將這些分區(qū)還給其他節(jié)點(diǎn).只有分區(qū)在節(jié)點(diǎn)之間的移動(dòng),分區(qū)數(shù)量不會(huì)改變,鍵所對(duì)應(yīng)的分區(qū)也不會(huì)改變.
   某種程度上,可以通過(guò)為更強(qiáng)大的節(jié)點(diǎn)(高性能)分配更多的分區(qū),強(qiáng)制它們承受更多負(fù)載.Riak/ES/Couchbase/Voldemort使用這種方案.
   缺點(diǎn): 分區(qū)數(shù)量的設(shè)置需要充分的考量.
2. 動(dòng)態(tài)分區(qū)
   當(dāng)分區(qū)超過(guò)配置大小時(shí),會(huì)被分為兩個(gè)分區(qū).如果分區(qū)縮小,則與相鄰分區(qū)合并.HBase和Mongo 2.4都使用這種方法.
   優(yōu)點(diǎn): 分區(qū)數(shù)量適應(yīng)總數(shù)據(jù)量.
3. 根據(jù)節(jié)點(diǎn)比例分區(qū)
   固定數(shù)量分區(qū)中的每個(gè)分區(qū)大小與數(shù)據(jù)集大小成正比;動(dòng)態(tài)分區(qū)時(shí),分區(qū)數(shù)量與數(shù)據(jù)集大小成正比.這兩種情況下,分區(qū)數(shù)量都與節(jié)點(diǎn)數(shù)量無(wú)關(guān).
   Cassandra和Ketama采用與節(jié)點(diǎn)數(shù)量相關(guān)的分區(qū)方式: 每個(gè)節(jié)點(diǎn)具有固定數(shù)量的分區(qū).每個(gè)分區(qū)大小與數(shù)據(jù)集大小成比例增長(zhǎng),節(jié)點(diǎn)數(shù)量保持不變.當(dāng)節(jié)點(diǎn)增加時(shí),分區(qū)將再次變小(當(dāng)一個(gè)新節(jié)點(diǎn)加入集群時(shí)，它隨機(jī)選擇固定數(shù)量的現(xiàn)有分區(qū)進(jìn)行拆分，然后占有這些拆分分區(qū)中每個(gè)分區(qū)的一半，同時(shí)將每個(gè)分區(qū)的另一半留在原地).
   優(yōu)點(diǎn): 每個(gè)分區(qū)的大小趨于穩(wěn)定.

請(qǐng)求路由

發(fā)起請(qǐng)求時(shí)如何決定應(yīng)該將請(qǐng)求發(fā)送至哪個(gè)節(jié)點(diǎn)呢?

1. 允許客戶(hù)端聯(lián)系任何節(jié)點(diǎn),由節(jié)點(diǎn)之間轉(zhuǎn)發(fā)請(qǐng)求并回復(fù)
2. 由路由層進(jìn)行轉(zhuǎn)發(fā)
3. 客戶(hù)端知道分區(qū)和節(jié)點(diǎn)的分配,直接發(fā)送請(qǐng)求到對(duì)應(yīng)節(jié)點(diǎn)
   因此,許多分布式數(shù)據(jù)系統(tǒng)都依賴(lài)于一個(gè)獨(dú)立的協(xié)調(diào)服務(wù),比如ZooKeeper來(lái)跟蹤集群元數(shù)據(jù).Espresso/HBase/Solr和Kafka都使用ZK跟蹤分區(qū)分配.
   Mongo依賴(lài)于自己的配置服務(wù)器,Cassandra和Riak在節(jié)點(diǎn)之間采用Gossip協(xié)議傳播集群狀態(tài)變化.