數據分割的建議

發行項
07/03/2024

適用於此 Azure 架構完善的架構可靠性檢查清單建議：

RE：06	在應用程式、數據和基礎結構層級實作及時且可靠的調整策略。

相關指南：調整

本指南說明針對您所部署的資料庫和數據儲存技術設計數據分割策略的建議。此策略可協助您改善數據資產的可靠性。

關鍵設計策略

在許多大規模解決方案中，數據分割可用來分割數據，以便分開管理及存取數據。數據分割可改善延展性、減少爭用，並將效能優化。實作數據分割，以依使用模式分割數據。例如，您可以在廉價的數據記憶體中封存較舊的數據。請謹慎選擇數據分割策略，以最大化優點，並將不良影響降到最低。

注意

在本文中，數據分割一詞表示實際將數據分割成個別數據存放區的程式。它與 SQL Server 數據表分割不同。

為什麼要分割數據？

改善可擴縮性。 當您相應增加單一資料庫系統時，資料庫最終會達到實體硬體限制。如果您將數據分割到多個分割區，且每個分割區裝載在個別伺服器上，您幾乎可以無限期地向外延展系統。
改善效能。 在每個分割區中，相較於未分割的數據，數據存取作業會透過較小的數據量執行。分割數據，讓您的系統更有效率。影響多個分割區的作業可以平行執行。
改善安全性。 在某些情況下，您可以將敏感性和非敏感性數據分成不同的分割區，並將不同的安全性控制套用至敏感數據。
提供作業彈性。 您可以將數據分割為微調作業、將系統管理效率最大化，以及將成本降至最低。例如，您可以根據每個分割區中數據的重要性，定義管理、監視、備份和還原和其他系統管理工作的策略。
比對數據存放區與使用的模式。 您可以根據數據存放區所提供的成本和內建功能，在不同類型的數據存放區上部署每個分割區。例如，您可以將大型二進位數據儲存在 Blob 記憶體中，並將結構化數據儲存在檔案資料庫中。如需詳細資訊，請參閱瞭解數據存放區模型。
改善可用性。 若要避免單一失敗點，您可以跨多部伺服器分隔數據。如果一個實例失敗，則只有該分割區中的數據無法使用。作業會繼續在其他分割區中。此考慮與受控平臺即服務（PaaS）數據存放區較不相關，因為它們具有內建備援。

設計數據分割

分割資料有三個典型的策略：

水平數據分割 （通常稱為 分區化）。在此策略中，每個分割區都是個別的數據存放區，但所有分割區都有相同的架構。每個分割區稱為分區，並保存數據的子集，例如一組客戶訂單。
垂直數據分割。 在此策略中，每個分割區都會保存數據存放區中專案的字段子集。欄位會根據其使用模式來分割。例如，經常存取的欄位可能會放在一個垂直分割區中，而較不常存取的欄位則放在另一個數據分割中。
功能分割。 在此策略中，數據會根據系統中每個系結內容如何使用數據來匯總。例如，電子商務系統可能會將發票數據儲存在一個分割區中，並將產品清查數據儲存在另一個數據分割中。

當您設計數據分割配置時，請考慮結合這些策略。例如，您可以將數據分割成分區，然後使用垂直數據分割進一步細分每個分區中的數據。

水平資料分割（分區化）

下圖顯示水平數據分割或分區化範例。此範例會將產品清查數據分割成以產品密鑰為基礎的分區。每個分區都會保留連續分區索引鍵範圍的數據（A-G 和 H-Z），依字母順序排列。當您執行分區化時，它會將負載分散到更多計算機，以減少爭用並改善效能。

最重要的因素是您選擇的分區化索引鍵。在系統運作之後，可能很難變更密鑰。索引鍵必須確保數據已分割，以盡可能平均地分散工作負載到分區。

分區不需要相同大小。平衡要求數目更重要。某些分區可能很大，但分區中的每個專案都有少量的存取作業。其他分區可能較小，但分區中的每個項目都會更頻繁地存取。此外，請務必確保單一分區不會超過數據存放區容量和處理資源的調整限制。

避免建立 可能會影響效能和可用性的經常性 分割。例如，如果您使用客戶名稱的第一個字母，它可能會建立不平衡的分佈，因為某些字母比其他字母更常見。請改用客戶標識碼哈希，將數據平均分散到分割區。

