# 資料庫系統設計：分割槽

## 術語澄清

分割槽 (partition)，對應 MongoDB、ES 中的 shard，HBase 的 Region，Bigtable 的 tablet，Cassandra 的 vnode，Couchbase 的 vBucket。但分割槽 (partitioning) 是最普遍的。

## 定義

每條資料（或每條記錄，每行或每個文件）屬於且僅屬於某特定分割槽。每個分割槽都能視為一個完整小型資料庫，雖然資料庫可能存在跨分割槽操作。

## 目的

提高可擴充套件性。不同分割槽可放在一個無共享叢集的不同節點。這樣的一個大資料集可分散在更多磁碟，查詢負載也隨之分佈到更多處理器。

單分割槽查詢時，每個節點對自己所在分割槽查詢可獨立執行查詢操作，新增更多節點就能提高查詢吞吐量。大型複雜查詢儘管比較困難，但也可能做到跨節點的並行處理。

分割槽資料庫在 20 世紀 80 年代由 Teradata 和 NonStop SQL 等產品率先推出，最近因 NoSQL 和基於 Hadoop 的資料倉儲重新被關注。有些系統是為事務處理而設計，有些系統則用於分析：這種差異會影響系統的運作方式，但是分割槽的基本原理均適用於這兩種工作方式。

在本章中，我們將首先介紹分割大型資料集的不同方法，並觀察索引如何與分割槽配合。然後討論 rebalancing，若想新增、刪除叢集中的節點，則必須進行再 rebalancing。最後，概述 DB 如何將請求路由到正確的分割槽並執行查詢。

## 1 分割槽與複製

分割槽一般和複製搭配使用，即每個分割槽的多個節點都有副本。這意味著，某條記錄屬於特定的分割槽，而同樣內容會儲存在不同的節點上，以提高系統容錯性。

一個節點可能儲存多個分割槽。如圖 - 1 所示，主從複製模型和分割槽組合時資料的分佈情況。每個分割槽都有自己的主副本，如被分配給某節點，而從庫副本被分配給其他節點。一個節點可能是某些分割槽的主副本，同時也是其他分割槽的從副本。

上一個文章討論的複製相關所有內容同樣適用於分割槽資料的複製。考慮到分割槽方案的選擇通常獨立於複製，為簡單起見，本文忽略複製相關內容。

