分區化模式

將數據存放區分割成一組水平數據分割或分區。 這可以改善儲存和存取大量數據時的延展性。

內容和問題

由單一伺服器裝載的數據存放區可能受限於下列限制：

• 儲存體空間。 大型雲端應用程式的數據存放區預計將包含大量數據，可能會隨著時間大幅增加。 伺服器通常只提供有限的磁碟記憶體，但您可以使用較大的磁碟取代現有的磁碟，或隨著數據磁碟區成長，將進一步的磁碟新增至計算機。 不過，系統最終會達到限制，因為無法輕易增加指定伺服器上的儲存容量。

• 計算資源。 雲端應用程式需要支援大量並行使用者，每個用戶都會執行從資料存放區擷取信息的查詢。 裝載數據存放區的單一伺服器可能無法提供支援此負載的必要運算能力，導致使用者的回應時間延長，而且應用程式嘗試儲存和擷取數據逾時時，經常發生失敗。您可以新增記憶體或升級處理器，但當無法進一步增加計算資源時，系統將會達到限制。

• 網路頻寬。 最後，在單一伺服器上執行的數據存放區效能取決於伺服器可以接收要求和傳送回復的速率。 網路流量的容量可能會超過用來連線到伺服器的網路容量，而導致要求失敗。

• 地理位置。 基於法律、合規性或效能考慮，或減少數據存取延遲，可能需要將特定使用者所產生的數據儲存在與那些使用者相同的區域中。 如果使用者分散到不同的國家或地區，可能無法將應用程式的整個資料儲存在單一數據存放區中。

藉由新增更多磁碟容量、處理能力、記憶體和網路連線來垂直調整，可能會延後其中一些限制的影響，但可能只是暫時的解決方案。 能夠支援大量使用者和大量數據的商業雲端應用程式必須能夠無限期地調整，因此垂直調整不一定是最佳解決方案。

解決方案

將數據存放區分割成水準分割區或分區。 每個分區都有相同的架構，但會保存其本身不同的數據子集。 分區是自己的數據存放區（它可以包含不同類型之許多實體的數據），在做為記憶體節點的伺服器上執行。

此模式具有下列優點：

• 您可以藉由新增在其他記憶體節點上執行的進一步分區來相應放大系統。

• 系統可以使用現成的硬體，而不是針對每個記憶體節點專用且昂貴的計算機。

• 您可以藉由在分區之間平衡工作負載來減少爭用並改善效能。

• 在雲端中，分區可以實際靠近將存取數據的使用者。

將數據存放區分割成分區時，決定應該在每個分區中放置哪些數據。 分區通常包含落在數據一或多個屬性所決定之指定範圍內的專案。 這些屬性會形成分區索引鍵（有時稱為分割區索引鍵）。 分區索引鍵應該是靜態的。 它不應該以可能變更的數據為基礎。

分區化會實際組織數據。 當應用程式儲存和擷取數據時，分區化邏輯會將應用程式導向適當的分區。 此分區化邏輯可以實作為應用程式中數據存取程式代碼的一部分，或者，如果數據儲存系統以透明方式支援分區化，則可以由數據儲存系統實作。

在分區化邏輯中抽象化數據的實體位置，可提供高度控制哪些分區包含哪些數據。 如果稍後需要重新分配分區中的數據，它也可讓數據在分區之間移轉，而不需要重新處理應用程式的商業規則（例如，如果分區變得不平衡）。 取捨是判斷擷取每個數據項位置所需的額外數據存取額外負荷。

為了確保最佳效能和延展性，請務必以適合應用程式執行之查詢類型的方式分割數據。 在許多情況下，分區化配置不太可能完全符合每個查詢的需求。 例如，在多租用戶系統中，應用程式可能需要使用租使用者標識符擷取租用戶數據，但也可能需要根據租用戶的名稱或位置等其他屬性來查閱此數據。 若要處理這些情況，請使用支援最常執行查詢的分區索引鍵來實作分區化策略。