選擇分區化索引鍵，以將未來需要分割大型分區、將小型分區合併成較大的分割區，或變更架構。這些作業相當耗時，而且可能需要脫機一或多個分區。

如果複寫分區，您可以在其他復本進行分割、合併或重新設定時，讓部分複本保持在線狀態。不過，系統可能會限制可在重新設定期間執行的作業。例如，複本中的數據可能會標示為唯讀，以防止數據不一致。

如需詳細資訊，請參閱分區化模式。

垂直資料分割

垂直數據分割最常見的用途是減少與擷取經常存取專案相關聯的 I/O 和效能成本。下圖顯示垂直數據分割的範例。在此範例中，專案的不同屬性會儲存在不同的分割區中。一個分割區會保存更頻繁存取的數據，包括產品名稱、描述和價格。另一個分割區會保存清查數據，包括庫存計數和最後一個排序日期。

在此範例中，應用程式會在向客戶顯示產品詳細數據時，定期查詢產品名稱、描述和價格。庫存計數和最後排序日期位於個別的數據分割中，因為這兩個專案通常一起使用。

請參閱下列垂直資料分割的優點：

您可以將相對緩慢行動的數據（產品名稱、描述和價格）與更動態的數據（庫存水準和上次訂購日期）分開。緩慢移動的數據是應用程式在記憶體中快取的良好候選專案。
您可以使用新增的安全性控制件，將敏感資料儲存在個別的數據分割中。
垂直數據分割可以減少所需的並行存取量。

垂直數據分割會在數據存放區內的實體層級運作，部分正規化實體，將其從寬項目細分為一組窄專案。它非常適合用於數據行導向的數據存放區，例如 HBase 和 Cassandra。如果數據行集合中的數據不太可能變更，請考慮在 SQL Server 中使用資料行存放區。

功能資料分割

當應用程式中的每個不同商務區域可以識別界限內容時，功能分割可以改善隔離和數據存取效能。功能分割的另一個常見用途是將讀寫數據與唯讀數據分開。下圖顯示功能分割的概觀，其中包含與客戶數據分開的清查數據。

此數據分割策略可協助減少系統不同部分的數據存取爭用。

設計延展性的數據分割

請務必考慮每個分割區的大小和工作負載。平衡它們，讓數據散發以達到最大延展性。不過，您也必須分割數據，使其不會超過單一數據分割存放區的調整限制。

當您設計資料分割以進行延展性時，請遵循下列步驟：

分析應用程式以了解資料存取模式，例如每個查詢傳回的結果集大小、存取頻率、固有延遲，以及伺服器端計算處理需求。在許多情況下，少數主要實體需要大部分的處理資源。
使用此分析來判斷目前和未來的延展性目標，例如數據大小和工作負載。然後將數據分散到分割區，以符合延展性目標。針對水平數據分割，請選擇正確的分區索引鍵，以確保平均分佈。如需詳細資訊，請參閱分區化模式。
請確定每個分割區有足夠的資源來處理數據大小和輸送量方面的延展性需求。視數據存放區而定，每個分割區可能會限制儲存空間、處理能力或網路頻寬。如果需求可能超過這些限制，您可能需要精簡數據分割策略或進一步分割數據。您可能需要結合兩個或多個策略。
監視系統，確認數據是否如預期般散發，而且數據分割可以處理負載。實際使用量不一定符合分析所預測的內容。您可能需要重新平衡數據分割，或重新設計系統的某些部分，以產生所需的平衡。

某些雲端環境會根據基礎結構界限配置資源。請確定所選界限的限制可提供足夠的空間，以預期的數據量、數據儲存、處理能力和頻寬成長。

例如，如果您使用 Azure 數據表記憶體，單一分割區可以在特定時段內處理的要求數量有限制。如需詳細資訊，請參閱標準記憶體帳戶的延展性和效能目標。忙碌分區可能需要比單一分割區可以處理的更多資源。您可能需要重新分割分區以分散負載。如果這些數據表的總大小或輸送量超過記憶體帳戶的容量，您可能需要建立更多記憶體帳戶，並將數據表分散到這些帳戶。

