Aerospike-Architecture系列之資料分布

標籤：分布式   aerospike   nosql   記憶體資料庫   share-nothing   

Data Distribution（資料分布）

Aerospike資料庫是Shared-Nothing 架構：一個Aerospike叢集中的每個節點都是相同的，所有節點對等，無單點故障。

利用Aerospike智能分區演算法，資料分布在叢集中的各個節點之上。我們已經在這個領域的許多案例中測試過我們的方法，這個非常隨機數函數保證分區分布誤差在1-2%。

為了確定記錄去向，使用RIPEMD160演算法，任意長度的記錄鍵（key）被雜湊化為一個20位的定長字串，前12位組成分區ID，用來確定哪個分區包含這條記錄。分區同樣分佈於叢集節點中。所以，叢集中有N個節點，每個節點大約儲存1/N的資料。

因為資料均勻且隨機的分佈於節點，不會出現熱點和瓶頸。也不會出現明顯的某個節點比其他節點處理請求多的情況。

例如，在美國很多的姓以R開頭。如果資料按照字母排序儲存，儲存以R開頭的伺服器其通訊量會遠遠大於儲存以X，Y或Z開頭的伺服器。資料隨機分配保證伺服器負載平衡。

對於可靠性，Aerospike在一個或多個節點上複製分區。一個節點作為讀寫分區的主節點，其他節點儲存副本。

例如，在一個4節點的Aerospike叢集中，每個節點約是1/4資料的主節點，同時也是1/4資料的副本。作為主節點的資料分區，分佈於所有其他作為副本的節點。所以，如果節點#1不可訪問，節點#1的副本將被延伸至其他3個節點。

複製因子（ replication factor）是一個配置參數，不能超過叢集節點數。副本越多可靠性越高。但是作為必須經過所有資料副本的寫請求也越高。實踐中，大部分部署使用的資料因子為2（一份主要資料和一個副本）。

同步複製保證即時一致性，沒有資料丟失。在提交資料並返回結果給用戶端之前，寫事務被傳播到所有副本。個別案例中，在叢集重新設定期間，當Aerospike智能終端發送請求到那些短暫過時的錯誤節點時，Aerospike智能叢集會透明的代理請求至正確的節點。最後，當叢集正在從分區中恢複，它解決所有發生在不同副本之間的衝突。解析可以配置為自動的，在這種情況下擁有最新的時間戳記的資料被視為標準。或者為了在更高層次解析，所有資料副本可以被返回應用程式。

How Aerospike Creates Partitions（Aerospike如何建立分區）

namespace是Aerospike資料庫以相同方式儲存的資料的集合。每個namespace分為4096個分區，分區被均等的分到叢集中的節點。意味著如果叢集中有n個節點，每節點約儲存1/n的資料

用非常隨機數雜湊方法保證分區均勻分布。我們已經在這個領域的許多案例中測試過我們的方法，資料分布誤差在1-2%。

因為資料均勻且隨機的分佈於節點，不會出現熱點和瓶頸。也不會出現明顯的某個節點比其他節點處理請求多的情況。

例如，在美國很多的姓以R開頭。如果資料按照字母排序儲存，儲存以R開頭的伺服器其通訊量會遠遠大於儲存以X，Y或Z開頭的伺服器。資料隨機分配保證伺服器負載平衡。

下一步，無須人工分區。叢集節點間均等的劃分分區。用戶端發現叢集變化並發送請求到正確的節點。定節點被添加或移除，叢集自動重新平衡。叢集中所有節點是均等的-沒有單獨的master節點失敗而導致整個資料庫宕掉。

當資料庫create一個條記錄，記錄key的雜湊值被用來分配記錄到某一分區，雜湊演算法是確定的-雜湊演算法總是將記錄映射到同樣分區。在記錄的整個生命週期它駐留在同一節點上。分區可能從一個節點移動到其他節點。但是分區不會分裂或者重新分配記錄到其他分區

叢集中每個節點有一個設定檔。每個節點上的namespace配置參數必須一致。How Data is Replicated/Synchronized locally（資料如何被局部的複製/同步）An Aerospike Cluster with No Replication（一個無複製的Aerospike叢集）

考慮4節點叢集的情況。Aerospike資料庫中，無複製資料需要設定複製因子為1（replication factor = 1），意思是資料庫中只存在一個副本。