如果查詢會定期使用屬性值的組合來擷取數據，您可以將屬性連結在一起來定義複合分區索引鍵。 或者，使用索引表之類的模式，根據分區索引鍵未涵蓋的屬性，為數據提供快速查閱。

分區化策略

選取分區索引鍵並決定如何將數據分散到分區時，通常會使用三種策略。 請注意，分區與裝載它們的伺服器之間不需要一對一對應，單一伺服器可以裝載多個分區。 策略如下：

查閱策略。 在此策略中，分區化邏輯會實作對應，以使用分區索引鍵將數據的要求路由傳送至包含該數據的分區。 在多租使用者應用程式中，租使用者的所有數據都可以使用租使用者標識碼作為分區索引鍵，一起儲存在分區中。 多個租使用者可能會共用相同的分區，但單一租用戶的數據不會分散到多個分區。 此圖說明根據租使用者標識符分區化租用戶數據。

分區索引鍵值與數據存在的實體記憶體之間的對應，可以依據實體分區，其中每個分區索引鍵值對應至實體分割區。 或者，重新平衡分區的更有彈性的技術是虛擬分割，其中分區索引鍵值會對應至相同數目的虛擬分區，進而對應到較少的實體分割區。 在此方法中，應用程式會使用參考虛擬分區的分區索引鍵值來找出數據，而系統會以透明方式將虛擬分區對應至實體分割區。 虛擬分區與實體分割區之間的對應可以變更，而不需要修改應用程式程式代碼以使用不同的分區索引鍵值集。

範圍策略。 此策略會將相同分區中的相關專案分組在一起，並依分區索引鍵排序，分區索引鍵是循序的。 對於經常使用範圍查詢擷取專案集的應用程式很有用（查詢會針對落在指定範圍內之分區索引鍵傳回一組數據項的查詢）。 例如，如果應用程式定期需要尋找指定月份中的所有訂單，則如果一個月的所有訂單都以日期和時間順序儲存在同一個分區，則可以更快速地擷取此數據。 如果每個訂單都儲存在不同的分區中，則必須執行大量的點查詢來個別擷取它們（傳回單一數據項的查詢）。 下一個圖說明將循序集（範圍）的數據儲存在分區中。

在此範例中，分區索引鍵是包含訂單月份作為最重要的元素的複合索引鍵，後面接著訂單日和時間。 當新訂單建立並新增至分區時，訂單的數據自然會排序。 某些數據存放區支援兩部分分區索引鍵，其中包含可識別分區的數據分割索引鍵專案，以及可唯一識別分區中專案的數據列索引鍵。 數據通常會以數據列索引鍵順序保留在分區中。 受限於範圍查詢且需要群組在一起的專案，可以使用分割區索引鍵具有相同值的分區索引鍵，但數據列索引鍵的唯一值。

哈希策略。 此策略的目的是減少熱點（接收不成比例負載的分區）的機會。 它會將數據分散到分區，以達到每個分區大小與每個分區將遇到的平均負載之間取得平衡的方式。 分區化邏輯會根據數據之一或多個屬性的哈希來計算要儲存專案的分區。 選擇的哈希函式應該將數據平均分散到分區，可能是將一些隨機元素引入計算中。 下圖說明以租用戶標識碼哈希為基礎的分區化租用戶數據。

若要瞭解哈希策略與其他分區化策略的優點，請考慮如何循序註冊新租使用者的多租用戶應用程式，將租使用者指派給數據存放區中的分區。 使用 Range 策略時，租使用者 1 到 n 的數據都會儲存在分區 A 中，租用戶 n+1 到 m 的數據全都會儲存在分區 B 中，依序儲存。 如果最近註冊的租使用者也是最活躍的租使用者，則大部分的數據活動將會發生在少數分區中，這可能會導致熱點。 相反地，哈希策略會根據租用戶標識符的哈希，將租使用者配置給分區。 這表示循序租使用者最有可能配置給不同的分區，這會分散這些分區的負載。 上圖顯示租使用者 55 和 56 的這個值。

三個分區化策略具有下列優點和考慮：