設計查詢效能的數據分割

您可以使用小型資料集和執行平行查詢來提升查詢效能。每個分割區都應該包含整個數據集的一小部分。減少磁碟區可以改善查詢的效能。不過，數據分割不是適當的資料庫設計和設定的替代方案。請確定您實作必要的索引。

當您設計查詢效能的數據分割時，請遵循下列步驟：

檢查應用程式需求和效能。
- 使用商務需求來判斷必須一律快速執行的重要查詢。
- 監視系統，以識別執行速度緩慢的查詢。
- 判斷最常執行的查詢。即使單一查詢的成本最低，累積資源耗用量可能相當重要。
分割造成效能緩慢的數據。
- 限制每個分割區的大小，讓查詢回應時間在目標內。
- 如果您使用水平數據分割，請設計分區索引鍵，讓應用程式可以輕鬆地選取適當的分割區。此規格可防止查詢掃描每個分割區。
- 請考慮分割區的位置。嘗試將數據保留在地理位置接近應用程式與存取資料的應用程式和用戶的數據分割中。
如果實體具有輸送量和查詢效能需求，請使用以該實體為基礎的功能分割。如果此配置仍然不符合需求，您可以新增水平數據分割。單一數據分割策略通常已足夠，但在某些情況下，合併這兩個策略會更有效率。
跨分割區平行執行查詢，以改善效能。

設計可用性的數據分割

分割數據以改善應用程式的可用性。數據分割可確保整個數據集沒有單一失敗點，而且您可以獨立管理數據集的個別子集。

請考慮影響可用性的下列因素：

判斷數據的關鍵性。 識別重要的商務數據，例如交易，以及較不重要的作業數據，例如記錄檔。

將重要數據儲存在高可用性分割區中，並建立適當的備份計劃。
為不同的數據集建立不同的管理和監視程式。
將具有相同嚴重性層級的數據放在相同的分割區中，以便以相同頻率進行備份。例如，您可能需要備份保存事務數據的數據分割，而不是保存記錄或追蹤信息的數據分割。

管理個別分割區。 設計數據分割以支持獨立的管理和維護。這種做法提供數個優點，例如：

如果分割區失敗，則可以獨立復原，而不需要存取其他分割區中的數據的應用程式。
依地理區域分割數據可讓每個位置的排程維護工作在離峰時間進行。請確定分割區沒有太大，因此無法在此期間完成計劃性維護。

跨分割區復寫重要數據。 此策略可改善可用性和效能，但也可能會帶來一致性問題。將變更與每個復本同步處理所需的時間。在同步處理期間，不同的分割區包含不同的數據值。

應用程式設計考量

數據分割會增加系統設計和開發的複雜性。即使系統一開始只包含單一分割區，分割數據也是系統設計的基本部分。如果您以事後方式處理數據分割，這很困難，因為您已經有一個要維護的實時系統。您可以：

必須修改數據存取邏輯。
必須移轉大量的現有數據，以將其分散到分割區。
遇到挑戰，因為用戶預期會在移轉期間繼續使用系統。

在某些情況下，數據分割並不重要，因為初始數據集很小，而且單一伺服器可以輕鬆地處理它。有些工作負載不需要分割區，但隨著用戶數目增加，許多商業系統需要擴充。

某些小型數據存放區也受益於數據分割。例如，數百個並行用戶端可能會存取小型數據存放區。如果您在此情況下分割數據，有助於減少爭用並改善輸送量。

設計資料分割配置時，請考慮下列幾點：

最小化跨分割區數據存取作業。 嘗試將數據保留在分割區中最常見的資料庫作業，以將跨分割區數據存取作業降到最低。跨分割區進行查詢，而不是在單一數據分割內進行查詢可能更耗時。但優化一組查詢的數據分割可能會對其他一組查詢造成負面影響。如果您必須跨分割區查詢，請執行平行查詢並匯總應用程式內的結果，將查詢時間降至最低。在某些情況下，您無法使用此方法，例如，如果下一個查詢中使用來自一個查詢的結果。

復寫靜態參考數據。 如果查詢使用相對靜態的參考數據，例如郵遞區數據表或產品清單，請考慮在所有分割區中複寫此數據，以減少不同數據分割中的個別查閱作業。這種方法也可以降低參考數據成為 來自整個系統大量流量的經常 性數據集的可能性。同步處理參考數據的變更時，會有額外的成本。

