分片模式

將資料存放區分割成一組水平分區或分片。 這種方法能提升你儲存和存取大量資料時的可擴展性。

內容和問題

單一伺服器上的資料儲存有以下限制：

• 儲存空間： 大型雲端應用的資料儲存庫可以包含大量資料，且資料會隨時間成長。 伺服器提供的磁碟儲存空間有限，你可以用較大的磁碟取代現有磁碟，或隨著資料卷增加增加磁碟數量。 系統最終會達到無法在單一伺服器上增加儲存容量的極限。

• 計算資源： 雲端應用程式必須支援大量同時使用者，每人對資料儲存庫執行查詢。 單一伺服器可能無法提供足夠的運算能力來應付此負載，導致回應時間延長與逾時。 你可以增加記憶體或升級處理器，但系統會達到無法再增加運算資源的極限。

• 網路頻寬： 單一伺服器接收請求並發送回覆的速度限制了資料儲存效能。 網路流量量可能超過網路連線容量，導致請求失敗。

• 地理： 法律、合規或效能要求可能要求你將使用者資料存放在與使用者相同的地理區域。 如果使用者跨國或跨地區，可能無法將所有應用程式資料儲存在同一個資料庫中。

為了暫時延緩這些限制，你可以透過增加磁碟容量、運算能力、記憶體和網路連線來垂直擴展。 一個必須支援大量使用者和大量資料的雲端應用程式，必須具備橫向擴展。

解決方案

將數據存放區分割成水準分割區或分區。 每個分片擁有相同的結構結構，但包含其獨特的資料子集。 每個分片是一個完整的資料儲存庫，可以包含多種不同類型的實體資料。 分片運行在作為儲存節點的伺服器上。

此模式具有下列優點：

• 你可以透過在額外的儲存節點上增加更多碎片來擴展系統規模。

• 系統可以使用預建硬體，而非每個儲存節點的專用且昂貴的電腦。

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

• 在雲端中，分片可以物理上靠近存取資料的使用者。

當你將資料儲存區劃分為分片時，決定要將哪些資料放入每個分片。 每個分片通常包含依一個或多個資料屬性分組的項目。 這些屬性構成分片鍵，有時稱為 分割鍵。

分片會實質性地組織數據。 當應用程式儲存並檢索資料時，分片邏輯會將其導向適當的分片。 你可以將此邏輯實作在應用程式的資料存取程式碼中，或是在透明地支援分片的資料儲存系統中。

在分片邏輯中抽象資料的物理位置，可以控制哪些分片包含哪些資料。 當你需要重新分配資料時，例如分片失衡時，也能在不修改應用程式商業邏輯的情況下，在分片間遷移資料。 這種取捨會導致在檢索過程中判斷每個資料項目的位置而產生額外的資料存取開銷。

分片金鑰選擇

分片金鑰是分片系統中最關鍵的設計決策。 在選擇分片金鑰後更改，通常必須將所有資料遷移到新的分片配置，這在運作中的系統中是一項昂貴且風險較高的操作。 在撰寫任何程式碼前，請謹慎做出這個決定。

有效的分片金鑰是不可變的，基數高，資料分配和載入均勻，且與你主導的查詢模式對齊，使大多數請求都能針對單一分片解決。 避免單調遞增的值（自增整數與連續時間戳記）、低基數屬性（布林值與小型枚舉集合）以及頻繁變動的揮失性屬性。 這些特性會導致熱點或代價高昂的跨分片資料移動。

若無單一屬性符合這些條件，則透過結合兩個或多個屬性來定義複合分片鍵。 如果查詢需要透過不屬於分片鍵的屬性來取得資料，可以使用像 索引表（Index Table ）這類模式來提供次要查找。

欲了解更多關於如何在 Azure 服務間選擇分割鍵的資訊，請參閱 資料分割指引 與 資料分割策略。

分片策略

當你選擇分片金鑰並決定如何在分片間分配資料時，請採用以下策略之一。 你不需要分片和主機伺服器之間一對一的對應。 單一伺服器可以承載多個分片。

查詢分片策略

在查找策略（也稱為 目錄基礎策略）中，分片邏輯實作一個映射，利用分片鍵將資料請求路由至包含該資料的分片。 在多租戶應用程式中，你可以用租戶 ID 作為分片鍵，將所有租戶資料集中存放在分片中。 多個租戶可能共用同一個分片，但單一租戶的資料不會分散在多個分片上。 下圖顯示根據租戶 ID 分片租戶資料的情況。