• 查閱。 這可讓您更充分掌控分區的設定和使用方式。 使用虛擬分區可減少重新平衡數據時的影響，因為可以將新的實體分割區新增至甚至輸出工作負載。 虛擬分區與實作分區的實體分割區之間的對應可以修改，而不會影響使用分區索引鍵來儲存和擷取數據的應用程式程序代碼。 查閱分區位置可能會造成額外的額外負荷。

• 範圍。 這很容易實作，且適用於範圍查詢，因為它們通常可以在單一作業中從單一分區擷取多個數據項。 此策略提供更簡單的數據管理。 例如，如果相同區域中的用戶位於相同的分區中，則可以根據本機負載和需求模式，在每個時區排程更新。 不過，此策略不會在分區之間提供最佳平衡。 如果大部分活動是針對相鄰分區索引鍵，重新平衡分區很困難，而且可能無法解決負載不平均的問題。

• 哈希。 此策略提供更佳的機會，讓數據更均勻且負載分佈。 您可以使用哈希函式直接完成要求路由。 不需要維護地圖。 請注意，計算哈希可能會造成額外的額外負荷。 此外，重新平衡分區很困難。

最常見的分區化系統實作上述其中一種方法，但您也應該考慮應用程式的商務需求及其數據使用量模式。 例如，在多租使用者應用程式中：

• 您可以根據工作負載來分區數據。 您可以在個別分區中隔離高度揮發性租用戶的數據。 可能會改善其他租用戶的數據存取速度。

• 您可以根據租使用者的位置來分區數據。 您可以將特定地理區域中租用戶的數據離線，以在該區域的離峰時段進行備份和維護，而其他區域中租用戶的數據會維持在在線狀態，並在上班時間存取。

• 高價值租使用者可以指派自己的私人、高效能、輕載分區，而較低價值的租使用者可能會共用更密集且忙碌的分區。

• 需要高度數據隔離和隱私權的租用戶數據可以儲存在完全獨立的伺服器上。

調整和數據移動作業

每個分區化策略都表示管理相應縮小、相應放大、數據移動和維護狀態的不同功能和複雜度層級。

查閱策略允許在用戶層級在線或離線執行縮放和數據移動作業。 這項技術是暫停部分或所有用戶活動（也許是在離峰期間）、將數據移至新的虛擬分割區或實體分區、變更對應、使保留此數據的任何快取失效或重新整理，然後允許用戶活動繼續。 這種類型的作業通常可以集中管理。 查閱策略需要狀態為高度可快取且方便複本使用。

Range 策略會對調整和數據移動作業施加一些限制，通常必須在部分或所有數據存放區離線時執行，因為數據必須分割並合併到分區。 如果大部分活動是針對位於相同範圍內的連續分區索引鍵或數據識別碼，行動數據至重新平衡分區可能無法解決負載不平均的問題。 Range 策略可能也需要維護某些狀態，才能將範圍對應至實體分割區。

哈希策略會使調整和數據移動作業變得更複雜，因為分割區索引鍵是分區索引鍵或數據標識碼的哈希。 每個分區的新位置必須從哈希函式決定，或修改過的函式以提供正確的對應。 不過，哈希策略不需要維護狀態。

問題和考量

當您決定如何實作此模式時，請考慮下列幾點：

• 分區化與其他類型的數據分割互補，例如垂直數據分割和功能分割。 例如，單一分區可以包含垂直分割的實體，而且功能分割可以實作為多個分區。 如需數據分割的詳細資訊，請參閱 數據分割指引。

• 讓分區保持平衡，讓它們都處理類似的 I/O 磁碟區。 插入和刪除數據時，必須定期重新平衡分區，以確保平均分佈並減少熱點的機會。 重新平衡可能是昂貴的作業。 若要減少重新平衡的必要性，請藉由確保每個分區包含足夠的可用空間來處理預期的變更量，以規劃成長。 如果有必要，您也應該開發策略和腳本，以便快速重新平衡分區。

