分佈式系統-分區(partition)

分區(Partition)

什麼是分區?

分區主要是爲了可擴展性。不一樣的分區能夠放在不共享集羣中的不一樣節點上

爲何要分區?

• 提高系統的擴展性
• 提高系統的可用性(節點故障只會引發一部分數據丟失)

*水平分區與垂直分區

水平切分經常使用於分佈式系統

• 不存在單庫數據量過大、高併發的性能瓶頸，提高系統穩定性和負載能力
• 應用端改造較小，不須要拆分業務模塊

垂直切分經常使用於DBMS

• 解決業務系統層面的耦合，業務清晰
• 與微服務的治理相似，也能對不一樣業務的數據進行分級管理、維護、監控、擴展等
• 高併發場景下，垂直切分必定程度的提高IO、數據庫鏈接數、單機硬件資源的瓶頸

Synonymes(同義詞)

分區partition在不一樣數據庫有不一樣的稱謂

• Shard [分片] MongoDB,Elasticsearch
• Region[區域] HBase
• tablet[表塊] BigTable
• vnode [虛節點] Cassandra,Riak

分區與複製

分區一般與複製結合使用，使得每一個分區的副本存儲在多個節點上。 這意味着，即便每條記錄屬於一個分區，它仍然能夠存儲在多個不一樣的節點上以得到容錯能力。

鍵值數據的分區

分區目標是將數據和查詢負載均勻分佈在各個節點上。若是每一個節點均勻分享數據和負載，那麼理論上10個節點應該可以處理10倍的數據量和10倍的單個節點的讀寫吞吐量。

兩個概念 skew&hot spot

• skew:一些分區比其餘分區有更多的數據或查詢，咱們稱之爲偏斜
• hot spot:不均衡致使的高負載的分區被稱爲熱點

根據鍵的範圍分區(Range Partitioning)

一種分區的方法是爲每一個分區指定一塊連續的鍵範圍（從最小值到最大值）

拿mysql range partition爲例,建立一個employees表

CREATE TABLE employees (
    id INT NOT NULL,
    fname VARCHAR(30),
    lname VARCHAR(30),
    hired DATE NOT NULL DEFAULT '1970-01-01',
    separated DATE NOT NULL DEFAULT '9999-12-31',
    job_code INT NOT NULL,
    store_id INT NOT NULL
)
PARTITION BY RANGE (store_id) (
    PARTITION p0 VALUES LESS THAN (6),
    PARTITION p1 VALUES LESS THAN (11),
    PARTITION p2 VALUES LESS THAN (16),
    PARTITION p3 VALUES LESS THAN (21)
);
複製代碼

能夠看到store_id = 1~5被分到p0分區,6-11被分到p2分區,而後依次類推

range partition的優缺點

• 支持範圍查詢,好比按照時間散列
• load skew

根據鍵的散列分區

hash partition 哈希散列

• Map the (skewed) range of keys to a uniformly distributed range of hashes

一致性hash

上篇文章已經介紹過一致性hash的內容了,再也不贅述。

分片與次級索引

基於文檔的分區（document-based）和基於關鍵詞（term-based）的分區。

local index

Every partition manages its own index with all pointers to local data items

• Vertically(垂直) partitioned index
• Insert/update/delete: performed locally
• Select: queries all partition indexes

適用於OnLine Transaction Processing(聯機事務處理過程)

global index

Index entries are partitioned by their key independently from local data items

• Horizontally partitioned index
• Insert/update/delete: require remote updates
• Select: queries only one partition index

適用於OnLine Analytical Processing(分析處理過程)

分區再平衡

Things change:

• Query load → add more CPUs
• Data size → add more disks and RAM
• Nodes fail → other nodes need to take over
• Require to move data around (rebalancing)!

反面教材 hash mod N

若是n改變了,那麼對於mod n的數值也會隨着變動 好比:

123456 % 10 = 6, 123456 % 11 = 3, 123456 % 12 = 0,

固定數量的分區

若是一個節點被添加到集羣中，新節點能夠從當前每一個節點中竊取一些分區，直到分區再次公平分配

動態分區

• 建立一些初始分區數
• 若是分區超過某個最大大小閾值，將其拆分開來
• 若是分區小於最小的閾值,將其合併

相似於B樹數據結構

按節點比例分區

請求路由

如今咱們已經將數據集分割到多個機器上運行的多個節點上。可是仍然存在一個未解決的問題。當客戶端想要發出請求時，如何知道要鏈接哪一個節點？隨着分區從新平衡，分區對節點的分配也發生變化。

這個問題能夠歸納爲 服務發現(service discovery)

• 循環策略的負載均衡（Round-Robin Load Balancer）若是節點剛好有請求的分區,則直接處理,不然轉發到適當的節點
• 首先將全部來自客戶端的請求發送到路由層，它決定了應該處理請求的節點，並相應地轉
• 要求客戶端知道分區和節點的分配

許多分佈式數據系統都依賴於一個獨立的協調服務，好比ZooKeeper來跟蹤集羣元數據。每一個節點在ZooKeeper中註冊本身，ZooKeeper維護分區到節點的可靠映射。

Cassandra和Riak採起不一樣的方法：他們在節點之間使用流言協議（gossip protocol） 來傳播羣集狀態的變化。請求能夠發送到任意節點，該節點會轉發到包含所請求的分區的適當節點