兩個應用程式實例會向分片邏輯元件發送特定租戶的查詢。 分片邏輯會根據租戶 ID 將每個請求導向正確的分片，例如 A、B、或 C。 每個分片儲存一個獨特的資料子集。

分片金鑰值與實體儲存之間的對應可以直接進行，每個分片金鑰值會對應到一個實體分割區。 較靈活的技術是虛擬分割，將分片鍵值映射到虛擬分片，系統再將這些虛擬分片映射到較少的實體分區。 應用程式透過使用指向虛擬分片的分片金鑰值來定位資料，系統則透明地將虛擬分片映射到實體分割區。 虛擬分片與實體分割區之間的映射可以改變，而不需要修改應用程式碼。

基於範圍的分片策略

基於範圍的策略將相關物品分組在同一分片中，並按照順序分片鍵排序。 此策略支援經常透過範圍查詢來檢索項目集合的應用程式。 範圍查詢會回傳一組屬於特定範圍內的分片金鑰的資料項目。

例如，如果應用程式需要定期查找某個月份內的所有訂單，若將該月份的所有訂單以日期和時間順序儲存在同一分片中，就能更快取得資料。 如果你將每個訂單存放在不同的分片中，應用程式必須透過大量點查詢來逐一取得它們。 下圖顯示了儲存在分片中的連續資料集合或範圍。

申請實例會對特定月份的訂單提出查詢。 一個分片邏輯元件每個月對應到一個分片，例如十月對應到分片 A、十一月對應到分片 B、十二月對應到分片 C。訂單會依日期和時間順序儲存在每個分片內。

在此範例中，分片鍵是一個複合鍵，包含訂單月份作為最高有效元素，接著是訂單日期與時間。 新訂單在建立並加入分片時，會自動按順序排序。

部分資料儲存支援兩部分分片金鑰。 分割鍵用於識別分片，列鍵則唯一識別分片中的項目。 分片通常依列鍵順序儲存資料。 對於需要範圍查詢且必須分組的項目，你可以使用在分區鍵上有相同值但在列鍵上有唯一值的分片鍵。

基於雜湊的分片策略

基於雜湊的策略降低了熱點（hotspots）的機率，熱點是承受過多負載的分片。 此策略將資料分散到各個分片，以平衡每個分片的大小與平均負載。 分片邏輯會根據資料中一個或多個屬性的哈希值來計算應儲存物件的分片。 所選的雜湊函數應該能將資料均勻分布在各個分片之間。 下圖顯示根據租戶 ID 雜湊值分片租戶資料。

應用程式實例會針對特定租戶提交查詢。 分片邏輯元件會雜湊租戶 ID，並將每個請求路由到一個分片，例如租戶 55 轉到分片 B，租戶 56 轉到分片 N。每個分片儲存一部分租戶資料。

為了理解雜湊策略相較於其他分片策略的優勢，請考慮一個多租戶應用程式，若依序註冊新租戶，可能會將租戶分配到資料儲存中的分片。 使用範圍策略時，租戶 1 到 n 的資料會儲存在分片 A，租戶 n+1 到 m 的資料存放在分片 B，後續的租戶範圍則會對應到後續的分片。 如果最近註冊的租戶同時也是最活躍的，大部分資料活動集中在少數分片中，這可能導致熱點。 相較之下，哈希策略則根據租戶 ID 的哈希值將租戶分配到分片。 雜湊通常會將順序排列的租戶分配到不同的分片，以平衡負載。 前一圖展示了55號與56號租戶的此方法。

地理分片策略

地理策略根據資料的地理來源或預期消費區域，將資料分配給分片。 在許多工作負載中，使用者及其產生的資料集中在特定區域。 像資料駐留法等法規要求，特定資料必須留在特定司法管轄區內。 即使沒有監管驅動程式，將資料放置在最常存取的使用者附近，也能降低讀寫的網路延遲。

應用程式實例會將查詢路由到分片邏輯元件，該元件將區域映射到分片。 來自亞太地區的請求路由到分片A、歐洲的請求到分片B，以及美洲的請求到分片C。每個分片儲存其指定區域的資料。

在此策略中，你從地理屬性（如使用者的國家/地區、來源資料中心區域或區域租戶識別碼）推導分片金鑰。 你將每個分片託管在該地理範圍內的基礎設施中，或將其釘接到該基礎設施上。