• 針對分區索引鍵使用穩定的數據。 如果分區索引鍵變更，對應的數據項可能需要在分區之間移動，以增加更新作業所執行的工作量。 基於這個理由，請避免將分區索引鍵基礎放在潛在的揮發性資訊上。 相反地，尋找不可變或自然形成索引鍵的屬性。

• 確定分區索引鍵是唯一的。 例如，避免使用自動新增欄位作為分區索引鍵。 在某些系統中，自動遞增字段無法跨分區協調，可能會導致不同分區的專案具有相同分區索引鍵。

  非分區索引鍵之其他欄位中的自動遞增值也可能會導致問題。 例如，如果您使用自動新增欄位來產生唯一標識碼，則位於不同分區中的兩個不同的專案可能會指派相同的標識碼。

• 可能無法設計分區索引鍵，以符合每個可能查詢對數據的需求。 將數據分區化以支援最常執行的查詢，並在必要時建立次要索引表以支援使用準則來擷取數據的查詢，這些查詢會根據不屬於分區索引鍵的屬性來擷取數據。 如需詳細資訊，請參閱 索引表模式。

• 只存取單一分區的查詢比從多個分區擷取數據的查詢更有效率，因此請避免實作分區化系統，以執行大量查詢來聯結位於不同分區中的數據。 請記住，單一分區可以包含多個實體類型的數據。 請考慮將您的數據反正規化，以保留通常一起查詢的相關實體（例如客戶的詳細數據，以及他們已放置的訂單）放在相同的分區中，以減少應用程式執行的個別讀取次數。

  如果某個分區中的實體參考另一個分區中儲存的實體，請包含第二個實體的分區索引鍵，做為第一個實體架構的一部分。 這有助於改善跨分區參考相關數據的查詢效能。

• 如果應用程式必須執行從多個分區擷取數據的查詢，則可能可以使用平行工作來擷取此數據。 範例包括展開查詢，其中多個分區的數據會以平行方式擷取，然後匯總成單一結果。 不過，這種方法不可避免地會對解決方案的數據存取邏輯增加一些複雜度。

• 對於許多應用程式而言，建立較多小型分區比擁有少量大型分區更有效率，因為它們可以提供增加的負載平衡機會。 如果您預期需要將分區從某個實體位置移轉至另一個位置，這也很有用。 移動小型分區比移動大型分區更快。

• 請確定每個分區記憶體節點可用的資源都足以處理數據大小和輸送量方面的延展性需求。 如需詳細資訊，請參閱數據分割指引中的一節。

• 請考慮將所有分區的參考數據複寫。 如果從分區擷取數據的作業也會參考靜態或移動緩慢的數據做為相同查詢的一部分，請將此數據新增至分區。 然後，應用程式可以輕鬆地擷取查詢的所有數據，而不需要對個別的數據存放區進行額外的來回行程。

  如果多個分區中保留的參考數據變更，系統必須跨所有分區同步處理這些變更。 發生此同步處理時，系統可能會經歷一定程度的不一致。 如果您這樣做，您應該將應用程式設計為能夠處理它。

• 很難維護分區之間的引用完整性和一致性，因此您應該將影響多個分區數據的作業降到最低。 如果應用程式必須修改跨分區的數據，請評估是否需要完整的數據一致性。 相反地，雲端中的常見方法是實作最終一致性。 每個分割區中的數據會個別更新，而且應用程式邏輯必須負責確保更新全部順利完成，以及處理在最終一致作業執行時查詢數據時可能發生的不一致。 如需實作最終一致性的詳細資訊，請參閱 數據一致性入門。

• 設定和管理大量的分區可能是一項挑戰。 監視、備份、檢查一致性和記錄或稽核等工作必須在多個分區和伺服器上完成，可能保留在多個位置。 這些工作可能會使用腳本或其他自動化解決方案來實作，但可能無法完全消除額外的系統管理需求。

• 分區可以異地配置，讓其包含的數據接近使用該分區的應用程式實例。 這種方法可以大幅改善效能，但需要對必須在不同位置存取多個分區的工作進行額外考慮。

