變更 Azure Cosmos DB 中的摘要設計模式
適用於：
NoSQL
Azure Cosmos DB 變更摘要可有效地處理具有大量寫入的大型資料集。 變更摘要也提供了替代方式，以查詢整個資料集來識別已變更的項目。 本文著重於常見變更摘要設計模式、設計取捨和變更摘要限制。
Azure Cosmos DB 非常適合用於 IoT、遊戲、零售，以及操作記錄應用程式。 這類應用程式中的常見設計模式是使用資料的變更來觸發其他動作。 這些動作的範例包括：
- 在插入、更新或刪除項目時觸發通知或呼叫 API。
- IoT 的即時串流處理或在操作資料上的即時分析處理。
- 資料移動，例如與快取、搜尋引擎、資料倉儲或冷儲存體進行同步處理。
Azure Cosmos DB 中的變更摘要可讓您針對每一個模式建置有效率且可調整的解決方案，如下圖所示：
事件計算和通知
Azure Cosmos DB 變更摘要可以簡化需要觸發通知的案例，或根據特定事件傳送對 API 的呼叫。 您可以使用變更摘要處理器來自動輪詢容器的變更，然後在每次進行寫入、更新或刪除時呼叫外部 API。
您也可以根據特定準則，選擇性地觸發通知或傳送對 API 的呼叫。 例如，如果您要使用 Azure Functions 以從變更摘要中進行讀取，則可以將邏輯放入函數，只在符合條件時才傳送通知。 雖然會針對每個變更執行 Azure Function 程式碼，但只有在符合條件時才會傳送通知。
即時串流處理
Azure Cosmos DB 變更摘要可用於 IoT 的即時串流處理，或在操作資料上的即時分析處理。 例如，您可能會接收和儲存來自裝置、感應器、基礎結構和應用程式的事件資料，然後使用 Spark來即時處理這些事件。 下圖顯示如何使用 Azure Cosmos DB 變更摘要來實作 lambda 結構：
在許多情況下，串流處理實作會先將大量的傳入資料接收到臨時訊息佇列，例如 Azure 事件中樞或 Apache Kafka。 變更摘要是絕佳的替代方案，因為 Azure Cosmos DB 能夠以保證的低讀取和寫入延遲來支援持續性的高速資料擷取。 透過訊息佇列的 Azure Cosmos DB 變更摘要優點包括：
資料持續性
寫入 Azure Cosmos DB 的資料會顯示在變更摘要中。 如果您使用最新版本模式來讀取資料，則除非刪除資料，否則資料會保留在變更摘要中。 訊息佇列通常具有最大保留期間。 例如，Azure 事件中樞提供 90 天的最大資料保留期。
查詢能力
除了從 Azure Cosmos DB 容器的變更摘要進行讀取之外，您還可以對 Azure Cosmos DB 中所儲存的資料執行 SQL 查詢。 變更摘要不是容器中已有的資料重複，而只是不同的資料讀取機制。 因此，如果您從變更摘要讀取資料，則資料一律會與相同 Azure Cosmos DB 容器的查詢一致。
高可用性
Azure Cosmos DB 最多可提供 99.999% 的讀取和寫入可用性。 與許多訊息佇列不同，Azure Cosmos DB 資料可以使用零復原時間目標 (RTO) 來輕鬆地進行全域散發和設定。
在您處理變更摘要中的項目之後，可以建置具體化檢視，並在 Azure Cosmos DB 中持續保存彙總的值。 例如，如果您要使用 Azure Cosmos DB 來建置遊戲，則可以使用變更摘要，以根據已完成遊戲的分數來實作即時排行榜。
資料移動
您也可以從變更摘要讀取以進行即時資料移動。
例如，變更摘要可協助您有效率地執行下列工作︰
使用 Azure Cosmos DB 中所儲存的資料來更新快取、搜尋索引或資料倉儲。
執行零停機時間移轉至另一個 Azure Cosmos DB 帳戶或具有不同邏輯分割區索引鍵的另一個 Azure Cosmos DB 容器。
實作應用程式層級的資料層和封存。 例如，您可以在 Azure Cosmos DB 中儲存「經常性存取資料」，並將「非經常性存取資料」存留到其他儲存體系統，例如 Azure Blob 儲存體。
當您必須跨分割區和容器反正規化資料時，您可以從容器的變更摘要讀取，做為此資料複寫的來源。 具有變更摘要的即時資料複寫只能保證最終一致性。 您可以監視變更摘要處理器在處理 Azure Cosmos DB 容器中的變更時落後的程度。
事件來源
事件來源模式牽涉到使用附加專用存放區來記錄該資料的完整系列動作。 Azure Cosmos DB 變更摘要是一個作為事件來源架構內中央資料存放區的絕佳選擇，其中所有的資料擷取都會模型化為寫入 (無更新或刪除)。 在此情況下，每次寫入至 Azure Cosmos DB 都是「事件」，因此變更摘要中會有過去事件的完整記錄。 中央事件存放區所發佈事件的一般用法，是用來維護具體化檢視或與外部系統整合。 因為變更摘要最新版本模式沒有保留時間限制，所以您可以從 Azure Cosmos DB 容器的變更摘要開頭進行讀取，以重新執行所有過去的事件。 您甚至可以讓多個變更摘要取用者訂閱相同容器的變更摘要。
Azure Cosmos DB 是事件來源模式中的絕佳中央附加專用持續性資料存放區，因為其優勢在於水平擴縮性和高可用性。 此外，變更摘要處理器會提供「至少一次」保證，以確保您不會錯過處理任何事件。
目前的限制
變更摘要具有多種模式，而且每種模式都有您應該瞭解的重要限制。 當您以最新版本模式或所有版本和刪除模式設計使用變更摘要的應用程式時，需要考慮幾個領域。
中繼更新
在最新版本模式中，變更摘要中只會包括特定項目的最新變更。 處理變更時，您會讀取到最新可用項目版本。 如果相同的項目在短時間內有多個更新，則可能會遺漏處理中繼更新。 如果您想要重新執行項目的過去個別更新，則可以改為將這些更新模型化為一系列的寫入，或使用所有版本和刪除模式。
Deletes
變更摘要最新版本模式不會擷取刪除。 如果您從容器中刪除項目，則也會將其從變更摘要中移除。 最常見的處理刪除方法是在要刪除的項目上新增軟標記。 您可以新增稱為 deleted 的屬性，並在刪除時將其設定為 true。 此文件更新會顯示在變更摘要中。 您可以在此項目上設定存留時間 (TTL)，以在稍後自動刪除。
保留期
最新版本模式中的變更摘要具有無限制的保留期。 只要您的容器中有項目，變更摘要中就會提供該項目。
保證順序
分割區索引鍵值內的所有變更摘要模式都會有保證的順序，但跨分割區索引鍵值則沒有。 您應該選取分割區索引鍵，以提供有意義的順序保證。
例如，請考慮可使用事件來源設計模式的零售應用程式。 在此應用程式中，不同的使用者動作是模型化為 Azure Cosmos DB 寫入的「事件」。 假設有一些範例事件依照下列順序發生：
- 客戶將項目 A 新增至其購物車。
- 客戶將項目 B 新增至其購物車。
- 客戶從其購物車移除項目 A。
- 客戶簽出，而且購物車內容已出貨。
針對每個客戶維護目前購物車內容的具體化檢視。 此應用程式必須確保這些事件會依照其發生的順序進行處理。 例如，如果要在項目 A 移除之前處理購物車結帳，則可能已將項目 A 出貨給客戶，而不是客戶想要的項目 B。為了保證這四個事件會依照發生順序進行處理，其應該落在相同的分割區索引鍵值內。 如果您選取 username (每個客戶都有唯一的使用者名稱) 作為分割區索引鍵，則可以保證這些事件在變更摘要中會依照其寫入至 Azure Cosmos DB 的相同順序來顯示。
範例
以下是最新版本模式的一些真實世界的變更摘要程式碼範例，其延伸超出所提供範例的範圍：