雲端計算設計模式（二十一）——Sharding分片模式

將一個資料儲存到一組水平分割槽或碎片。儲存和訪問大量資料時，這個模式可以提高可擴充套件性。

背景和問題

由一個單一的伺服器託管的資料儲存區可能會受到以下限制：
•儲存空間。一種資料儲存為一個大型雲應用可以預期含有資料量巨大，可以隨著時間的推移顯著增加。伺服器通常提供的磁碟儲存僅是有限的，但它可以是能與較大的取代現有的磁碟，或者新增另外的磁碟的機器作為資料量的增加。然而，由此，不能夠容易地增加一個給定的伺服器上的儲存容量的系統最終將達到一個硬限制。
•計算資源。雲應用程式可能需要支援大量併發使用者，每一個執行檢索的資料儲存資訊的查詢。一個單一的伺服器託管

解決方案

劃分資料儲存到水平分割槽或碎片。每個碎片都有相同的模式，但儲存的資料其獨特的子集。甲碎片是在自己的權利（它可以包含許多不同型別的實體的資料）的資料儲存器，用作儲存節點的伺服器上執行。

這種模式具有以下優點：
•您可擴充套件系統，通過新增額外的儲存節點上執行的進一步碎片。
•系統可以使用現成的商品硬體，而不是專門的（和昂貴）的計算機為每個儲存節點。
•您可以通過平衡

分片策略

選擇所述分片金鑰，並決定如何跨碎片分發資料時的三種策略是常用的。注意，並不需要成為碎片和承載它們 - 在單個伺服器可以承載多個分塊中的伺服器之間的一對一的對應關係。這些戰略包括：
•查詢策略。在上述策略中，分片的邏輯實現了一個圖，路由對資料的請求到包含碎片，通過使用分片金鑰資料。在一個多使用者應用將租戶的所有資料可能通過使用租戶ID作為分片金鑰一起儲存在一個碎片。多個租戶可能共享相同的碎片，但對於單個租戶的資料將不被跨越多個碎片散佈。圖1示出了這種策略的一個例子。

圖1 - 基於租戶ID的分片租戶資料


分片鍵和物理儲存的對映關係可以基於物理分塊，每個分片鍵對映到一個物理分割槽。可替換地，這種技術提供了重新平衡碎片時更大的靈活性是使用虛擬分割槽方法，其中分片鍵對映到虛擬碎片的數量相同，這又對映到較少的物理分割槽。在這種方法中，一個應用程式通過使用指的是一個虛擬碎片一個碎片鍵定位資料，並在系統的虛擬分片透明地對映到物理分割槽。進行修改，以使用一組不同的碎片的鍵的虛擬碎片和物理分割槽可以改變，而不需要對應用程式程式碼之間的對映。

•範圍的策略。這在同一個分片相關的專案一起策略組，並把它們的訂單通過分片金鑰分片鍵是連續的。它是用於應用程式通過使用範圍查詢（即返回一組資料項的為落在給定範圍內的碎片鍵查詢）經常檢索項集有用的。例如，如果應用程式經常需要找到放置在給定月份所有的訂單，該資料可被檢索更快如果一個月的所有命令被儲存在日期和時間的順序在同一個分片。如果每個訂單被儲存在不同的碎片，它們將必須通過進行大量的點查詢（返回單個資料項的查詢）的單獨取出。圖2示出了這種策略的一個例子。

圖2  - 資料中的碎片儲存順序集合（範圍）


在這個例子中，分片鍵是一個組合鍵，包括訂單月作為最顯著元件，其次是為了日和時間。建立和附加到一個碎片新訂單時，訂單中的資料自然排序。一些資料儲存支援包括識別所述碎片和行金鑰唯一地標識該子庫中的項分割槽鍵元件的兩部分分片金鑰。資料通常是在碎片中排鍵順序舉行。該受的範圍內的查詢和需要的專案組合在一起可以使用一個分片鍵具有用於分割槽鍵但該行鍵的唯一值相同的值。

•雜湊策略。這種策略的目的是減少在資料熱點的機會。它的目的是分配在實現每個碎片的大小和平均負載，每個碎片會遇到之間的平衡的方式在整個碎片中的資料。分片的邏輯計算，其中基於所述資料的一個或多個屬性的雜湊來儲存中的專案的子庫。所選擇的雜湊函式應該均勻地分佈在整個資料碎片，可能通過引入一些隨機元素插入的計算。圖2示出了這種策略的一個例子。

圖3 - 基於租戶ID的雜湊分片租戶資料


•瞭解超過其他分片策略雜湊策略的優勢，考慮如何依序錄取新租戶多租戶應用程式可能分配租戶碎片中的資料儲存。當使用範圍的策略，租戶1到n的資料都將儲存在分片A中，資料為住戶的n +1到m都將儲存在分片B，依此類推。如果最近登記的租戶也是最活躍，最資料活動將發生在少數碎片，這可能會導致熱點。與此相反，雜湊策略分配租戶基於對其租戶ID的雜湊碎片。這意味著順序租戶是最有可能被分配到不同的碎片，如圖3所示為住戶55和56，這將在這些碎片分配負載。