最小化跨分割區聯結。 可能的話，請將跨垂直和功能性分割區引用完整性的需求降到最低。在這些配置中，應用程式會負責維護分割區之間的引用完整性。跨多個分割區聯結數據的查詢效率不佳，因為應用程式通常會執行以索引鍵和外鍵為基礎的連續查詢。相反地，請考慮復寫或取消正規化相關數據。如果需要跨分割區聯結，請對分割區執行平行查詢，並聯結應用程式內的數據。

接受最終一致性。 評估強式一致性是否為需求。分散式系統中的常見方法是實作最終一致性。每個分割區中的數據會個別更新，而應用程式邏輯可確保更新順利完成。應用程式邏輯也會處理在最終一致作業執行時，查詢數據所產生的不一致。

請考慮查詢如何找出正確的分割區。 如果查詢必須掃描所有分割區以找出所需的數據，即使執行多個平行查詢，也會大幅影響效能。透過垂直和功能性數據分割，查詢可以指定分割區。另一方面，水平數據分割可能會使尋找專案變得困難，因為每個分區都有相同的架構。典型的解決方案是維護用來查閱專案分區位置的對應。在應用程式的分區化邏輯中實作此對應。如果數據存放區支援透明分區化，數據存放區也可以由數據存放區維護。

定期重新平衡分區。 使用水平數據分割，重新平衡分區有助於依大小和工作負載平均分散數據。重新平衡分區，以將熱點降到最低、將查詢效能最大化，以及解決實體記憶體限制。這項工作很複雜，而且通常需要自定義工具或程式。

複寫數據分割。 復寫每個分割區，以提供針對失敗的新增保護。如果單一複本失敗，查詢會導向至工作複本。

將延展性延伸至不同的層級。 如果您達到數據分割策略的實體限制，您可能需要將延展性延伸至不同的層級。例如，如果數據分割位於資料庫層級，您可能需要找出或復寫多個資料庫中的數據分割。如果數據分割已經在資料庫層級，而且有實體限制，您可能需要在多個主控帳戶中找出或復寫分割區。

避免存取多個分割區中數據的交易。 某些數據存放區會針對修改數據的作業實作交易一致性和完整性，但只有在數據位於單一分割區時。如果您需要跨多個分割區的交易支援，請將它實作為應用程式邏輯的一部分，因為大部分的數據分割系統都不提供原生支援。

所有數據存放區都需要一些作業管理和監視活動。這些工作包括載入數據、備份和還原數據、重新組織數據，以及確保系統能夠正確且有效率地執行。

請考慮下列會影響作業管理的因素：

在分割數據時，實作適當的管理和操作工作。 這些工作可能包括備份和還原、封存數據、監視系統和其他系統管理工作。例如，在備份和還原作業期間維護邏輯一致性可能很困難。
將數據載入多個分割區，並新增來自其他來源的新數據。 某些工具和公用程式可能不支援分區化數據作業，例如將數據載入正確的分割區。
定期封存和刪除數據。 若要防止分割區過度成長，請封存和刪除每個月的數據。您可能需要轉換數據，以符合不同的封存架構。
找出數據完整性問題。 請考慮執行定期程式來找出數據完整性問題，例如某個數據分割中的數據參考另一個數據分割中遺漏的資訊。此程式可以自動嘗試修正這些問題，或產生報告以進行手動檢閱。

重新平衡數據分割

隨著系統成熟，您可能必須調整數據分割配置。例如，個別分割區可能會開始接收不成比例的流量並變成經常性存取，而導致過度爭用。或者，您可能低估了某些分割區中的數據量，這會導致分割區接近容量限制。

某些數據存放區，例如 Azure Cosmos DB，可以自動重新平衡數據分割。在其他情況下，您可以在兩個階段中重新平衡分割區：

判斷新的數據分割策略。
- 哪些分割區需要分割或合併？
- 新的分割區索引鍵是什麼？
將數據從舊的數據分割配置遷移至新的數據分割集。