![img](https://f.pz.al/pzal/2022/09/14/448be602a6c7d.jpg)

## 2 KV 資料的分割槽

海量資料想切分，如何決定在哪些節點上儲存哪些記錄？

分割槽的主要目標：將資料和查詢負載均勻分佈在各節點。若每個節點平均分擔資料和負載，則理論上 10 個節點能處理 10 倍的資料量和 10 倍於單節點的讀寫吞吐量（暫忽略複製）。

但若分割槽不均，則會導致某些分割槽節點比其他分割槽有更多資料量或查詢負載，即傾斜，這會導致分割槽效率下降很多。極端情況下，所有負載可能壓在一個分割槽節點，其餘 9 個節點空閒，系統瓶頸落在這最忙的節點。這時的高負載分割槽即是系統熱點。

### 2.1 避免熱點

最簡單的，將記錄隨機分配給所有節點。這能在所有節點比較均勻分佈資料，但缺點是：試圖讀取特定資料時，不知道儲存在哪個節點，必須並行查詢所有節點。

可以最佳化該方案。假設資料是簡單的 KV 資料模型，即總能透過 K 訪問記錄。如在一本百科全書，可透過標題查詢一個條目；而所有條目按字母序排序，因此能快速找到目標條目。

### 2.2 根據 K 的範圍分割槽（Key Range 分割槽策略）

一種分割槽方案，為每個分割槽指定一塊連續的 K 範圍（以 min 和 max 指示），如紙質百科全書的卷（圖 - 2）。若知道 K 區間的邊界，就能輕鬆確定哪個分割槽包含這些 K。若你還知道分割槽所在的節點，則可直接請求相應節點（就像從書架上選取正確書籍）。

![img](https://f.pz.al/pzal/2022/09/14/1fc00d3c4beea.jpg)

K 的區間不一定要均勻分佈，因為資料本身可能就不均勻。如圖 - 2 中，1 捲包含 A、B 開頭的單詞，但 12 卷則包含 T、U、V、X、Y 和 Z 開頭單詞。若只是簡單規定每個捲包含兩個字母，可能導致一些卷比其他卷大。為更均勻分佈資料，分割槽的邊界應適配資料本身的分佈特徵。

分割槽邊界可由管理員手動確定或由 DB 自動選擇。Bigtable 及其開源版本 HBase 和 2.4 版本之前的 MongoDB 都採用該分割槽策略。

每個分割槽中，可按 K 排序儲存。範圍掃描就很簡單，將 K 作為聯合索引來處理，從而在一次查詢中獲取多個相關記錄。假設有個程式儲存網路感測器的資料，K 是測量的時間戳（年月日 - 時分秒）。範圍掃描此時很有用，可快速獲取某月內的所有資料。

#### 缺點

某些訪問模式會導致熱點。 若 K 是時間戳，則分割槽對應於一個時間範圍，如每天一個分割槽。 測量資料從感測器寫入 DB 時，所有寫入操作都集中在同一分割槽（即當天的分割槽），導致該分割槽在寫入時處於高負載，而其他分割槽始終空閒。

為避免該問題，需要使用時間戳之外的內容作為 K 的第一項。 可考慮每個時間戳前新增感測器名稱，這樣首先按感測器名稱，再按時間進行分割槽。假設多個感測器同時執行，則寫入負載最終會均勻分佈在多個節點。 當想要獲取一個時間範圍內、多個感測器的資料，可根據感測器名稱，各自執行單獨的範圍查詢。

### 2.3 根據鍵的 Hash 分割槽

由於資料傾斜和熱點問題，許多分散式系統採用基於 K 雜湊函式來分割槽。

好的雜湊函式可處理傾斜資料並使其均勻分佈。

資料分割槽目的的 hash 函式無需健壯的加密能力，如 Cassandra 和 MongoDB 使用 MD5。許多程式語言也有內建的簡單雜湊函式（主要用於雜湊表），但可能不適合分割槽：如 Java 的 Object.hashCode ()，同一 K 可能在不同程式中有不同雜湊值。

確定合適的 hash 函式後，就能為每個分割槽分配一個 hash 範圍（而不是直接就是 K 的範圍），每個 K 透過 hash 雜湊落在不同分割槽，如圖 - 3：

![img](https://f.pz.al/pzal/2022/09/14/d5c7935edc5e9.jpg)

這種方案擅長在分割槽之間均勻分配 K。分割槽邊界可以是均勻間隔，也可以是偽隨機選擇（也稱為一致性雜湊）。

#### 一致性雜湊

一種平均分配自己負載的方法，最初用於內容分發網路（CDN）等網際網路快取系統。 採用隨機選擇的分割槽邊界來規避中央控制或分散式共識。此處的一致性與副本一致性或 ACID 一致性無任何關聯 ，它只描述了資料動態平衡的一種方法。

正如 “分割槽再平衡” 中所見，這種特殊分割槽方法對於 DB 實際上效果並非很好，所以目前很少使用（雖然某些 DB 的文件仍會使用一致性雜湊說法，但其實不準確）。 因為有可能產生混淆，所以最好避免使用一致性雜湊這個術語，而只是把它稱為 **雜湊分割槽（hash partitioning）**。

但透過 hash 分割槽，失去高效的執行範圍查詢的能力：即使相鄰的 K，經過 hash 後也會分散在不同分割槽。MongoDB 中，若使用 hash 分割槽，則範圍查詢都必須傳送到所有分割槽。而 Couchbase 或 Voldemort 乾脆直接不支援 K 的範圍查詢。

Cassandra 在兩種分割槽策略之間採取折中。 Cassandra 的表可使用由多個列組成的複合主鍵。鍵中只有第一部分可用於 hash 分割槽，而其他列則被用作 Casssandra 的 SSTables 中排序資料的聯合索引。儘管不支援複合主鍵的第一列的範圍查詢，但若第一列已指定固定值，則可對其他列執行高效的範圍查詢。

聯合索引為一對多關係提供一個優雅的資料模型。如社交網站，一個使用者可能釋出很多訊息更新。若更新的 K 被設定為 (user_id,update_timestamp)，則能高效檢索某使用者在某時間段內，按時間戳排序的所有更新。不同使用者可儲存在不同分割槽，但對某一使用者，訊息會按時間戳順序儲存在同一分割槽。

### 2.4 負載偏斜與熱點消除

hash 分割槽可減少熱點，但無法完全避免：極端情況下，所有讀 / 寫操作都是針對同一 K，則所有請求都會被路由到同一分割槽。

這種負載也許不常見，但也並非不可能：如社交網站，一個坐擁百萬粉絲的大 V 使用者，釋出一些熱點事件時，可能引發一場訪問風暴。導致同一個 K 的大量寫操作（K 可能是大 V 的使用者 ID 或人們正在評論的事件 ID）。此時，hash 策略不起任何作用，因為兩個相同 ID 的 hash 值仍相同。

如今，大多資料系統仍無法自動消除這種高度偏斜的負載，只能透過應用層來減少傾斜。如某 K 被確認為熱點，簡單方法是在 K 的開始或結尾新增一個隨機數。只要一個兩位數的十進位制隨機數就能將主鍵分散為 100 種不同的 K，從而儲存在不同分割槽。

但之後的任何讀取都要做額外工作，必須從所有 100 個 K 分佈中讀取資料然後合併。因此通常只對少量熱點 K 附加隨機數才有意義；而對寫吞吐量低的大多數 K，這些都是不必要開銷。此外，還需額外後設資料來標記哪些 K 進行了特殊處理。

感興趣的小夥伴可以在3A雲伺服器上部署環境自己進行測試，也許將來某天，資料系統將能自動檢測和處理負載傾斜情況；但當下，仍需你自己來綜合權衡策略。

資料庫系統設計：分割槽

相關文章