例如，服務北美、歐洲及 Asia-Pacific 客戶的應用程式，可能會維護三個分片群組，分別位於每個對應的 Azure 區域。 僅服務歐洲用戶的歐洲應用程式會將請求路由至歐洲分片。 此方法降低延遲並符合資料駐留要求。

地理分片帶來資料分布不均的風險。 如果你的大多數使用者都住在同一個區域，該區域的分片會承擔不成比例的負載和儲存。 你可以在每個區域內結合地理分片與其他策略，例如雜湊或查找，讓負載均勻分配到同一地理邊界內的多個分片。

每種策略的優點與考量

四種分片策略具有以下優點與考量：

• 查找策略 提供對分片配置的更多控制。 虛擬分片減少了重新平衡的影響，因為你可以新增實體分區來平衡工作負載。 你可以修改虛擬分片與其實體分割區之間的映射，而不會影響應用程式程式碼。 查找分片位置會增加負擔。

• 範圍策略 易於實作，且與範圍查詢良好配合。 範圍查詢可在一次操作中從單一分片取得多個資料項目。 資料管理更簡單。 例如，當同一區域的使用者共用分片時，你可以根據當地負載模式排程更新。 然而，這種策略無法在分片間均勻分配負載。 重新平衡是困難的，且當大多數活動集中在相鄰的分片鍵上時，可能無法解決負載不均的問題。

• 雜湊策略 提供更好的平均資料與負載分配機會。 你可以直接使用雜湊函數來路由請求，而不需要維護映射。 計算雜湊值會增加一些成本。 缺乏一致性哈希，重新平衡會變得很困難。

• 地理策略 符合其他策略未涵蓋的資料駐留與主權要求。 當使用者存取其區域資料時，它能降低讀寫延遲。 然而，當使用者群體在不同區域分布不均時，地理分片會造成大量資料和負載失衡。 跨區域查詢，如全球報告，必須從所有地理分片取得資料，且會產生較高的延遲。 當你需要合規性甚至負載分配時，可以將地理分片與每個區域內的其他策略結合。

大多數分片系統都採用其中一種方法，但你也應該考慮應用程式的業務需求及其資料使用模式。 例如，在多租使用者應用程式中：

• 你可以根據工作負載來分片資料。 將高波動租戶的資料隔離到不同的分片中，以提升其他租戶的資料存取速度。

• 你可以根據租戶位置來分片資料。 在該區域的非尖峰時段，將特定地理區域的租戶資料離線備份與維護，而其他地區的租戶資料則在營業時間保持線上狀態。

• 為高價值租戶分配專屬的、負載輕的分片。 價值較低的租戶可以共享更高密度的分片。

• 將資料儲存給需要強力資料隔離與隱私的租戶，分別存放在不同的伺服器上。

每種策略的擴展與資料移動操作

每種分片策略都提供不同的能力與複雜度，以管理縮減、擴展、資料移動及狀態維護。

• 查詢策略 允許在使用者層級進行擴展與資料移動操作，無論是線上或離線。 要移動資料：

  1. 暫停部分或全部用戶活動，通常在非尖峰時段。

  2. 將資料移到新的虛擬分割區或實體分片。

  3. 更新映射。

  4. 取消或刷新存放這些資料的快取。

  5. 恢復使用者活動。

  你通常可以集中管理這個運作。 查找策略要求狀態高度可快取且對複製友善。

• 範圍策略 限制了縮放和資料移動操作，因為你必須在分片間分割並合併資料，通常是在部分或全部資料儲存離線時。 當你移動資料以重新平衡分片時，如果大部分活動集中在相鄰或同一範圍內的分片金鑰或資料識別碼上，可能無法消除不均勻的負載。 範圍策略也可能要求狀態將範圍映射到實體分割區。

• 雜湊策略 使擴展與資料移動操作變得複雜。 分割鍵是分片鍵或資料識別碼的雜湊值。 使用標準雜湊函數，例如 hash(key) mod N，新增或移除分片會重新分配大部分金鑰並觸發大規模資料遷移。 一致性雜湊透過安排雜湊空間，使得當分片數量改變時，只有少部分金鑰會移動，從而減少這種影響。 雜湊策略不需要維護獨立的映對狀態。