重新放置數據時，您可能需要讓分割區無法使用，這稱為 離線移轉。視數據存放區而定，您可能會在數據分割使用時，在數據分割之間移轉數據。這項技術稱為 在線移轉。

離線移轉

離線移轉可減少發生爭用的機會。若要執行離線移轉：

將分割區標示為離線。您可以將分割區標示為唯讀，讓應用程式在行動資料時仍可讀取數據。
分割合併並將數據移至新的分割區。
Verify the data.
讓新的分割區上線。
拿掉舊的分割區。

線上移轉

相較於離線移轉，在線移轉更為複雜，但較不干擾。此程式類似於離線移轉，但不會將原始分割區標示為離線。根據移轉程式的數據粒度，例如逐專案逐項與分區，用戶端應用程式中的數據存取程式代碼可能必須讀取和寫入位於兩個位置的數據，原始分割區和新的分割區。

Azure 便利化

下列各節說明分割儲存在 Azure 服務中的數據的建議。

Azure SQL 資料庫中的數據分割

單一 SQL 資料庫對可以包含的數據量有限制。輸送量受限於架構因素及其支援的並行連線數目。

彈性集區支援 SQL 資料庫的水平調整。使用彈性集區將數據分割成分散於多個 SQL 資料庫的分區。您也可以在數據量成長和縮小時新增或移除分區。彈性集區也可以藉由將負載分散到資料庫，來協助減少爭用。

每個分區都會實作為 SQL 資料庫。分區可以保存多個數據集。每個數據集稱為 shardlet。每個資料庫都有描述其包含之shardlet的元數據。 shardlet 可以是單一數據項或共用相同 shardlet 索引鍵的專案群組。例如，在多租用戶應用程式中，shardlet 金鑰可以是租用戶標識碼，而租使用者的所有數據都可以位於相同的 shardlet 中。

應用程式負責將數據集與 shardlet 索引鍵產生關聯。個別的 SQL 資料庫會作為全域分區對應管理員。此資料庫具有系統中所有分區和shardlet的清單。應用程式會連線到分區對應管理員資料庫，以取得分區對應複本。它會在本機快取分區對應，並使用對應將數據要求路由至適當的分區。這項功能隱藏在 SQL 資料庫彈性資料庫功能用戶端連結庫中的一系列 API 後方，可供 Java 和 .NET 使用。

如需彈性集區的詳細資訊，請參閱使用 SQL 資料庫相應放大。

若要減少延遲並改善可用性，您可以復寫全域分區對應管理員資料庫。使用進階定價層，您可以設定作用中異地複寫，以持續將數據複製到不同區域中的資料庫。

或者，針對 SQL 資料庫或 Azure Data Factory 使用 SQL 資料同步，跨區域複寫分區對應管理員資料庫。這種形式的復寫會定期執行，如果分區對應不常變更，而且不需要進階層，則更適合。

彈性資料庫提供兩種配置來將數據對應至shardlet，並將其儲存在分區中：

清單分區對應會將單一索引鍵與shardlet產生關聯。例如，在多租用戶系統中，每個租用戶的數據都可以與唯一索引鍵相關聯，並儲存在自己的shardlet中。為了保證隔離，每個 Shardlet 都可以保存在自己的分區內。

下載此圖表的 Visio 檔案。
範圍 分區對應 會將一組連續索引鍵值與shardlet產生關聯。例如，您可以將一組租用戶的數據分組在相同的shardlet內，每個租使用者都有自己的密鑰。此配置比清單分區對應便宜，因為租使用者共享數據記憶體，但提供較少的隔離。

下載此圖表的 Visio 檔案

單一分區可以包含數個shardlet的數據。例如，您可以使用 list shardlet 來儲存相同分區中不同非連續租用戶的數據。您也可以在相同的分區中混合範圍 shardlet 和列出 shardlet，但接著會透過不同的對應來尋址。下圖顯示此方法：

下載此圖表的 Visio 檔案。

透過彈性集區，您可以在數據量成長和縮小時新增和移除分區。用戶端應用程式可以動態和透明地更新分區對應管理員，以動態和透明的方式建立和刪除分區。不過，移除分區是破壞性作業，也需要刪除該分區中的所有數據。

如果應用程式需要將分區分割成兩個不同的分區或合併分區，請使用分割合併工具。此工具會以 Azure Web 服務的形式執行，並在分區之間安全地移轉數據。