使用此模式的時機

當資料存放區可能需要擴充到單一記憶體節點可用的資源之外，或藉由減少數據存放區中的爭用來改善效能時，請使用此模式。

工作負載設計

架構設計人員應該評估分區化模式在工作負載的設計中如何使用，以解決 Azure 良好架構架構支柱中涵蓋的目標和原則。 例如：

如同任何設計決策，請考慮對其他可能以此模式導入之目標的任何取捨。

範例

請考慮一個網站，以呈現全球出版書籍的廣泛資訊集合。 此工作負載中編錄的可能書籍數目和一般查詢/使用模式會違反指示單一關係資料庫用來儲存書籍資訊。 工作負載架構設計人員決定使用叢書的靜態國際標準書籍編號 （ISBN） 來分割多個資料庫實例的數據。 具體來說，他們會使用 ISBN的檢查位數 （0 - 10），因為它可提供11個可能的邏輯分區，而且數據會在每個分區之間相當平衡。 首先，他們決定將11個邏輯分區共置成三個實體分區資料庫。 他們會使用 查閱 分區化方法，並將索引鍵對伺服器對應資訊儲存在分區對應資料庫中。

查閱分區對應

分區對應資料庫包含下列分區對應數據表和數據。

SELECT ShardKey, DatabaseServer
FROM BookDataShardMap

| ShardKey | DatabaseServer |
|----------|----------------|
|        0 | bookdbshard0   |
|        1 | bookdbshard0   |
|        2 | bookdbshard0   |
|        3 | bookdbshard1   |
|        4 | bookdbshard1   |
|        5 | bookdbshard1   |
|        6 | bookdbshard2   |
|        7 | bookdbshard2   |
|        8 | bookdbshard2   |
|        9 | bookdbshard0   |
|       10 | bookdbshard1   |

範例網站程序代碼 - 單一分區存取

網站不知道實體分區資料庫的數目（在此案例中為三個），也不知道將分區索引鍵對應至資料庫實例的邏輯，但網站知道書籍 ISBN 的檢查位數應該視為分區索引鍵。 網站具有分區對應資料庫的唯讀存取權，以及所有分區資料庫的讀寫存取權。 在此範例中，網站使用裝載網站的 Azure App 服務 系統受控識別進行授權，以將秘密保留在 連接字串 外。

網站會使用下列 連接字串 來設定，不論是在此範例中appsettings.json，或是透過App Service 應用程式設定。

{
  ...
  "ConnectionStrings": {
    "ShardMapDb": "Data Source=tcp:<database-server-name>.database.windows.net,1433;Initial Catalog=ShardMap;Authentication=Active Directory Default;App=Book Site v1.5a",
    "BookDbFragment": "Data Source=tcp:SHARD.database.windows.net,1433;Initial Catalog=Books;Authentication=Active Directory Default;App=Book Site v1.5a"
  },
  ...
}

透過可用的分區對應資料庫連接資訊，網站對工作負載資料庫分區集區所執行的更新查詢範例看起來會類似下列程序代碼。

...

// All data for this book is stored in a shard based on the book's ISBN check digit,
// which is converted to an integer 0 - 10 (special value 'X' becomes 10).
int isbnCheckDigit = book.Isbn.CheckDigitAsInt;

// Establish a pooled connection to the database shard for this specific book.
using (SqlConnection sqlConn = await shardedDatabaseConnections.OpenShardConnectionForKeyAsync(key: isbnCheckDigit, cancellationToken))
{
  // Update the book's Library of Congress catalog information
  SqlCommand cmd = sqlConn.CreateCommand();
  cmd.CommandText = @"UPDATE LibraryOfCongressCatalog
                         SET ControlNumber = @lccn,
                             ...
                             Classification = @lcc
                       WHERE BookID = @bookId";

  cmd.Parameters.AddWithValue("@lccn", book.LibraryOfCongress.Lccn);
  ...
  cmd.Parameters.AddWithValue("@lcc", book.LibraryOfCongress.Lcc);
  cmd.Parameters.AddWithValue("@bookId", book.Id);

  await cmd.ExecuteNonQueryAsync(cancellationToken);
}

