[TOC] ## 概述 ? 分區主要是為了**可擴展性**。不同的分區可以放在不共享集群中的不同節點上 ## 方案 ### 根據鍵的范圍分區 ### 根據鍵的散列分區 通過使用Key散列進行分區，我們失去了鍵范圍分區的一個很好的屬性：高效執行范圍查詢的能力。曾經相鄰的密鑰現在分散在所有分區中，所以它們之間的順序就丟失了 ## 分區再平衡 隨著時間的推移，數據庫會有各種變化。 * 查詢吞吐量增加，所以您想要添加更多的CPU來處理負載。 * 數據集大小增加，所以您想添加更多的磁盤和RAM來存儲它。 * 機器出現故障，其他機器需要接管故障機器的責任。 ### 反面教材：hash mod N 模$N$方法的問題是，如果節點數量N發生變化，大多數密鑰將需要從一個節點移動到另一個節點 ### 固定數量的分區 有一個相當簡單的解決方案：創建比節點更多的分區，并為每個節點分配多個分區。例如，運行在10個節點的集群上的數據庫可能會從一開始就被拆分為1,000個分區，因此大約有100個分區被分配給每個節點 現在，如果一個節點被添加到集群中，新節點可以從當前每個節點中**竊取**一些分區  **將新節點添加到每個節點具有多個分區的數據庫群集** ### 動態分區 具有固定邊界的固定數量的分區將非常不便：如果出現邊界錯誤，則可能會導致一個分區中的所有數據或者其他分區中的所有數據為空。手動重新配置分區邊界將非常繁瑣 當分區增長到超過配置的大小時（在HBase上，默認值是10GB），會被分成兩個分區，每個分區約占一半的數據【26】。與之相反，如果大量數據被刪除并且分區縮小到某個閾值以下，則可以將其與相鄰分區合并 ## 按節點比例分區 ? 通過動態分區，分區的數量與數據集的大小成正比，因為拆分和合并過程將每個分區的大小保持在固定的最小值和最大值之間。另一方面，對于固定數量的分區，每個分區的大小與數據集的大小成正比。在這兩種情況下，分區的數量都與節點的數量無關