數據分割配置可能會大幅影響系統的效能。它也可以影響必須新增或移除分區的速率，或必須在分區之間重新分割數據。請考慮下列幾點：

將相同分區中使用的數據分組，並避免從多個分區存取數據的作業。分區是自己的許可權中的 SQL 資料庫，而且當作業存取多個分區時，必須在用戶端上執行跨資料庫聯結。

雖然 SQL 資料庫不支援跨資料庫聯結，但您可以使用彈性資料庫工具來執行多分區查詢。多分區查詢會將個別查詢傳送至每個資料庫，並合併結果。
設計在分區之間沒有相依性的系統。某個資料庫中的引用完整性條件約束、觸發程式和預存程式無法參考另一個資料庫中的物件。
如果您有查詢經常使用的參考數據，請考慮跨分區複寫數據。這種方法可以消除跨資料庫聯結數據的需求。在理想情況下，這類數據應該是靜態或緩慢移動，以將復寫工作降到最低，並減少其過時的機會。
針對屬於相同分區對應的 Shardlet 使用相同的架構。 SQL 資料庫不會強制執行本指南，但如果每個shardlet都有不同的架構，數據管理和查詢就會很複雜。相反地，請為每個架構建立個別的分區對應。您可以將屬於不同 shardlet 的數據儲存在相同的分區中。
如果您的商業規則需要執行交易，請在相同的分區中儲存數據，或實作最終一致性。交易式作業僅支援分區中的數據，而不是跨分區。如果交易屬於相同分區的一部分，則交易可以跨越shardlet。
將分區放在接近存取這些分區中數據的使用者附近。此策略有助於降低延遲。
避免有高度作用中和相對非使用中分區的組合。嘗試將負載平均分散到分區。您可能必須哈希分區化索引鍵。如果您要異地定位分區，請確定哈希索引鍵會對應至儲存在靠近存取該數據之使用者的分區中保留的shardlet。

Azure Blob 儲存體中的數據分割

使用 Blob 記憶體，您可以儲存大型二進位物件。在需要您快速上傳或下載大量數據的案例中使用區塊 Blob。針對需要隨機而非序列存取數據部分的應用程式使用分頁 Blob。

每個區塊 Blob 或分頁 Blob 都會保留在 Azure 記憶體帳戶中的容器中。使用容器來群組具有相同安全性需求的相關 Blob。此群組是邏輯的，而不是實體的。在容器內，每個 Blob 都有唯一的名稱。

Blob 的數據分割索引鍵是帳戶名稱、容器名稱和 Blob 名稱。數據分割索引鍵是用來將數據分割成範圍。這些範圍會跨系統進行負載平衡。 Blob 可以分散到許多伺服器，以相應放大存取它們。單一 Blob 只能由單一伺服器提供服務。

如果您的命名配置使用時間戳或數值標識符，可能會導致流量過多到一個分割區。它可防止系統有效地進行負載平衡。例如，如果您有每日作業使用具有時間戳的 Blob 物件，例如 yyyy-mm-dd，該作業的所有流量都會移至單一數據分割伺服器。請改用三位數哈希作為名稱的前置詞。如需詳細資訊，請參閱分割區命名慣例。

寫入單一區塊或頁面的動作不可部分完成，但跨越區塊、分頁或 Blob 的作業則不是。如果您需要確保跨區塊、頁面和 Blob 執行寫入作業時的一致性，請使用 Blob 租用來取出寫入鎖定。

考量

數據分割引進了您需要考慮的一些挑戰和複雜度。

分割區之間的數據同步處理可能會成為挑戰。請確定一個數據分割的更新或變更會以及時且一致的方式傳播至其他分割區。
當您需要協調多個分割區的備份和還原時，故障轉移和災害復原程式會變得複雜。如果某些分割區或其備份損毀或無法使用，可能會發生數據完整性問題。
如果您需要跨分割區進行查詢，而且當您重新平衡數據分割時，數據分割可能會影響效能和可靠性。如果數據成長不平均，數據分割就會重新平衡。

可靠性檢查清單

請參閱一組完整的建議。

可靠性檢查清單

共用方式為

數據分割的建議