...

在上述範例程式代碼中，如果 book.Isbn 是 978-8-1130-1024-6，則 isbnCheckDigit 應該是 6。 的呼叫 OpenShardConnectionForKeyAsync(6) 通常會使用另行快取方法來實作。 如果分區索引鍵 6 沒有快取分區資訊，則會查詢以 連接字串 ShardMapDb 識別的分區對應資料庫。 無論是從應用程式的快取還是從分區資料庫，bookdbshard2 值都會取代 SHARD 連接字串 BookDbFragment 。 已建立集區連線，以 bookdbshard2.database.windows.net、開啟並傳回呼叫程序代碼。 然後，程式代碼會更新該資料庫實例上的現有記錄。

範例網站程式代碼 - 多個分區存取

在罕見的情況下，網站需要直接的跨分區查詢，應用程式會跨所有分區執行平行展開查詢。

...

// Retrieve all shard keys
var shardKeys = shardedDatabaseConnections.GetAllShardKeys();

// Execute the query, in a fan-out style, against each shard in the shard list.
Parallel.ForEachAsync(shardKeys, async (shardKey, cancellationToken) =>
{
  using (SqlConnection sqlConn = await shardedDatabaseConnections.OpenShardConnectionForKeyAsync(key: shardKey, cancellationToken))
  {
    SqlCommand cmd = sqlConn.CreateCommand();
    cmd.CommandText = @"SELECT ...
                          FROM ...
                         WHERE ...";

    SqlDataReader reader = await cmd.ExecuteReaderAsync(cancellationToken);

    while (await reader.ReadAsync(cancellationToken))
    {
      // Read the results in to a thread-safe data structure.
    }

    reader.Close();
  }
});

...

作為此工作負載中跨分區查詢的替代方案，可能會使用 Azure AI 搜尋中的外部維護索引，例如網站搜尋或多面向導覽功能。

新增分區實例

工作負載小組知道，如果數據目錄或其並行使用量大幅成長，可能需要超過三個資料庫實例。 工作負載小組不會預期會動態新增資料庫伺服器，而且如果新的分區需要上線，工作負載會持續停機。 讓新的分區實例上線需要將數據從現有的分區移至新的分區，以及更新分區對應數據表。 這個相當靜態的方法可讓工作負載在網站程序代碼中自信地快取分區索引鍵資料庫對應。

此範例中的分區索引鍵邏輯硬性上限為11個最大實體分區。 如果工作負載小組執行負載估計測試，並評估最終需要超過11個資料庫實例，則需要對分區索引鍵邏輯進行侵入性變更。 這項變更牽涉到仔細規劃程式碼修改和數據遷移至新的密鑰邏輯。

SDK 功能

評估彈性資料庫客戶端連結庫，而不是撰寫自定義程式碼以用於分區管理和查詢路由至 Azure SQL 資料庫 實例。 此連結庫支援 C# 和 Java 中的分區對應管理、數據相依查詢路由和跨分區查詢。

下一步

實作此模式時，下列指引也可能相關：

• 數據一致性入門。 可能需要維護分散到不同分區的數據一致性。 摘要說明維護分散式數據一致性的相關問題，並描述不同一致性模型的優點和取捨。
• 數據分割指引。 將數據存放區分區化可能會帶來一系列其他問題。 描述與分割雲端中數據存放區相關的這些問題，以改善延展性、減少爭用，以及優化效能。

相關資源

實作此模式時，下列模式也可能相關：

• 索引數據表模式。 有時候無法完全透過分區索引鍵的設計來支持查詢。 可讓應用程式藉由指定分區索引鍵以外的索引鍵，從大型數據存放區快速擷取數據。
• 具體化檢視模式。 為了維護某些查詢作業的效能，建立具體化檢視來匯總和摘要數據會很有用，特別是此摘要數據是以分散於分區的資訊為基礎時。 描述如何產生和填入這些檢視。