本文說明在各種 Azure 資料存放區中分割數據的一些策略。 如需何時分割數據和最佳做法的一般指引，請參閱 數據分割。
分割 Azure SQL 資料庫
單一 SQL 資料庫對可以包含的數據量有限制。 輸送量受限於架構因素及其支援的並行連線數目。
彈性集 區支援 SQL 資料庫的水平調整。 使用彈性集區，您可以將數據分割成分散於多個 SQL 資料庫的分區。 您也可以新增或移除分區，因為您需要處理成長和縮小的數據量。 彈性集區也可以藉由將負載分散到資料庫，來協助減少爭用。
每個分區都會實作為 SQL 資料庫。 分區可以保存一個以上的數據集（稱為 shardlet）。 每個資料庫都會維護描述其包含之shardlet的元數據。 shardlet 可以是單一數據項，或共用相同 shardlet 索引鍵的專案群組。 例如，在多租用戶應用程式中，shardlet 金鑰可以是租用戶標識碼，而租使用者的所有數據都可以保留在相同的 shardlet 中。
用戶端應用程式負責將數據集與shardlet索引鍵產生關聯。 個別 SQL 資料庫 作為全域分區對應管理員。 此資料庫具有系統中所有分區和shardlet的清單。 應用程式會連線到分區對應管理員資料庫，以取得分區對應複本。 它會在本機快取分區對應，並使用對應將數據要求路由傳送至適當的分區。 這項功能隱藏在 彈性資料庫客戶端連結庫中的一系列 API 後方，可供 Java 和 .NET 使用。
如需彈性集區的詳細資訊，請參閱使用 Azure SQL 資料庫 相應放大。
若要減少延遲並改善可用性，您可以復寫全域分區對應管理員資料庫。 使用進階定價層，您可以設定作用中異地複寫，以持續將數據複製到不同區域中的資料庫。
或者，使用 Azure SQL 資料同步 或 Azure Data Factory，跨區域復寫分區對應管理員資料庫。 這種形式的復寫會定期執行，如果分區對應不常變更，而且不需要進階層，則更適合。
彈性資料庫提供兩種配置來將數據對應至shardlet，並將其儲存在分區中：
清單分區對應會將單一索引鍵與shardlet產生關聯。 例如，在多租用戶系統中，每個租用戶的數據都可以與唯一索引鍵相關聯，並儲存在自己的shardlet中。 為了保證隔離，每個 Shardlet 都可以保存在自己的分區內。
範圍 分區對應 會將一組連續索引鍵值與shardlet產生關聯。 例如，您可以將一組租用戶的數據分組在相同的shardlet內，每個租使用者都有自己的密鑰。 此配置比第一個配置便宜，因為租使用者共享數據記憶體，但隔離程度較低。
單一分區可以包含數個shardlet的數據。 例如，您可以使用 list shardlet 來儲存相同分區中不同非連續租用戶的數據。 您也可以在相同的分區中混合範圍 shardlet 和列出 shardlet，不過它們會透過不同的對應來尋址。 下圖顯示此方法：
彈性集區可讓您新增和移除分區，因為數據量會縮小和成長。 用戶端應用程式可以動態建立和刪除分區，並透明地更新分區對應管理員。 不過，移除分區是破壞性作業，也需要刪除該分區中的所有數據。
如果應用程式需要將分區分割成兩個不同的分區或合併分區，請使用 分割合併工具。 此工具會以 Azure Web 服務的形式執行，並在分區之間安全地移轉數據。
數據分割配置可能會大幅影響系統的效能。 它也可以影響必須新增或移除分區的速率，或必須在分區之間重新分割數據。 請考慮下列幾點：
將同一個分區中使用的數據分組，並避免從多個分區存取數據的作業。 分區是本身許可權中的 SQL 資料庫，而且必須在用戶端上執行跨資料庫聯結。
雖然 SQL 資料庫 不支援跨資料庫聯結，但您可以使用彈性資料庫工具來執行多分區查詢。 多分區查詢會將個別查詢傳送至每個資料庫，並合併結果。
請勿設計具有分區之間相依性的系統。 某個資料庫中的引用完整性條件約束、觸發程式和預存程式無法參考另一個資料庫中的物件。
如果您有查詢經常使用的參考數據，請考慮跨分區複寫此數據。 這種方法可以移除跨資料庫聯結數據的需求。 在理想情況下，這類數據應該是靜態或緩慢移動，以將復寫工作降到最低，並減少其過時的機會。
屬於相同分區對應的 Shardlet 應該具有相同的架構。 SQL 資料庫 不會強制執行此規則，但如果每個 Shardlet 有不同的架構，數據管理和查詢就會變得非常複雜。 相反地，請為每個架構建立個別的分區對應。 請記住，屬於不同 shardlet 的數據可以儲存在相同的分區中。
交易式作業僅支援分區內的數據，而不是跨分區。 只要交易屬於相同分區的一部分，交易就可以跨越shardlet。 因此，如果您的商業規則需要執行交易，請將數據儲存在相同的分區或實作最終一致性。
將分區放在接近存取這些分區中數據的使用者附近。 此策略有助於降低延遲。
避免混合高度作用中和相對非使用中的分區。 嘗試將負載平均分散到分區。 這可能需要哈希分區化索引鍵。 如果您要異地定位分區，請確定哈希索引鍵會對應至儲存在靠近存取該數據之使用者之分區中保留的shardlet。
分割 Azure 資料表記憶體
Azure 資料表記憶體是針對數據分割而設計的索引鍵/值存放區。 所有實體都會儲存在分割區中，而分割區是由 Azure 數據表記憶體在內部管理。 儲存在資料表中的每個實體都必須提供包含下列兩部分的索引鍵：
數據分割索引鍵。 這是一個字串值，決定 Azure 數據表記憶體將放置實體的分割區。 具有相同數據分割索引鍵的所有實體都會儲存在相同的分割區中。
數據列索引鍵。 這是識別數據分割內實體的字串值。 分割區中的所有實體都會依此索引鍵以遞增順序排序語彙。 每個實體的數據分割索引鍵/數據列索引鍵組合必須是唯一的，長度不能超過 1 KB。
如果實體已新增至具有先前未使用分割區索引鍵的數據表，Azure 數據表記憶體會為此實體建立新的分割區。 具有相同分割區索引鍵的其他實體會儲存在相同的分割區中。
此機制可有效地實作自動向外延展策略。 每個分割區都會儲存在 Azure 數據中心的同一部伺服器上，以協助確保從單一分割區快速執行擷取數據的查詢。
Microsoft已發佈 Azure 儲存體 的延展性目標。 如果您的系統可能超過這些限制，請考慮將實體分割成多個數據表。 使用垂直分割將欄位分割成最有可能一起存取的群組。
下圖顯示範例記憶體帳戶的邏輯結構。 記憶體帳戶包含三個數據表：客戶資訊、產品資訊和訂單資訊。
每個數據表都有多個分割區。
- 在 [客戶資訊] 數據表中，數據會根據客戶所在的城市進行分割。 數據列索引鍵包含客戶識別碼。
- 在 [產品資訊] 數據表中，產品會依產品類別來分割，而數據列索引鍵包含產品名稱。
- 在 Order Info 數據表中，訂單會依訂單日期進行分割，而數據列索引鍵會指定收到訂單的時間。 所有數據都會依每個分割區中的數據列索引鍵排序。
當您為 Azure 資料表記憶體設計實體時，請考慮下列幾點：
依數據存取方式選取數據分割索引鍵和數據列索引鍵。 選擇支援大部分查詢的數據分割索引鍵/數據列索引鍵組合。 最有效率的查詢會藉由指定數據分割索引鍵和數據列索引鍵來擷取數據。 藉由掃描單一數據分割，即可完成指定數據分割索引鍵和數據列索引鍵範圍的查詢。 這是相對快速的，因為數據會以數據列索引鍵順序保留。 如果查詢未指定要掃描的數據分割，則必須掃描每個分割區。
如果實體有一個自然索引鍵，請使用它作為分割區索引鍵，並將空字串指定為數據列索引鍵。 如果實體有包含兩個屬性的複合索引鍵，請選取最慢的變更屬性做為分割區索引鍵，另一個則選取為數據列索引鍵。 如果實體有兩個以上的索引鍵屬性，請使用串連屬性來提供數據分割和數據列索引鍵。
如果您使用數據分割和數據列索引鍵以外的欄位定期執行查詢，請考慮實 作索引表模式，或考慮使用不同的支援索引的數據存放區，例如 Azure Cosmos DB。
如果您使用單調序列來產生分割區索引鍵（例如 “0001”、“0002”、“0003”），而且每個分割區只包含有限的數據量，Azure 數據表記憶體可以在相同的伺服器上實際將這些分割區分組在一起。 Azure 儲存體 假設應用程式最有可能跨連續數據分割範圍執行查詢（範圍查詢），並針對此案例優化。 不過，這種方法可能會導致熱點，因為新實體的所有插入都可能會集中在連續範圍的一端。 它也可以減少延展性。 若要更平均地分散負載，請考慮哈希數據分割索引鍵。
Azure 數據表記憶體支援屬於相同分割區的實體的交易作業。 只要交易不包含超過 100 個實體，而且要求的承載不超過 4 MB，應用程式就可以執行多個插入、更新、刪除、取代或合併作業作為不可部分完成的單位。 跨越多個分割區的作業不是交易式，而且可能需要您實作最終一致性。 如需數據表記憶體和交易的詳細資訊，請參閱 執行實體群組交易。
請考慮資料分割索引鍵的資料粒度：
針對每個實體使用相同的分割區索引鍵，會導致在一部伺服器上保留的單一分割區。 這可防止分割區相應放大，並將負載放在單一伺服器上。 因此，此方法只適用於儲存少量實體。 不過，它確實可確保所有實體都可以參與實體群組交易。
針對每個實體使用唯一的數據分割索引鍵會導致數據表記憶體服務為每個實體建立個別的數據分割，而可能導致大量的小型分割區。 這種方法比使用單一分割區索引鍵更可調整，但無法進行實體群組交易。 此外，擷取多個實體的查詢可能涉及從多個伺服器讀取。 不過，如果應用程式執行範圍查詢，則針對分割區索引鍵使用單調序列可能有助於優化這些查詢。
跨實體子集共用分割區索引鍵，可讓您將相同分割區中的相關實體分組。 牽涉到相關實體的作業可以使用實體群組交易來執行，而透過存取單一伺服器即可滿足擷取一組相關實體的查詢。
如需詳細資訊，請參閱 Azure 儲存體 數據表設計指南和可調整的數據分割策略。
數據分割 Azure Blob 儲存體
Azure Blob 儲存體 可讓您保存大型二進位物件。 當您需要快速上傳或下載大量數據時，請使用區塊 Blob。 針對需要隨機而非序列存取數據部分的應用程式使用分頁 Blob。
每個 Blob（區塊或分頁）都會保留在 Azure 儲存體 帳戶的容器中。 您可以使用容器來群組具有相同安全性需求的相關 Blob。 此群組是邏輯的，而不是實體的。 在容器內，每個 Blob 都有唯一的名稱。
Blob 的數據分割索引鍵是帳戶名稱 + 容器名稱 + Blob 名稱。 分割區索引鍵是用來將數據分割成範圍，而且這些範圍會在系統之間進行負載平衡。 Blob 可以分散到許多伺服器，以相應放大存取它們，但單一 Blob 只能由單一伺服器提供服務。
如果您的命名配置使用時間戳或數值標識符，可能會導致過多的流量流向一個分割區，限制系統無法有效地進行負載平衡。 例如，如果您有每日作業使用具有時間戳的 Blob 物件，例如 yyyy-mm-dd，該作業的所有流量都會移至單一數據分割伺服器。 相反地，請考慮在名稱前面加上三位數哈希。 如需詳細資訊，請參閱 分割區命名慣例。
寫入單一區塊或頁面的動作不可部分完成，但跨越區塊、分頁或 Blob 的作業則不是。 如果您需要確保跨區塊、頁面和 Blob 執行寫入作業時的一致性，請使用 Blob 租用來取出寫入鎖定。
分割 Azure 儲存體 佇列
Azure 儲存體 佇列可讓您在進程之間實作異步傳訊。 Azure 儲存體 帳戶可以包含任意數目的佇列，而且每個佇列可以包含任意數目的訊息。 唯一的限制是記憶體帳戶中可用的空間。 個別訊息的大小上限為 64 KB。 如果您需要大於此的訊息，請考慮改用 Azure 服務匯流排 佇佇列。
每個記憶體佇列在包含它的記憶體帳戶內都有唯一的名稱。 Azure 分割區佇列會根據名稱。 相同佇列的所有訊息都會儲存在由單一伺服器控制的相同分割區中。 不同的佇列可以由不同的伺服器管理，以協助平衡負載。 將佇列配置給伺服器對應用程式和使用者而言是透明的。
在大規模的應用程式中，請勿針對應用程式的所有實例使用相同的記憶體佇列，因為這種方法可能會導致裝載佇列的伺服器成為熱點。 相反地，請針對應用程式的不同功能區域使用不同的佇列。 Azure 儲存體 佇列不支援交易，因此將訊息導向不同的佇列對傳訊一致性的影響不大。
Azure 儲存體 佇列每秒最多可以處理 2,000 則訊息。 如果您需要以比這個更高的速率處理訊息，請考慮建立多個佇列。 例如，在全域應用程式中，在不同的記憶體帳戶中建立個別的記憶體佇列，以處理在每個區域中執行的應用程式實例。
數據分割 Azure 服務匯流排
Azure 服務匯流排 會使用訊息代理程式來處理傳送至 服務匯流排 佇列或主題的訊息。 根據預設，傳送至佇列或主題的所有訊息都會由相同的訊息代理程序處理。 此架構可能會限制消息佇列的整體輸送量。 不過，您也可以在建立佇列或主題時分割佇列或主題。 若要這麼做，您可以將佇列或主題描述的 EnablePartitioning 屬性設定為 true。
分割的佇列或主題分成多個片段，每個片段都由個別的訊息存放區和訊息代理程序支援。 服務匯流排 負責建立和管理這些片段。 當應用程式將訊息張貼至分割的佇列或主題時，服務匯流排 將該訊息指派給該佇列或主題的片段。 當應用程式從佇列或訂用帳戶收到訊息時，服務匯流排 檢查每個片段是否有下一個可用的訊息，然後將它傳遞給應用程式進行處理。
此結構有助於將負載分散到訊息代理程式和訊息存放區，提高延展性並改善可用性。 如果暫時無法使用某個片段的訊息代理程式或訊息存放區，服務匯流排 可以從其中一個剩餘的可用片段擷取訊息。
服務匯流排 將訊息指派給片段，如下所示：
如果訊息屬於會話，則 SessionId 屬性具有相同值的所有訊息都會傳送至相同的片段。
如果訊息不屬於會話，但傳送者已指定 PartitionKey 屬性的值，則具有相同 PartitionKey 值的所有訊息都會傳送至相同的片段。
注意
如果同時指定 SessionId 和 PartitionKey 屬性，則必須將它們設定為相同的值，否則將會拒絕訊息。
如果未指定訊息的 SessionId 和 PartitionKey 屬性，但已啟用重複偵測，則會使用 MessageId 屬性。 具有相同 MessageId 的所有訊息都會導向至相同的片段。
如果訊息不包含 SessionId、PartitionKey 或 MessageId 屬性，則 服務匯流排 依序將訊息指派給片段。 如果片段無法使用，服務匯流排 會繼續下一個。 這表示訊息基礎結構中的暫時錯誤不會造成訊息傳送作業失敗。
在決定是否或如何分割 服務匯流排 消息佇列或主題時，請考慮下列幾點：
服務匯流排 佇列和主題是在 服務匯流排 命名空間的範圍內建立的。 服務匯流排 目前允許每個命名空間最多 100 個分割佇列或主題。
每個 服務匯流排 命名空間都會對可用資源施加配額，例如每個主題的訂用帳戶數目、每秒並行傳送和接收要求的數目，以及可建立的並行聯機數目上限。 這些配額記載於 服務匯流排 配額中。 如果您預期超過這些值，請使用自己的佇列和主題建立其他命名空間，並將工作分散到這些命名空間。 例如，在全域應用程式中，在每個區域中建立個別的命名空間，並將應用程式實例設定為使用最接近命名空間中的佇列和主題。
傳送做為交易一部分的訊息必須指定資料分割索引鍵。 這可以是 SessionId、 PartitionKey 或 MessageId 屬性。 作為相同交易一部分傳送的所有訊息都必須指定相同的分割區索引鍵，因為它們必須由相同的訊息代理程序處理。 您無法將訊息傳送至相同交易內的不同佇列或主題。
分割的佇列和主題無法設定為在閑置時自動刪除。
如果您要建置跨平臺或混合式解決方案，則分割佇列和主題目前無法與進階消息佇列通訊協定 （AMQP） 搭配使用。
分割 Azure Cosmos DB
適用於 NoSQL 的 Azure Cosmos DB 是用來儲存 JSON 檔的 NoSQL 資料庫。 Azure Cosmos DB 資料庫中的檔是物件或其他數據片段的 JSON 串行化表示法。 除非每個檔都必須包含唯一標識符，否則不會強制執行任何固定架構。
檔會組織成集合。 您可以將相關文件群組在集合中。 例如，在維護部落格文章的系統中，您可以將每個部落格文章的內容儲存為集合中的檔。 您也可以為每個主旨類型建立集合。 或者，在多租使用者應用程式中，例如不同作者控制及管理自己的部落格文章的系統，您可以依作者分割部落格，併為每個作者建立個別的集合。 配置給集合的儲存空間是彈性的，而且可以視需要壓縮或成長。
Azure Cosmos DB 支援根據應用程式定義的分割區索引鍵來自動分割數據。 邏輯分割區是一個分割區，可儲存單一分割區索引鍵值的所有數據。 共用數據分割索引鍵相同值的所有文件都會放在相同的邏輯分割區內。 Azure Cosmos DB 會根據分割區索引鍵的哈希來散發值。 邏輯分割區的大小上限為 20 GB。 因此，選擇分割區索引鍵是在設計時間的重要決策。 選擇具有各種值，甚至存取模式的屬性。 如需詳細資訊，請參閱 Azure Cosmos DB 中的數據分割和調整。
注意
每個 Azure Cosmos DB 資料庫都有一個 效能等級 ，可決定其取得的資源數量。 效能等級與 要求單位 （RU） 速率限制相關聯。 RU 速率限制會指定該集合保留且可供獨佔使用的資源數量。 集合的成本取決於針對該集合選取的效能等級。 效能等級越高（和 RU 速率限制），費用就越高。 您可以使用 Azure 入口網站 來調整集合的效能層級。 如需詳細資訊，請參閱 Azure Cosmos DB 中的要求單位。
如果 Azure Cosmos DB 提供的分割機制不足，您可能需要在應用層級將數據分區化。 檔集合提供在單一資料庫內分割數據的自然機制。 實作分區化最簡單的方式是為每個分區建立集合。 容器是邏輯資源，而且可以跨越一或多個伺服器。 固定大小的容器的最大限制為 20 GB 和 10,000 RU/秒的輸送量。 無限制的容器沒有記憶體大小上限，但必須指定分割區索引鍵。 使用應用程式分區化時，用戶端應用程式必須將要求導向至適當的分區，通常是根據定義分區索引鍵之數據的某些屬性來實作自己的對應機制。
所有資料庫都會建立在 Azure Cosmos DB 資料庫帳戶的內容中。 單一帳戶可以包含數個資料庫，並指定資料庫建立所在的區域。 每個帳戶也會強制執行自己的訪問控制。 您可以使用 Azure Cosmos DB 帳戶，將分區（資料庫內的集合）異地定位到需要存取它們的使用者，並強制執行限制，讓只有這些使用者可以連線到它們。
決定如何使用適用於 NoSQL 的 Azure Cosmos DB 分割數據時，請考慮下列幾點：
Azure Cosmos DB 資料庫可用的資源受限於帳戶的配額限制。 每個資料庫可以保存一些集合，而且每個集合都與管理該集合之 RU 速率限制（保留輸送量）的效能層級相關聯。 如需詳細資訊，請參閱 Azure 訂用帳戶和服務限制、配額與條件約束。
每個文件都必須有一個屬性，可用來唯一識別保存檔集合內的該檔。 這個屬性與分區索引鍵不同，它會定義保存檔的集合。 集合可以包含大量的檔。 理論上，它只受限於文件標識碼的最大長度。 檔標識碼最多可以有 255 個字元。
對檔的所有作業都會在交易的內容中執行。 交易的範圍會設定為包含檔的集合。 如果作業失敗，則會復原已執行的工作。 雖然檔受限於作業，但所做的任何變更都會受限於快照集層級隔離。 此機制可確保如果建立新檔的要求失敗，另一位同時查詢資料庫的使用者將不會看到接著移除的部分檔。
資料庫查詢的範圍也限於集合層級。 單一查詢只能從一個集合擷取數據。 如果您需要從多個集合擷取數據，您必須個別查詢每個集合，並在應用程式程式代碼中合併結果。
Azure Cosmos DB 支援可程式化專案，這些專案全都可以與檔一起儲存在集合中。 其中包括預存程式、使用者定義函式和觸發程式（以 JavaScript 撰寫）。 這些專案可以存取相同集合內的任何檔。 此外，這些專案會在環境交易的範圍內執行（如果是觸發程式，觸發程式會在針對文件執行建立、刪除或取代作業時引發），或啟動新交易（在明確用戶端要求執行之預存程序的情況下）。 如果可程式化專案中的程式代碼擲回例外狀況，則會回復交易。 您可以使用預存程式和觸發程式來維護檔之間的完整性和一致性，但這些檔都必須是相同集合的一部分。
您想要在資料庫中保存的集合不太可能超過集合效能層級所定義的輸送量限制。 如需詳細資訊，請參閱 Azure Cosmos DB 中的要求單位。 如果您預期達到這些限制，請考慮將集合分割到不同帳戶中的資料庫，以減少每個集合的負載。
分割 Azure 搜尋服務
搜尋數據的能力通常是許多 Web 應用程式所提供的流覽和探索主要方法。 其可協助用戶根據搜尋準則的組合快速尋找資源（例如電子商務應用程式中的產品）。 Azure 搜尋服務 透過 Web 內容提供全文搜尋功能，並包含預先輸入、根據接近相符專案的建議查詢，以及多面向導覽等功能。 如需詳細資訊，請參閱 什麼是 Azure 搜尋服務？。
Azure 搜尋服務會將可搜尋的內容儲存為資料庫中的 JSON 檔。 您可以定義索引，以指定這些檔中的可搜尋欄位，並將這些定義提供給 Azure 搜尋服務。 當使用者提交搜尋要求時，Azure 搜尋服務會使用適當的索引來尋找相符的專案。
為了減少爭用，Azure 搜尋服務所使用的記憶體可以分成 1、2、3、4、6 或 12 個分割區，而且每個分割區最多可以復寫 6 次。 分割區數目乘以複本數目的乘積稱為 搜尋單位 （SU） 。 Azure 搜尋服務的單一實例最多可以包含 36 個 SU（具有 12 個分割區的資料庫只支援最多 3 個複本）。
系統會針對配置給您服務的每個 SU 向您收費。 當可搜尋的內容量增加或搜尋要求的速度增加時，您可以將 SU 新增至現有的 Azure 搜尋服務實例，以處理額外的負載。 Azure 搜尋服務本身會將檔平均分散到分割區。 目前不支援手動分割策略。
每個分割區最多可以包含 1500 萬份檔，或佔用 300 GB 的儲存空間（以較小者為準）。 您最多可以建立 50 個索引。 服務的效能會因文件的複雜性、可用的索引和網路等待時間的影響而有所不同。 平均而言，單一複本 （1 SU） 應該能夠每秒處理 15 個查詢 （QPS），不過我們建議使用您自己的數據執行基準檢驗，以取得更精確的輸送量量值。 如需詳細資訊，請參閱 Azure 搜尋服務中的服務限制。
注意
您可以將一組有限的數據類型儲存在可搜尋的檔中，包括字串、布爾值、數值數據、日期時間數據，以及一些地理數據。 如需詳細資訊，請參閱 Microsoft 網站上的支持數據類型 （Azure 搜尋服務） 頁面。
您對於 Azure 搜尋服務如何分割每個服務實例的數據，有有限的控制權。 不過，在全域環境中，您可以使用下列任一策略來分割服務本身，以改善效能並減少延遲和爭用：
在每個地理區域中建立 Azure 搜尋服務的實例，並確定用戶端應用程式導向至最接近的可用實例。 此策略要求所有服務實例都能及時複寫可搜尋內容的任何更新。
建立兩層 Azure 搜尋服務：
- 每個區域中的本地服務，其中包含該區域中使用者最常存取的數據。 用戶可以在這裡導向要求，以取得快速但有限的結果。
- 包含所有數據的全域服務。 用戶可以在這裡導向要求，以取得較慢但更完整的結果。
當所搜尋的數據中有顯著的區域變化時，此方法最合適。
分割 Azure Cache for Redis
Azure Cache for Redis 會在雲端中提供共用快取服務，此服務是以 Redis 索引鍵/值數據存放區為基礎。 如同其名稱，Azure Cache for Redis 是作為快取解決方案。 只用於保存暫時性數據，而不是作為永久數據存放區。 如果快取無法使用，則使用 Azure Cache for Redis 的應用程式應該能夠繼續運作。 Azure Cache for Redis 支援主要/次要復寫以提供高可用性，但目前會將快取大小上限限製為 53 GB。 如果您需要超過此空間，您必須建立其他快取。 如需詳細資訊，請參閱 Azure Cache for Redis。
分割 Redis 數據存放區牽涉到將數據分割到 Redis 服務的實例。 每個實例都會構成單一分割區。 Azure Cache for Redis 會抽象化外觀後面的 Redis 服務，而不會直接公開它們。 實作數據分割最簡單的方式是建立多個 Azure Cache for Redis 實例，並將數據分散到其中。
您可以將每個數據項與識別碼（分割區索引鍵）產生關聯，以指定哪些快取會儲存數據項。 用戶端應用程式邏輯接著可以使用這個標識碼，將要求路由傳送至適當的分割區。 此配置非常簡單，但如果分割配置變更（例如，如果已建立額外的 Azure Cache for Redis 實例），用戶端應用程式可能需要重新設定。
原生 Redis （不是 Azure Cache for Redis）支援以 Redis 叢集為基礎的伺服器端數據分割。 在這種方法中，您可以使用哈希機制，將數據平均分割到伺服器。 每個 Redis 伺服器都會儲存描述數據分割所保存之哈希索引鍵範圍的元數據，也包含其他伺服器上哪些哈希索引鍵位於數據分割中的資訊。
用戶端應用程式只會將要求傳送至任何參與的 Redis 伺服器（可能是最接近的伺服器）。 Redis 伺服器會檢查用戶端要求。 如果它可以在本機解析，它會執行要求的作業。 否則，它會將要求轉送至適當的伺服器。
此模型是使用 Redis 叢集來實作，並在 Redis 網站上的 Redis 叢集教學課程頁面上詳細說明。 Redis 叢集對用戶端應用程式而言是透明的。 您可以將其他 Redis 伺服器新增至叢集（而且可以重新分割數據），而不需要重新設定用戶端。
重要
Azure Cache for Redis 目前僅支援進階層中的 Redis 叢集。
數據分割頁面 ：如何在 Redis 網站上的多個 Redis 實例 之間分割數據，提供有關使用 Redis 實作數據分割的詳細資訊。 本節的其餘部分假設您正在實作用戶端或 Proxy 輔助數據分割。
決定如何使用 Azure Cache for Redis 分割數據時，請考慮下列幾點：
Azure Cache for Redis 並非用來作為永久資料存放區，因此無論您實作何種數據分割配置，您的應用程式程式代碼都必須能夠從不是快取的位置擷取數據。
經常一起存取的數據應該保留在相同的分割區中。 Redis 是功能強大的索引鍵/值存放區，可提供數個高度優化的機制來建構數據。 這些機制可以是下列其中一項：
- 簡單字串（長度高達 512 MB 的二進位資料）
- 匯總類型，例如清單（可作為佇列和堆疊）
- 集合 （已排序與未排序 ）
- 哈希 （可將相關欄位分組在一起，例如代表物件中欄位的專案）
匯總類型可讓您將許多相關值與相同的索引鍵產生關聯。 Redis 索引鍵會識別清單、集合或哈希，而不是它所包含的數據項。 這些類型都可供 Azure Cache for Redis 使用，並由 Redis 網站上的 [資料類型] 頁面描述。 例如，在追蹤客戶所下訂單的電子商務系統中，每個客戶的詳細數據都可以儲存在使用客戶標識碼進行密鑰處理的 Redis 哈希中。 每個哈希都可以保存客戶的訂單標識碼集合。 個別的 Redis 集合可以保存訂單、再次結構化為哈希，並使用訂單標識碼進行索引鍵。 圖 8 顯示此結構。 請注意，Redis 不會實作任何形式的引用完整性，因此開發人員有責任維護客戶與訂單之間的關聯性。
圖 8。 Redis 記憶體中記錄客戶訂單及其詳細數據的建議結構。
注意
在 Redis 中，所有索引鍵都是二進位數據值（例如 Redis 字串），最多可包含 512 MB 的數據。 理論上，索引鍵幾乎可以包含任何資訊。 不過，我們建議針對描述數據類型的索引鍵採用一致的命名慣例，以識別實體，但不會過長。 常見的方法是使用 「entity_type：ID」 格式的索引鍵。 例如，您可以使用 「customer：99」 來指出標識碼為 99 的客戶密鑰。
您可以將相關信息儲存在相同資料庫中的不同匯總中，以實作垂直數據分割。 例如，在電子商務應用程式中，您可以在一個 Redis 哈希中儲存經常存取的產品相關信息，並在另一個哈希中較不常使用的詳細資訊。 這兩個哈希都可以使用與密鑰一部分相同的產品標識碼。 例如，您可以針對產品資訊使用 「product： nn」 （其中 nn 是產品識別碼），並針對詳細數據使用 「product_details： nn」。 此策略可協助減少大部分查詢可能擷取的數據量。
您可以重新分割 Redis 資料存放區，但請記住，這是一項複雜且耗時的工作。 Redis 叢集可以自動重新分割數據，但 Azure Cache for Redis 無法使用此功能。 因此，當您設計數據分割配置時，請嘗試在每個分割區中保留足夠的可用空間，以允許一段時間的預期數據成長。 不過，請記住，Azure Cache for Redis 的目的是暫時快取數據，且快取中保留的數據可以有有限的存留期指定為存留時間 （TTL） 值。 對於相對揮發性的數據，TTL 可能很短，但對於靜態數據而言，TTL 可能更長。 如果此數據的磁碟區可能填滿快取，請避免將大量數據儲存在快取中。 您可以指定收回原則，讓 Azure Cache for Redis 在空間處於進階階段時移除數據。
注意
當您使用 Azure Cache for Redis 時，您可以選取適當的定價層來指定快取的大小上限（從 250 MB 到 53 GB）。 不過，建立 Azure Cache for Redis 之後，您無法增加或減少其大小。
Redis 批次和交易無法跨越多個連線，因此所有受批次或交易影響的數據都應該保留在相同的資料庫中（分區）。
注意
Redis 交易中的作業序列不一定不可部分完成。 撰寫交易的命令會在執行之前經過驗證並排入佇列。 如果在這個階段期間發生錯誤，則會捨棄整個佇列。 不過，成功提交交易之後，佇列命令會依序執行。 如果有任何命令失敗，則只有該命令停止執行。 佇列中的所有先前和後續命令都會執行。 如需詳細資訊，請移至 Redis 網站上的 [交易 ] 頁面。
Redis 支援有限的不可部分完成作業。 支援多個索引鍵和值之此類型的唯一作業是 MGET 和 MSET 作業。 MGET 作業會傳回指定索引鍵清單的值集合，而 MSET 作業會儲存指定索引鍵清單的值集合。 如果您需要使用這些作業，MSET 和 MGET 命令所參考的索引鍵/值組必須儲存在相同的資料庫中。
分割 Azure Service Fabric
Azure Service Fabric 是微服務平臺，可為雲端中的分散式應用程式提供運行時間。 Service Fabric 支援 .NET 客體可執行檔、具狀態和無狀態服務，以及容器。 具狀態服務提供 可靠的集合 ，以持續將數據儲存在 Service Fabric 叢集內的索引鍵/值集合中。 如需在可靠集合中分割索引鍵策略的詳細資訊，請參閱 Azure Service Fabric 中可靠集合的指導方針和建議。
下一步
分割 Service Fabric 可靠服務 提供有關 Azure Service Fabric 中可靠服務的詳細資訊。
數據分割 Azure 事件中樞
Azure 事件中樞 專為大規模數據串流而設計，而數據分割則內建在服務中，以啟用水平調整。 每個取用者只會讀取訊息數據流的特定分割區。
事件發佈行者只會知道資料分割索引鍵，不會知道事件發佈的目的地資料分割。 索引鍵和資料分割脫鉤的這種機制，讓傳送者不需要知道太多有關下游處理的細節。 （也可能將事件直接傳送至指定的分割區，但通常不建議這麼做。
當您選取分割區計數時，請考慮長期調整。 建立事件中樞之後，您無法變更分割區數目。
下一步
如需在事件中樞中使用分割區的詳細資訊，請參閱 什麼是事件中樞？。
如需可用性與一致性之間的取捨考慮，請參閱 事件中樞的可用性和一致性。