因為所有4096個分區在一個4節點叢集中，每個節點有1/4的資料-隨機分配的1024個分區。叢集看起來如，每個節點管理一個分區集合（簡單起見，只展示兩個節點的分區）：

每個節點是1/4資料分區的主要資料節點-如果節點是資料的主讀寫源，那麼它就是主要資料節點。

用戶端對資料有位置感知能力-用戶端知道每個分區的位置-索引資料可以單跳從節點返回。每個讀寫請求發送至主要資料節點處理。當智能節點讀某條記錄時，它發送請求到記錄的主要資料節點。

An Aerospike Cluster with Replication（有複製的Aerospike叢集）

現在考慮一下帶資料複製的情況。大多數情況是維護兩個資料副本，主要資料和副本。Aerospike資料庫中，需要指定複製因子為2（replication factor = 2）。

在這個例子中，每個節點擁有1/4的主要資料（1024個分區）和1/4的資料副本（1024個分區）。看起來像這樣（簡單起見，顯示兩個節點的細節）

注意，每個節點的主要資料作為副本被分布到所有的其他節點。例如，節點#1的主要資料分區副本橫跨其他節點分布。當節點#1不可用，節點#1的資料副本延伸至跨其他資料節點。

與先前提到的無副本的例子一樣，用戶端發送請求至主要資料。

與無複製的情況一樣，讀請求通過智能用戶端發送至正確的節點，寫請求也被發送至正確的節點。當節點收到寫請求，它儲存資料並轉寄寫請求到副本節點。一旦副本節點確認資料寫成功並且主要資料節點本身也完成寫動作，然後確認被發送至用戶端，寫操作成功。

複製因子不能超過叢集中節點的數量。越多副本越可靠，但是對於穿越所有副本的寫請求的需求也越高。實踐中，多數資料庫複寫因子為2。Automatic data rebalancing（自動資料重新平衡）

無人工分區。

Aerospike資料重新平衡演算法保證請求量在所有節點間均勻分布，在重新平衡期間節點失敗發生時，演算法依舊健壯。系統被設計為持續可用，所有資料重新平衡不影響叢集行為。事務演算法與資料分布系統整合，只有一個一致投票來協調叢集變化。當用戶端發現新的叢集配置時，利用叢集內部重新導向演算法，只有一個小的間隔。這樣，在一個可伸縮的無共用機制最佳化事務簡單環境,同時保ACID特徵。

Aerospike允許配置選項指定有多少可用的操作開銷應該用於管理工作,例如與運行用戶端事務相比有多少用於節點間重新平衡。在首選事務放緩的情況下，叢集癒合更快。在交易量和速度必須維持的情況下，叢集重新平衡會很慢。

在某些叢集因子不能滿足的情況下。叢集可以配置為減少配置因子以保持所有資料，或者清除哪些標記為可丟棄的就資料。如果叢集不成接受更多資料，叢集將在read-only模式下操作，直到新的擴容可用-節點會自動變為可以接受應用程式的寫操作。

不需要操作員幹預，甚至在要求的時間內，叢集將自愈。在客戶部署中，提取8節點叢集中的一個會讓整個迴路被打斷。這就需要無人工幹預。即使資料中心在高峰時宕機，事務依舊保持精確的ACID。幾小時內，當錯誤被修複，操作者不需要執行特殊步驟來維護叢集。

我們的擴容計劃和系統監控，為你提供處理不可預見的錯誤的能力，而且無服務丟失。你可以配置硬體容量、設定複製/同步策略，這樣資料庫恢複時可以對使用者無影響。

Handling Traffic Saturation（處理通訊量）

討論網路硬體如何處理高峰流量負載的細節超出了本文檔的範圍。Aerospike資料庫提供了用來評估瓶頸的監控工具。如果網路是瓶頸，資料庫不會滿負荷運轉，請求會變慢。

Handling Capacity Overflows（處理容量溢出）

對於容量規劃我們有很多建議，管理儲存並監控叢集以確儲存儲不溢出。但是在儲存溢出的情況下，Aerospike觸發停止寫限制-在這種情況下不會有新的記錄 被接受。但是資料修改和讀取被正常處理。

換句話說，即使超過容量，資料庫不會停止處理查詢操作，它持續保持盡量多的使用者請求處理量。

原文連結： <http://www.aerospike.com/docs/architecture/data-distribution.html>
譯       者：北京IT爺們兒
 

Aerospike-Architecture系列之資料分布