• 地理策略將擴展作業直接連結到區域基礎設施配置。 在一個地區增加產能並不會減輕另一個地區的負擔。 強制執行地理分片的法規要求也可能限制跨地理界線的資料流動。 在每個區域內，調整規模使用輔助策略，將資料分配到該區域的分片。

問題和考慮

在決定如何實施此模式時，請考慮以下幾點：

• 將分片作為垂直分割和功能分割等其他分割形式的補充使用。 例如，一個分片可以包含垂直分割的實體，功能性分區也可以實作為多個分片。 欲了解更多資訊，請參閱 水平、垂直及功能性資料分割。

• 保持分片平衡，讓它們能處理相似的輸入/輸出（I/O）體積。 隨著時間的推移，由於紀錄的插入和刪除，數據傾斜會累積，從而導致熱點。 計劃定期重新平衡。

  重新平衡會在分片間移動資料，常導致停機或吞吐量下降。 若要減少重新平衡頻率，建議使用虛擬分割區。 將許多邏輯分割區映射到較少的實體分片。 當分片超載時，將其虛擬分割區重新分配到新的實體分片，且不重排整個資料集。 Azure Cosmos DB 採用此方法將分割方案與實體基礎設施分離。

  偏好多碎片勝過少數大碎片。 較小的分片遷移速度更快，負載平衡更均勻，且在資料再分配上提供更多彈性。

• 針對分片鍵使用穩定的數據。 如果分片鍵改變，你可能需要在分片間移動對應的資料項目，這會增加更新操作的負擔。 避免將分片鑰匙建立在可能不穩定的資訊上。 選擇不變或自然形成鍵的屬性。

• 確保分片鍵是唯一的。 例如，避免使用自動遞增欄位作為分片鍵。 在某些系統中，自動增量欄位無法跨分片協調，可能導致不同分片中的項目擁有相同的分片金鑰。

  備註

  其他欄位中非分片鍵的自動遞增值也可能造成問題。 例如，如果你使用自動遞增欄位來產生唯一 ID，不同分片中的兩個項目可能會被分配相同的 ID。

• 將資料分割以支援最常執行的查詢。 你可能無法設計出一個分金鑰，能讓每個查詢的需求都與資料相匹配。 如有必要，建立次級索引表，支援透過非分片鍵屬性檢索資料的查詢。 欲了解更多資訊，請參閱 指數表模式。

• 設計你的分片金鑰和資料模型，讓大部分操作都集中在單一分片上。 僅存取單一分片的查詢，比從多個分片擷取資料的查詢更有效率。 將資料非正規化，將常被查詢的相關實體（如顧客及其訂單）保持在同一分片中，以減少獨立讀取次數。

  跨分片查詢會增加延遲、資源消耗與複雜度。 當應用程式必須從多個分片擷取資料時，請使用平行的散出查詢，同時對每個分片執行並彙總結果。 即使有平行運算，最慢的分片也決定整體延遲。

  小提示

  如果一個分片中的一個實體參考另一個分片中的另一個實體，請將第二個實體的分片金鑰作為第一個實體的結構圖的一部分。 此方法能提升跨分片查詢相關資料的效能。

• 如果你的工作量需要跨分片邊界的強大交易完整性，請重新考慮你的分片金鑰，或是分片是否適合你的需求。 跨分片交易對於整個系統的運行帶來挑戰。 分散式協調協定，如兩階段提交，會增加延遲、引入失敗模式並降低吞吐量。 大多數分片系統避免分散式交易，改採最終一致性。 在此模型中，每個分片獨立更新，應用程式處理暫時性的不一致。

• 確保每個分片儲存節點可用的資源能應付資料大小和吞吐量的擴展需求。 如需詳細資訊，請參閱 數據分割策略。

• 請考慮將參考數據複製到所有分片。 如果對某個分片的查詢同時也引用靜態或緩變的資料，請將這些資料加入分片。 應用程式接著可以擷取查詢的所有資料，而無需往返於獨立的資料儲存庫。

  備註

  若多個分片中的參考資料有所變動，系統必須在所有分片間同步這些變更。 在同步執行過程中，可能會出現一定程度的不一致。 設計你的應用程式時要容忍這種不一致。

