目錄

1. 范圍分區vs哈希分區
2. 二級索引的全局所以和分區索引
3. 分區重平衡（海量，動態，按節點比例）
4. 請求路由 （3種router方案，zookeeper vs gossip）

image.png

分區策略

數據分區的目的是：將數據和查詢負載均勻地分布在節點上。（其實副本也有同樣的效果，取決于副本同步機制）而如果數據分區不公平，則會出現某些分區的數據或查詢比其他分區要多，我們稱之為偏斜。數據偏斜就使得分區效果變差，導致負載不均衡形成分區熱點。 所以分區策略通常以分區均勻為考量，接下來我們介紹幾種常見的分區策略：

范圍分區

范圍分區是分配一個連續的范圍鍵，如同幾冊百科全書一般。如果知道范圍之間的邊界，就可以很容易地確定哪個分區包含給定的鍵。如果您還知道哪個分區被分配到哪個節點，那么您可以直接將請求發送到適當的節點。

多冊百科全書按照范圍分冊

哈希分區

由于范圍分區容易產生熱點問題，許多分布式數據存儲使用一個哈希函數來確定一個鍵值的分區。一個好的哈希函數可以將傾斜的數據均勻分布，即使數據范圍很接近，但是它們的哈希值是均勻分布的值。如下圖所示，時間接近的鍵值被哈希函數均勻的分區在多個分區，每個鍵的哈希值落在一個分區的范圍將被存儲在該分區：

哈希分區

使用哈希分區，我們失去了鍵范圍分區的一個很好的特性，曾經相鄰的鍵現在分散在所有分區上，因此它們的排序順序丟失。我們可以通過級聯索引的方式解決這個問題。級聯索引方法支持一對多關系的優雅的數據模型，通過兩分區方式來綜合不同分區方式的優點，通過鍵哈希來確定分區的第一部分，但其他列作為SSTables的數據排序串聯。因此，查詢不能在復合鍵的第一列內搜索范圍內的值，但是如果它為第一列指定一個固定值，它就可以在鍵的其他列上執行有效的范圍掃描。例如，在社交媒體站點上，一個用戶可以發布許多更新。如果更新主鍵（user_id，update_timestamp），那么你可以有效地檢索在一定時間間隔內特定用戶的所有更新。不同的用戶可以存儲在不同的分區上，但是在每個用戶中，更新是在單個分區上以時間戳順序存儲的。

Tip：緩解熱點
通過哈希函數分區的確有助于減少熱點。然而，它不能完全避免它們：在極端情況下，所有讀寫操作都是相同的鍵，最終仍然會將所有請求到同一分區。例如，在社交媒體網站上，一個擁有數百萬追隨者的名人用戶在做某事時可能會引發一場讀寫風暴。此事件可能導致短時間內大量寫入同一個鍵（其中的Key可能是名人的用戶ID，或者是人們評論的行為ID）。這時哈希函數也無能為力，因為兩個相同ID的哈希值仍然相同。

大多數數據系統不能自動補償這種高度傾斜的工作負載，因此應用程序有責任減少偏斜。例如，如果已知一個鍵非常熱，一個簡單的方法就是在鍵的開頭或結尾加上一個隨機數。只有一個兩位數的十進制隨機數將把寫入分成100個不同的鍵，允許這些鍵被分配到不同的分區。但是將不同的鍵分開寫入后，現在任何讀取都必須做額外的工作，因為它們必須從所有100個鍵讀取數據并將其組合起來。而且這種方式還需要額外的記錄：因為只為少量的熱鍵添加隨機數是有意義的；對于絕大多數具有低寫入吞吐量的鍵，這將是不必要的開銷。因此，還需要一些方法來跟蹤哪些鍵正在被分割。

二級索引

而一旦涉及到二級索引，情況會變得更加復雜。二級索引通常不確定記錄的唯一性而應該是尋找一個特定的值出現的方式如：找到所有顏色是紅色的車 這樣的查詢。二級索引的問題是它不能映射到分區。有兩種主要方法將數據庫分為二級索引：基于分區的索引和基于全局的索引。

基于分區的索引

image.png

在這種索引方法中，每個分區都是完全獨立的，每個分區都保留自己的索引，只覆蓋分區中的文檔id。它不關心存儲在其他分區中的數據。每當您需要向數據庫寫入添加、刪除或更新文檔時，只需要處理包含您正在編寫的文檔ID的分區。

但是，從索引讀取時需要注意，如果您想搜索紅色的汽車，您需要將查詢發送到所有分區，并將所有返回的結果組合起來。這樣導致了二級索引上的讀取查詢非常耗時。即使并行的寫入和查詢分區，分散/聚集操作會導致延遲放大。

基于全局的索引

image.png

全局索引使讀操作更加高效：而不用分散/聚集所有分區的數據。但全球索引的缺點是，寫入速度較慢，更復雜，因為寫一個文件現在可以影響指數的多個分區。（文件中的每一項可能會在不同的分區，在不同的節點上，在實踐之中，二級全局索引通常通過異步的方式進行更新）。

分區重平衡

隨著時間的推移，數據庫會有各種變化。

