在許多大規模解決方案中，數據會分割成可以分開管理和存取的數據分割。 資料分割可以改善延展性、減少爭用，以及最佳化效能。 它也提供機制以根據使用模式來分隔資料。 例如，您可以將較舊的資料封存至成本較低的資料儲存空間。
不過，必須謹慎選擇數據分割策略，以發揮最大效益，同時將負面影響降至最低。
注意
在本文中，數據分割一詞表示實際將數據分割成個別數據存放區的程式。 它與 SQL Server 數據表分割不同。
為什麼要分割數據？
改善延展性。 當您相應增加單一資料庫系統時，最終會達到實體硬體限制。 如果您將資料分割到多個分割區，每個分割區都裝載在個別伺服器上，您可以幾乎無限期地向外延展系統。
改善效能。 每個分割區上的數據存取作業都會發生在較小的數據量上。 正確完成，數據分割可讓系統更有效率。 影響多個分割區的作業可以平行執行。
改善安全性。 在某些情況下，您可以將敏感性和非敏感性數據分成不同的分割區，並將不同的安全性控制套用至敏感數據。
提供作業彈性。 數據分割提供許多微調作業、最大化系統管理效率，以及將成本降至最低的機會。 例如，您可以根據每個分割區中數據的重要性，定義管理、監視、備份和還原和其他系統管理工作的不同策略。
比對數據存放區與使用的模式。 數據分割可根據數據存放區所提供的成本和內建功能，將每個數據分割部署在不同類型的數據存放區上。 例如，大型二進位數據可以儲存在 Blob 記憶體中，而更多的結構化數據可以保留在文件資料庫中。 請參閱 選擇正確的資料存放區。
改善可用性。 跨多部伺服器分隔數據可避免單一失敗點。 如果一個實例失敗，則只有該分割區中的數據無法使用。 其他分割區的作業可以繼續。 針對受控平臺即服務 （PaaS） 數據存放區，此考慮較不相關，因為這些服務是使用內建備援所設計。
設計數據分割
分割資料有三個典型的策略：
水平數據分割 （通常稱為 分區化）。 在此策略中，每個分割區都是個別的數據存放區，但所有分割區都有相同的架構。 每個分割區稱為 分區 ，並保存特定數據子集，例如特定一組客戶的所有訂單。
垂直數據分割。 在此策略中，每個分割區都會保存數據存放區中專案的字段子集。 欄位會根據其使用模式來分割。 例如，經常存取的欄位可能會放在一個垂直分割區中，而較不常存取的欄位則放在另一個數據分割中。
功能分割。 在此策略中，數據會根據系統中每個系結內容使用的方式進行匯總。 例如，電子商務系統可能會將發票數據儲存在一個分割區中，並將產品清查數據儲存在另一個數據分割中。
這些策略可以合併，建議您在設計數據分割配置時將其全部納入考慮。 例如，您可以將數據分割成分區，然後使用垂直數據分割進一步細分每個分區中的數據。
水平資料分割 （分區化）
圖 1 顯示水平數據分割或分區化。 在此範例中，產品清查數據會根據產品密鑰分割成分區。 每個分區都會保留連續分區索引鍵範圍的數據（A-G 和 H-Z），依字母順序排列。 分區化會將負載分散到更多計算機，以減少爭用並改善效能。
圖 1 - 根據數據分割索引鍵水準分割（分區化）數據。
最重要的因素是選擇分區化索引鍵。 在系統運作之後，可能很難變更密鑰。 索引鍵必須確保數據已分割，以盡可能平均地分散工作負載到分區。
分區不需要相同大小。 平衡要求數目更重要。 某些分區可能非常大，但每個專案都有少量的存取作業。 其他分區可能較小，但每個專案存取頻率會更高。 請務必確保單一分區不會超過數據存放區容量和處理資源的規模限制。
避免建立可能會影響效能和可用性的「經常性」分割區。 例如，使用客戶名稱的第一個字母會導致分佈不平衡，因為某些字母比較常見。 請改用客戶標識碼的哈希，將數據平均分散到分割區。
選擇分區化索引鍵，以將大型分區分割、將小型分區合併成較大的分割區，或變更架構的任何未來需求。 這些作業可能非常耗時，而且在執行分區時可能需要脫機一或多個分區。
如果複寫分區，可能會讓部分複本保持在線狀態，而其他複本則會進行分割、合併或重新設定。 不過，系統可能需要限制可在重新設定期間執行的作業。 例如，複本中的數據可能會標示為唯讀，以避免數據不一致。
如需水平數據分割的詳細資訊，請參閱 分區化模式。
垂直資料分割
垂直數據分割最常見的用途是減少與擷取經常存取之專案相關聯的 I/O 和效能成本。 圖 2 顯示垂直數據分割的範例。 在此範例中，專案的不同屬性會儲存在不同的分割區中。 一個分割區會保存更頻繁存取的數據，包括產品名稱、描述和價格。 另一個分割區會保存清查數據：庫存計數和上次排序日期。
圖 2 - 依其使用模式垂直分割數據。
在此範例中，應用程式會在向客戶顯示產品詳細數據時，定期查詢產品名稱、描述和價格。 庫存計數和最後排序日期會保留在個別的數據分割中，因為這兩個專案通常一起使用。
垂直資料分割的其他優點：
相對緩慢行動的數據（產品名稱、描述和價格）可以與更動態的數據（庫存水平和最後訂購日期）分開。 緩慢移動數據是應用程式在記憶體中快取的良好候選專案。
敏感數據可以儲存在具有其他安全性控件的個別分割區中。
垂直數據分割可以減少所需的並行存取量。
垂直數據分割會在數據存放區內的實體層級運作，部分正規化實體，將其從 寬 項目細分為一組 窄 專案。 它非常適合數據行導向的數據存放區，例如 HBase 和 Cassandra。 如果數據行集合中的數據不太可能變更，您也可以考慮在 SQL Server 中使用資料行存放區。
功能資料分割
當可以識別應用程式中每個不同商務區域的限定內容時，功能分割是改善隔離和數據存取效能的方法。 功能分割的另一個常見用途是將讀寫數據與唯讀數據分開。 圖 3 顯示功能分割的概觀，其中清查數據與客戶數據分開。
圖 3 - 依系結內容或子域以功能方式分割數據。
此數據分割策略可協助減少系統不同部分的數據存取爭用。
設計延展性的數據分割
請務必考慮每個分割區的大小和工作負載，並加以平衡，以便散發數據以達到最大延展性。 不過，您也必須分割數據，使其不會超過單一數據分割存放區的調整限制。
設計數據分割以進行延展性時，請遵循下列步驟：
- 分析應用程式以了解資料存取模式，例如每個查詢所傳回的結果集大小、存取頻率、固有延遲，以及伺服器端計算處理需求。 在許多情況下，一些主要實體會要求大部分的處理資源。
- 使用此分析來判斷目前和未來的延展性目標，例如數據大小和工作負載。 然後將數據分散到分割區，以符合延展性目標。 對於水平數據分割，選擇正確的分區索引鍵很重要，以確保分佈是偶數。 如需詳細資訊，請參閱 分區化模式。
- 請確定每個分割區有足夠的資源來處理數據大小和輸送量方面的延展性需求。 視數據存放區而定，每個分割區的儲存空間量、處理能力或網路頻寬可能會有限制。 如果需求可能超過這些限制，您可能需要精簡數據分割策略，或進一步分割數據，可能結合兩個或多個策略。
- 監視系統，確認數據是否如預期般散發，而且數據分割可以處理負載。 實際使用量不一定符合分析所預測的內容。 若是如此，則可能可以重新平衡數據分割，或重新設計系統的某些部分以取得所需的平衡。
某些雲端環境會根據基礎結構界限來配置資源。 請確定所選界限的限制在數據儲存、處理能力和頻寬方面，為數據量的任何預期成長提供足夠的空間。
例如，如果您使用 Azure 資料表記憶體，特定時段內單一分割區可以處理的要求數量有限制。 （如需詳細資訊，請參閱 Azure 記憶體延展性和效能目標。忙碌分區可能需要比單一分割區可以處理的更多資源。 如果是，可能需要重新分割分區以分散負載。 如果這些數據表的大小或輸送量總計超過記憶體帳戶的容量，您可能需要建立額外的記憶體帳戶，並將數據表分散到這些帳戶。
設計查詢效能的數據分割
查詢效能通常可藉由使用較小的數據集和執行平行查詢來提升。 每個分割區都應該包含整個數據集的一小部分。 減少磁碟區可以改善查詢的效能。 不過，數據分割不是適當地設計和設定資料庫的替代方案。 例如，請確定您已具備必要的索引。
設計查詢效能的數據分割時，請遵循下列步驟：
檢查應用程式需求和效能：
- 使用商務需求來判斷必須一律快速執行的重要查詢。
- 監視系統，以識別執行速度緩慢的任何查詢。
- 尋找最常執行的查詢。 即使單一查詢的成本最低，累積資源耗用量可能相當重要。
分割造成效能緩慢的數據：
- 限制每個分割區的大小，讓查詢回應時間在目標內。
- 如果您使用水平數據分割，請設計分區索引鍵，讓應用程式可以輕鬆地選取正確的分割區。 這可防止查詢掃描每個分割區。
- 請考慮分割區的位置。 可能的話，請嘗試將數據保留在數據分割中，且數據分割與存取它的應用程式和使用者相近。
如果實體具有輸送量和查詢效能需求，請使用以該實體為基礎的功能分割。 如果這仍然不符合需求，也請套用水平數據分割。 在大部分情況下，單一數據分割策略就已足夠，但在某些情況下，合併這兩個策略會更有效率。
請考慮跨分割區平行執行查詢，以改善效能。
設計可用性的數據分割
數據分割可以藉由確保整個數據集不會構成單一失敗點，而且可以獨立管理數據集的個別子集，以改善應用程式的可用性。
請考慮影響可用性的下列因素：
數據對商務營運有多重要。 識別哪些數據是重要的商務資訊，例如交易，以及哪些數據較不重要的作業數據，例如記錄檔。
請考慮使用適當的備份計劃，將重要數據儲存在高可用性分割區中。
為不同的數據集建立不同的管理和監視程式。
將具有相同嚴重性層級的數據放在相同的分割區中，以便以適當的頻率一起備份。 例如，保存事務數據的分割區可能需要比保存記錄或追蹤資訊的分割區更頻繁地備份。
如何管理個別分割區。 設計分割區以支持獨立管理和維護提供數個優點。 例如：
如果分割區失敗，則可以獨立復原，而不需要存取其他分割區中的數據的應用程式。
依地理區域分割數據可讓每個位置的排程維護工作在離峰時間進行。 請確定分割區太大，無法防止在此期間內完成任何計劃性維護。
是否要跨分割區復寫重要數據。 此策略可以改善可用性和效能，但也可能會帶來一致性問題。 將變更與每個復本同步處理所需的時間。 在此期間，不同的分割區會包含不同的數據值。
應用程式設計考量
數據分割會增加系統設計和開發的複雜性。 即使系統一開始只包含單一分割區，也請考慮將分割視為系統設計的基本部分。 如果您將數據分割視為事後考慮，將會更具挑戰性，因為您已經有一個要維護的實時系統：
- 必須修改數據存取邏輯。
- 可能需要移轉大量的現有數據，以將其分散到分割區。
- 用戶預期能夠在移轉期間繼續使用系統。
在某些情況下，數據分割並不重要，因為初始數據集很小，而且可由單一伺服器輕鬆處理。 對於某些工作負載而言，這可能是真的，但隨著用戶數目增加，許多商業系統需要擴充。
此外，它不只是受益於數據分割的大型數據存放區。 例如，數百個並行用戶端可能會大量存取小型數據存放區。 在此情況下，分割數據有助於減少爭用並改善輸送量。
設計資料分割配置時，請考慮下列幾點：
最小化跨分割區數據存取作業。 可能的話，請將每個分割區中最常見的資料庫作業的數據保持在一起，以將跨分割區數據存取作業降到最低。 跨分割區的查詢可能會比單一分割區內的查詢更耗時，但優化一組查詢的數據分割可能會對其他查詢集造成負面影響。 如果您必須跨分割區查詢，請執行平行查詢並匯總應用程式內的結果，將查詢時間降至最低。 （在某些情況下可能無法使用此方法，例如下一個查詢中使用來自某個查詢的結果時。
請考慮復寫靜態參考數據。 如果查詢使用相對靜態的參考數據，例如郵遞區數據表或產品清單，請考慮在所有分割區中複寫此數據，以減少不同分割區中的個別查閱作業。 這種方法也可以降低參考數據成為「經常性」數據集的可能性，而整個系統的流量會繁重。 不過，有額外的成本與同步處理參考數據的任何變更有關。
最小化跨分割區聯結。 可能的話，請將跨垂直和功能性分割區引用完整性的需求降到最低。 在這些配置中，應用程式會負責維護分割區之間的引用完整性。 跨多個分割區聯結數據的查詢效率不佳，因為應用程式通常需要根據索引鍵和外鍵執行連續查詢。 相反地，請考慮復寫或取消正規化相關數據。 如果需要跨分割區聯結，請對分割區執行平行查詢，並聯結應用程式內的數據。
接受最終一致性。 評估強式一致性是否實際上是需求。 分散式系統中的常見方法是實作最終一致性。 每個分割區中的數據會個別更新，而應用程式邏輯可確保更新都順利完成。 它也會處理在最終一致作業執行時，查詢數據時可能發生的不一致。
請考慮查詢如何找出正確的分割區。 如果查詢必須掃描所有分割區以找出所需的數據，即使執行多個平行查詢，也會對效能產生重大影響。 透過垂直和功能性數據分割，查詢可以自然地指定分割區。 另一方面，水平數據分割可能會使尋找專案變得困難，因為每個分區都有相同的架構。 維護地圖的一般解決方案，用來查閱特定專案的分區位置。 此對應可以在應用程式的分區化邏輯中實作，如果數據存放區支援透明分區化，則由資料存放區維護。
請考慮定期重新平衡分區。 使用水平數據分割，重新平衡分區可協助依大小和工作負載平均分散數據，以將熱點降到最低、查詢效能最大化，以及解決實體記憶體限制。 不過，這是一項複雜的工作，通常需要使用自定義工具或程式。
複寫數據分割。 如果您復寫每個分割區，它會提供額外的保護，以防止失敗。 如果單一複本失敗，查詢可以導向至工作複本。
如果您達到數據分割策略的實體限制，您可能需要將延展性延伸至不同的層級。 例如，如果數據分割位於資料庫層級，您可能需要找出或復寫多個資料庫中的數據分割。 如果數據分割已經在資料庫層級，而且實體限制是個問題，則可能表示您需要在多個主控帳戶中找出或復寫分割區。
避免存取多個分割區中數據的交易。 某些數據存放區會針對修改數據的作業實作交易一致性和完整性，但只有在數據位於單一分割區時。 如果您需要跨多個分割區的交易支援，您可能需要實作此作為應用程式邏輯的一部分，因為大部分的數據分割系統都不提供原生支援。
所有數據存放區都需要一些作業管理和監視活動。 這些工作的範圍包括載入數據、備份和還原數據、重新組織數據，以及確保系統能夠正確且有效率地執行。
請考慮下列會影響作業管理的因素：
如何在分割數據時實作適當的管理和操作工作。 這些工作可能包括備份和還原、封存數據、監視系統和其他系統管理工作。 例如，在備份和還原作業期間維護邏輯一致性可能是一項挑戰。
如何將數據載入多個分割區，並新增從其他來源抵達的新數據。 某些工具和公用程式可能不支援分區化數據作業，例如將數據載入正確的分割區。
如何定期封存和刪除數據。 若要防止數據分割過度成長，您必須定期封存和刪除數據（例如每月）。 可能需要轉換數據以符合不同的封存架構。
如何找出數據完整性問題。 請考慮執行定期程式來找出任何數據完整性問題，例如某個數據分割中的數據參考另一個數據中遺漏的資訊。 此程式可以嘗試自動修正這些問題，或產生報告以進行手動檢閱。
重新平衡數據分割
隨著系統成熟，您可能必須調整數據分割配置。 例如，個別分割區可能會開始取得不成比例的流量並變成經常性存取，而導致過度爭用。 或者，您可能低估了某些分割區中的數據量，導致某些分割區接近容量限制。
某些數據存放區，例如 Azure Cosmos DB，可以自動重新平衡數據分割。 在其他情況下，重新平衡是由兩個階段所組成的系統管理工作：
判斷新的數據分割策略。
- 哪些分割區需要分割（或可能合併）？
- 什麼是新的分割區索引鍵？
將數據從舊的數據分割配置遷移至新的數據分割集。
視數據存放區而定，您可能可以在資料分割之間移轉數據，而數據分割正在使用中。 這稱為 在線移轉。 如果不可能，您可能需要在數據重新放置時讓分割區無法使用（離線移轉）。
離線移轉
離線移轉通常比較簡單，因為它可減少發生爭用的機會。 在概念上，離線移轉的運作方式如下：
- 將分割區標示為離線。
- 分割合併並將數據移至新的分割區。
- Verify the data.
- 讓新的分割區上線。
- 拿掉舊的分割區。
您可以選擇性地在步驟 1 中將分割區標示為唯讀，讓應用程式在行動數據時仍可讀取數據。
線上移轉
在線移轉較複雜，但效能較低。 此程式類似於離線移轉，但原始分割區未標示為離線。 根據移轉程式的數據粒度（例如，依專案逐專案與分區分割），用戶端應用程式中的數據存取程式代碼可能必須處理在兩個位置、原始分割區和新分割區中保存的數據讀取和寫入。
下一步
- 瞭解特定 Azure 服務的數據分割策略。 請參閱 數據分割策略。
- Azure 記憶體延展性和效能目標
相關資源
- 選擇正確的資料存放區 \(部分機器翻譯\)
下列設計模式可能與您的案例相關：