下表列出的主要優點和考慮這三個分片策略。

最常見的拆分方案實現上述方法之一，但你也應該考慮你的應用程式的業務需求和他們的資料使用模式。例如，在一個多使用者應用：
•可以分片根據工作負載資料。你可以分開在不同的碎片極易揮發租戶的資料。對於其他租戶的資料訪問的速度可以提高作為結果。
•可以分片根據租戶的位置資料。它可能會採取對租戶的資料在一個特定的地理區域離線期間在該地區非高峰期備份和維護，而對於住戶在其他地區的資料仍然在他們上班時間上網和訪問。
•高價值的住戶能分到自己的私人高效能，輕載碎片，而價值較低的住戶可能有望分享更密集堆積，忙碎片。
•對於需要資料隔離和隱私的高度可以儲存一個完全獨立的伺服器上租戶的資料。

縮放和資料移動操作

每個分片策略意味著不同的功能和複雜性管理的規模，向外擴充套件，資料移動，並保持水平狀態。

查詢策略允許縮放和資料移動操作來進行，在使用者層面，無論是線上還是離線。該技術暫停部分或全部使用者活動（也許是在非高峰時段），移動資料到新的虛擬分割槽或物理碎片，改變對映，無效或重新整理持有該資料的快取，然後讓使用者活動恢復。通常這種型別的操作可以進行集中管理。查詢戰略要求的狀態是高度可快取和副本友好。

的範圍的策略規定了結垢和資料移動操作，這通常必須進行時的一部分或全部的資料儲存為離線，因為資料必須被分割和整個碎片合併的一些限制。移動的資料，以重新平衡碎片可能無法解決不均勻負荷的問題，如果大多數的活性是對相鄰分片金鑰或資料識別符號是相同的範圍之內的。範圍的策略可能也需要進行維護，以圖範圍內的物理分割槽的一些狀態。

雜湊策略使得擴充套件和資料移動操作更為複雜，因為分割槽鍵是碎片金鑰或資料識別符號的雜湊值。每個碎片的新位置，必須從雜湊函式來確定，或者該函式修改，以提供正確的對映。然而，雜湊策略不需要維護狀態。

問題和注意事項

在決定如何實現這個模式時，請考慮以下幾點：
•分片是互補的其他形式的分割槽，如垂直分割槽和功能劃分。例如，單個子庫可以包含已垂直劃分實體和功能劃分可以被實現為多個碎片。有關分割槽的詳細資訊，請參閱資料分割槽指導。
•保持平衡碎片，使他們都處理的I / O相似的體積。作為資料被插入和刪除，它可能有必要定期地重新平衡的碎片，以保證均勻分佈，並減少熱點的機會。再平衡可能是一個昂貴的操作。為了降低頻率與再平衡成為必要，你應該確保每個碎片中含有足夠的可用空間來處理變化的預期貨量計劃增長。你還應該制定戰略和指令碼，你可以用它來快速重新平衡碎片這應該成為必要。
•使用穩定的資料分片的關鍵。如果分片鍵的變化，相應的資料項可能需要碎片之間移動，增加工作通過更新操作執行的工作量。出於這個原因，避免立足於潛在的波動資訊的碎片關鍵。相反，尋找那些不變的或自然形成的關鍵屬性。
•確保碎片鑰匙都是獨一無二的。例如，應避免使用自動遞增的欄位作為分片的關鍵。在一些系統中，自動遞增欄位可以不橫跨碎片協調，從而可能導致在具有相同分片鍵不同的碎片的專案。

注意：

在不包括分片鍵也可能導致問題欄位自動遞增值。例如，如果您使用自增欄位來生成唯一標識，並分佈在不同的碎片兩個不同的專案可能被分配相同的ID。


•它可能無法設計出符合針對資料的每個可能的查詢要求一個分片鍵。分片的資料，以支援最經常進行的查詢，並在必要時建立二級索引表，以支援通過使用基於不屬於分片鍵的一部分的屬性標準檢索資料的查詢。欲瞭解更多資訊，請參見索引表模式。
•查詢訪問僅單個碎片會比那些來自多個分塊中檢索資料的效率，從而避免執行一個分片方案，該方案導致在執行該連線在不同碎片保持的資料的查詢的大量應用程式。請記住，碎瓷片可以包含的資料為多個型別的實體。考慮非規範化的資料保持相同的碎片常常被認為是一起查詢（如客戶的詳細資訊和訂單，他們已經把）相關實體，以減少單獨讀取數的應用程式執行。

注意：

如果在一個子庫的實體引用儲存在另一個分片的一個實體，包括分片鍵用於第二實體，作為第一實體的架構的一部分。這可以幫助提高引用跨碎片相關資料查詢的效能。