1. 查詢吞吐量增加，所以您想要添加更多的CPU來處理負載。
2. 數據集大小增加，所以您想添加更多的磁盤和RAM來存儲它。
3. 機器出現故障，其他機器需要接管故障機器的責任。

所有這些更改都需要數據和請求從一個節點移動到另一個節點。 將負載從集群中的一個節點向另一個節點移動的過程稱為再平衡（reblancing）。

再平衡的最低要求
1.負載均衡
2.保持數據庫本來的讀取和寫入
3.節點只移動必須的數據，減少網絡磁盤io

反面教材：hash mod N

因為再平衡要全局遷移數據

海量分區

節點創建遠超節點數目的分區數，并為每個節點分配幾個分區。例如，在10個節點的群集上運行的數據庫可以從一開始分裂成1000個分區，以便分配給每個節點大約100個分區。當將一個節點添加到集群中，新節點可以從每個現有節點竊取一些分區，直到再次公平分配分區為止。如下圖所示：

海量分區的再平衡

分區的數量不會改變，分區的鍵分配也不會改變。唯一改變的是分區與節點之間的映射。這種分區平衡的變化不是即時的，在網絡上傳輸大量數據需要一定的時間，所以舊的分區節點在分區平衡時需要承擔這個過程之中的讀寫操作。通過海量分區同樣也可以通過給性能更強悍的節點分配更多的分區，可以強制這些節點承擔更大的負載份額。

一開始配置的分區數量就是所能擁有的最大節點數，因此您需要選擇足夠高的分區數目以適應未來的增長。然而，每個分區也有管理開銷，所以選擇過高的值會適得其反。

動態分區

對于使用鍵范圍分區的數據庫，固定范圍值的固定分區數量將非常不方便：如果您的邊界錯誤，您可能會將所有數據放在一個分區中，而所有其他分區都是空的。手動重新分區分區將非常繁瑣。所以可以采取動態分區的機制：

當一個分區的增長超過配置的大小，它被分為兩個分區，大約一半的數據分配在兩個新的分區。相反，如果大量數據被刪除，一個分區縮小到某個閾值以下，它可以與相鄰分區合并。動態分區的優點是分區的數量與總數據量相適應。如果只有少量的數據，少量的分區就足夠了，因此開銷很小；如果有大量的數據，每個單獨的分區的大小限制為一個可配置的最大值。

按節點比例

上述兩種方案，分區的數量都與節點的數量無關。
Cassandra和Ketama使用的第三種方法是使分區數與節點數成正比——換句話說，每個節點具有固定數量的分區。在這種情況下，每個分區的大小與數據集大小成比例地增長，而節點數量保持不變，但是當增加節點數時，分區將再次變小。由于較大的數據量通常需要較大數量的節點進行存儲，因此這種方法也使每個分區的大小較為穩定。
當一個新節點加入集群時，它隨機選擇固定數量的現有分區進行拆分，然后占有這些拆分分區中每個分區的一半，同時將每個分區的另一半留在原地。隨機化可能會產生不公平的分割，但是平均在更大數量的分區上時（在Cassandra中，默認情況下，每個節點有256個分區），新節點最終從現有節點獲得公平的負載份額。 Cassandra 3.0引入了另一種再分配的算法來避免不公平的分割。
這邊筆者的理解是一致性哈希。

建議不要完全自動再平衡

例如，假設一個節點過載，并且對請求的響應暫時很慢。其他節點得出結論：過載的節點已經死亡，并自動重新平衡集群，使負載離開它。這會對已經超負荷的節點，其他節點和網絡造成額外的負載，從而使情況變得更糟，并可能導致級聯失敗。

請求路由

在多臺機器上運行的多個節點上對數據集進行分區，所以會面臨一個核心問題：當客戶端想要提出請求時，它如何知道要連接哪個節點？當分區被重新平衡，分區節點變化的時候客戶端如何感知變化。

在高層次上，對這個問題有幾種不同的解決方案：

1. 允許客戶端與任何節點聯系。如果該節點恰好擁有請求所應用的分區，則它可以直接處理請求；否則，它將請求轉發到適當的節點，接收應答，并將應答傳遞給客戶端。

2. 將客戶端的所有請求首先發送到路由層，這將決定應處理每個請求并相應轉發它的節點。

3. 要求客戶端知道分區和分配給節點的分區。在這種情況下，客戶機可以直接連接到適當的節點，而不需要任何中介。

三種路由解決方案

在三種情況之中關鍵的問題是：組成路由決策的組件（可能是其中一個節點，或者路由層，或客戶端）如何了解分區分配給節點的變化？

許多分布式數據系統依賴于一個單獨的協調服務如ZooKeeper跟蹤這個集群的元數據，每個節點在ZooKeeper之中注冊自己。ZooKeeper維護分區節點映射的權威，而路由層或客戶端，可以訂閱這個ZooKeeper。當一個分區發生變化時，或添加一個節點或刪除，ZooKeeper通知路由層，這樣可以保持它的路由信息更新。如下圖所示：

基于ZooKeeper的請求路由

Cassandra和Riak采取了不同的方法：通過使用Gossip協議節點之間傳播集群狀態的任何變化。請求可以發送到任何節點，該節點將它們轉發到所請求分區的適當節點。該模型提出了更復雜的數據庫節點，但避免了外部協調服務的依賴。