• 分片系統會增加營運負擔。 針對這些問題做規劃：

  • 監測： 你必須彙整所有分片的指標與日誌，才能完整掌握系統健康狀況。

  • 備份與還原： 你必須獨立備份每個分片，並設計還原程序以維持跨分片一致性。 一個分片的即時還原可能會與其他分片產生不一致。

  • 架構變更： 你必須協調每個分片之間的資料定義語言（DDL）變更。

  你可以透過腳本或其他自動化解決方案來實作這些任務。

• 你可以將分片地理定位，將它們的資料放置在使用這些分片的應用程式實例附近。 此方法可提升效能，但需額外規劃需存取位於不同地點的多個分片的操作。

使用此模式的時機

小提示

在設計自訂分片層之前，先確定你的資料平台已經處理哪些分片職責。 有些服務會完全管理分片。 例如，Azure Cosmos DB 在實體分割區間分配資料、處理分割及路由查詢，無需應用程式介入。 其他服務則部分管理分片。 例如，Azure SQL Database 提供 彈性資料庫工具 用於分片地圖管理和資料依賴路由，但你要設計分片金鑰並管理分割操作。 當你自己建置和操作分片邏輯時，請使用分片模式。

當下列情況時，請使用此模式：

• 總資料量超過單一資料庫實例的儲存容量，且沒有任何垂直縮放選項能彌補這個缺口。

• 交易吞吐量或查詢並行性超過單一實例所能承受的範圍，而僅靠讀取副本無法解決瓶頸，因為寫入負載也很高。

  備註

  分片提升系統的效能與可擴展性，也能提升可用性。 一個分割區的故障不一定會阻止應用程式存取其他分割區的資料。 操作員可以維護或恢復一個分割區，而不會讓所有資料無法使用。 如需詳細資訊，請參閱 資料分割指引。

• 法規或合規要求特定資料子集必須位於特定地理管轄區，單一區域部署無法滿足所有要求。

• 不同的租戶或客戶區段因安全、效能或合約理由需要實體資料隔離。

  在這類情境下，分片模式有時會應用於傳統資料儲存之外。 例如，DNS 區域管理系統可以依團隊、環境或區域分片，以減少 DNS 變更的範圍範圍並建立明確的所有權邊界。 在這樣的情境下，主要動機是營運分隔，而非可擴展性。 欲了解更多資訊，請參閱 分片私有 DNS 區域。

分片會為你的資料架構帶來大量且永久性的複雜性。 這種複雜性影響系統的開發、營運、測試、查詢設計及故障復原，涵蓋整個系統生命週期。

在下列情況下，此模式可能不適用：

• 即使預期有成長，你的資料量和吞吐量也只能集中在單一資料庫實例中。 垂直擴展則保留查詢的簡潔性與交易完整性。

• 你的瓶頸是讀取量，不是寫入量或儲存容量。 讀取副本和快取層可以分散讀取負載，而不會像分片一樣帶來跨分片查詢的複雜性。

• 你的資料庫引擎支援符合效能需求的資料表層級分割。 在單一實例內分割不需要多台伺服器或路由邏輯。

• 你的主導查詢模式需要跨實體連接、多實體交易或完整資料集聚合。 分片技術使這些操作的成本大幅提高，且扇出查詢與分散式協調的額外負擔可能超過擴展帶來的效益。

工作負載設計

評估如何在工作負載設計中使用分片模式，以達成 Azure Well-Architected Framework 支柱所涵蓋的目標與原則。 下表提供此模式如何支援每個要素目標的指引。

支柱	此模式如何支援支柱目標
可靠性 設計決策有助於使工作負載具有韌性，並確保在故障發生後能復原到正常運作的狀態。	資料與處理被隔離到各個分片，因此某個分片發生故障時，該故障會被限制在那個分片之內。 - 資料分割 - RE：07 自我保護
成本優化 專注於 維持並提升 您的工作負載的 投資報酬率。	實作分區的系統通常受益於使用成本較低的計算或記憶體資源的多個實例，而不是單一成本更高的資源。 在許多情況下，此設定可以節省您的成本。 - CO：07 元件成本
效能效率 可透過調整、數據和程式碼的優化， 有效率地協助您的工作負載符合需求 。	當你在擴展策略中使用分片時，資料和處理會被隔離在每個分片，因此請求只會在分配的分片內競爭資源。 您也可以使用分區化，根據地理位置進行優化。 - PE：05 縮放和分區 - PE：08 數據效能

如果此模式在一個支柱內部引入取捨，請將它們與其他支柱的目標進行考量。

範例