•如果應用程式必須執行檢索來自多個分塊資料的查詢，有可能通過使用並行任務來獲取這些資料。例子包括扇出查詢，其中來自多個分片的資料檢索平行，然後彙總到一個結果。然而，這種方法不可避免地增加了一些複雜性的溶液的資料訪問邏輯。
•對於許多應用來說，產生的小碎片更大數目可以比具有少量的大碎片，因為它們可以提供用於負載平衡的機會增加更加有效。如果預計需要碎片從一個物理位置移動到另一個這樣的方法也可以是有用的。移動小碎片比移動一個大的更快。
•確保提供給每個分片儲存節點的資源足以處理資料的規模和吞吐量方面的可擴充套件性要求。欲瞭解更多資訊，請參閱資料分割槽引導部分“設計分割槽的可擴充套件性”。
•考慮複製參考資料所有碎片。如果從一個子庫中檢索資料的操作還引用靜態或緩慢移動的資料作為同一查詢的一部分，這個資料新增到碎片。然後，應用程式可以讀取所有用於容易地查詢中的資料，而無需進行額外的往返行程到一個單獨的資料儲存中。

注意：

如果在多個分塊的變化保持的基準資料，該系統必須同步所有碎片這些變化。而此同步發生時，系統可能會出現一定程度的混亂。如果你按照這種方法，你應該設計自己的應用程式能夠處理這個矛盾。


•它可以是難以維持的碎片之間的參照完整性和一致性，所以你應該儘量減少影響在多個碎片資料操作。如果應用程式必須通過碎片修改資料，評估完整的資料一致性是否實際上是一個要求。相反，在雲中一個常用的方法是實現最終一致性。每個分割槽中的資料分別進行更新，並在應用程式邏輯必須承擔保證責任的更新都成功完成，以及處理，可以從查詢資料的最終一致的執行操作時產生的不一致。有關實現最終一致性的更多資訊，請參閱資料一致性底漆。
•配置和管理大量碎片可能是一個挑戰。任務，例如監控，備份，檢查一致性，並記錄或審計必須完成對多個碎片和伺服器，在多個位置有可能保持。這些任務可能會通過使用指令碼或其他自動化解決方案，但指令碼和自動化可能無法完全消除額外的行政要求執行。
•碎片可以是地理定位的，使得它們包含的資料是靠近使用它的應用程式的例項。這種方法可以顯著改善的效能，但是需要額外考慮為必須訪問多個分塊中的不同位置的任務。

何時使用這個模式

使用這種模式：
•當資料儲存可能需要擴充套件超越了一單個儲存節點的資源的限制。
•通過減少爭用的資料儲存來提高效能。

注意：

分片的主要焦點是改進系統的效能和可擴充套件性，而作為副產物，也可以藉助於其中資料被劃分成單獨的分割槽的方式提高可用性。在一個分割槽中的故障不一定阻止應用程式訪問的其他分割槽中儲存的資料，並且操作者無需使得整個資料為應用程式無法訪問的可以執行的一個或多個分割槽的維護或復原。欲瞭解更多資訊，請參閱資料分割槽指導。

例子

下面的示例使用了一組充當碎片的SQL Server資料庫。每個資料庫包含一個應用程式使用的資料的一個子集。應用程式檢索該被分佈在整個碎片通過使用它自己的分片邏輯（這是一個扇出查詢的一個例子）的資料。將位於每個子庫中的資料的細節是通過這樣的方法稱為GetShards返回。此方法返回ShardInformation物件，其中ShardInformation型別包含一個識別符號為每個碎片和SQL Server的連線字串，應用程式應該使用連線到碎片的列舉列表（在連線字串中沒有程式碼示例所示）。

private IEnumerable<ShardInformation> GetShards()
{
  // This retrieves the connection information from a shard store 
  // (commonly a root database).
  return new[]
  {
    new ShardInformation
    {
      Id = 1,
      ConnectionString = ...
    },
    new ShardInformation
    {
      Id = 2,
      ConnectionString = ...
    }
  };
}

下面的程式碼顯示瞭如何在應用程式使用ShardInformation物件名單進行了從並行每個碎片獲取資料的查詢。查詢的細節沒有示出，但在本實施例中所檢索的資料包括可以存放資訊，如客戶的名稱，如果碎片包含客戶的細節的字串。該結果由應用聚整合ConcurrentBag集合進行處理。

// Retrieve the shards as a ShardInformation[] instance. 
var shards = GetShards();

var results = new ConcurrentBag<string>();

// Execute the query against each shard in the shard list.
// This list would typically be retrieved from configuration 
// or from a root/master shard store.
Parallel.ForEach(shards, shard =>
{
  // NOTE: Transient fault handling is not included, 
  // but should be incorporated when used in a real world application.
  using (var con = new SqlConnection(shard.ConnectionString))
  {
    con.Open();
    var cmd = new SqlCommand("SELECT ... FROM ...", con);

    Trace.TraceInformation("Executing command against shard: {0}", shard.Id);
                    
    var reader = cmd.ExecuteReader();
    // Read the results in to a thread-safe data structure.
    while (reader.Read())
    {
      results.Add(reader.GetString(0));
    }
  }
});

Trace.TraceInformation("Fanout query complete - Record Count: {0}", 
                        results.Count);