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