試想一個網站，能呈現全球出版書籍的豐富資訊。 此工作負載中可能編目的書籍數量及典型的查詢與使用模式，超出單一關聯式資料庫所能處理的範圍。 工作負載架構師決定將資料分片到多個資料庫實例，並使用書籍的靜態 ISBN 作為分片鍵。 具體來說，架構師使用 ISBN 的 校驗碼 （0 - 10），該碼提供 11 種可能的邏輯分片，且資料分布相當均衡。

首先，架構師將 11 個邏輯分片集中在三個實體分片資料庫中。 在此 虛擬分割方法中，許多邏輯分割對應到較少的實體節點。 架構師採用 查找 分片方法，並將金鑰到伺服器的映射儲存在分片映射資料庫中。

Azure App Service 標示為書籍目錄網站。 它能連接多個 SQL 資料庫實例和一個 Azure AI 搜尋實例。 其中一個資料庫被標記為 ShardMap 資料庫。 它包含一個範例表格，鏡像映射表的一部分，該部分將在本文稍後列出。 該表格包含三個分片資料庫實例：bookdbshard0、bookdbshard1 和 bookdbshard2。 其他資料庫下方也包含相同的表格範例列表。 表格包括書籍、國會圖書館目錄，以及更多表格的指示。 AI 搜尋用於多面向的導航與網站搜尋。 管理身份與應用程式服務相關聯。

查找分片對應

分片對應資料庫包含下列分片對應資料表和資料。

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 Service 主機的系統管理身份來授權，這會將秘密排除在連線字串之外。

網站會使用以下連線字串配置，這些配置可以在 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) 呼叫通常採用快取旁路模式。 如果沒有 shard key 6 的快取分片資訊，該方法會查詢由 ShardMapDb 連接字串所識別的分片映射資料庫。 此方法會從應用程式快取或分片資料庫取得 bookdbshard2 值，並在連接字串中替換為SHARDBookDbFragment 該方法接著建立或重新建立一個與 bookdbshard2.database.windows.net 的池連線，開啟連線，並將連線回傳給呼叫程式碼。 然後，程式代碼會更新該資料庫實例上的現有記錄。

範例網站程式碼：多重分片存取

在極少數情況下，網站需要進行直接跨分片查詢，應用程式會在所有分片上進行平行的扇出式查詢。

...

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

// Run 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))
    {
      // Collect the results into a thread-safe data structure.
    }

    reader.Close();
  }
});

...

作為跨分片查詢的替代方案，此工作負載可利用 Azure AI Search 中外部維護的索引進行網站搜尋或分面導覽。

新增分片實例

工作負載團隊知道，如果資料目錄或其同時使用量大幅增加，可能需要超過三個資料庫實例。 工作負載團隊不期望動態新增資料庫伺服器，且當新分片上線時，他們會接受工作負載停機。 要讓新的分片實例上線，他們必須將現有分片的資料移入新分片，並更新分片映射表。 使用這種相當穩定的方法，運行負載可以自信地將分片鍵資料庫映射快取在網站程式碼中。

此範例中的分片金鑰邏輯上限為 11 個實體分片。 如果工作負載團隊透過負載估計判斷最終需要超過 11 個資料庫實例，他們必須對分片金鑰邏輯進行侵入式變更。 此變更涉及對程式碼修改及資料遷移至新金鑰邏輯的謹慎規劃。

SDK 功能

與其撰寫自訂程式碼來管理分片或查詢路由到 SQL 資料庫實例，不如評估 彈性資料庫客戶端函式庫。 此程式庫支援 C# 和 Java 中的分片圖管理、依據數據的查詢路徑和跨分片查詢。

下一個步驟

• Azure Cosmos DB中的一致性等級：將資料分散到各個分片會帶來一致性的取捨。 本文描述了從強一致性到最終一致性模型的光譜，以及它們對可用性與延遲的影響。

相關資源

• 水平、垂直與功能性資料分割：本文說明了雲端資料分割的其他策略，以提升可擴展性、減少爭用並優化效能。
• 索引表模式：有時候你無法僅靠分片鍵的設計來支援所有查詢。 應用程式可以使用索引表模式，透過指定除分片鍵外的鍵，從大型資料儲存庫取得資料。
• 實體化檢視模式：為了維持某些查詢操作的效能，你可以建立實體化檢視來彙整和摘要資料，特別是當你將資料分散到多個分片時。