更改 Azure Cosmos DB 的 API 對 Z206E3708AF0917CCA1ZE7 的 stream 支持有多可靠？

Question

描述

I am working on an ASP.NET Core 3.1 web application which needs to track/respond on changes made to the MongoDB database hosted by Azure Cosmos DB (version 3.6). 為此，我使用了Change feed support 。

更改非常頻繁：集合中的單個條目每秒更新約 10 次。

為了追蹤對集合所做的更改，我使用以下代碼將受影響的條目轉儲到文件中（這僅用於測試目的）。

private async Task HandleChangeStreamAsync<T>(IMongoCollection<T> coll, StreamWriter file, CancellationToken cancellationToken = default)
{
    var pipeline = new EmptyPipelineDefinition<ChangeStreamDocument<T>>()
            .Match(change => change.OperationType == ChangeStreamOperationType.Insert || 
                             change.OperationType == ChangeStreamOperationType.Update || 
                             change.OperationType == ChangeStreamOperationType.Replace)
            .AppendStage<ChangeStreamDocument<T>, ChangeStreamDocument<T>, ChangeStreamOutputWrapper<T>>(
                  "{ $project: { '_id': 1, 'fullDocument': 1, 'ns': 1, 'documentKey': 1 }}");

    var options = new ChangeStreamOptions
    {
        FullDocument = ChangeStreamFullDocumentOption.UpdateLookup
    };

    using (var cursor = await coll.WatchAsync(pipeline, options, cancellationToken))
    {
        await cursor.ForEachAsync(async change =>
        {
            var json = change.fullDocument.ToJson(new JsonWriterSettings { Indent = true });
            await file.WriteLineAsync(json);
        }, cancellationToken);
    }
}

問題

在觀察 output 時，我注意到對集合進行的每次更新都不會觸發更改提要。 我可以通過將生成的 output 與 MongoDB 雲托管的數據庫進行比較來確認這一點。

問題

1. 更改 Azure Cosmos DB 的 API 對 Z206E3708AF0917CCA1ZE7 的 stream 支持有多可靠？

2. API 能否保證最新的更新始終可用？

3. 我無法自己處理“本地”數據庫的“oplog.rs”集合，API 是否以任何方式支持這個？ 這甚至受到鼓勵嗎？

4. 收集吞吐量 (RU/s) 是否以某種方式與更改事件頻率相關？

最后的想法

我的理解是頻繁的更新會限制系統，並且更改源根本無法處理日志中的所有事件（而是定期掃描它）。 但是，我想知道依靠這種機制有多安全，並確保不會錯過對數據庫進行的任何關鍵更新。

---

如果更改提要支持無法對事件處理頻率做出任何保證並且無法處理“oplog.rs”，則唯一的選擇似乎是定期輪詢數據庫。

如果我錯了，請糾正我，但切換到輪詢會極大地影響性能，並會導致解決方案不可擴展。

Answer 1

我懷疑 MongoDB 更改 stream 是基於 Cosmos DB Change Feed 構建的。 我的經驗完全來自 Cosmos DB 更改提要； 我根本沒有使用過 MongoDB API。 所以這個答案都是假設 MongoDB 更改 stream 在內部使用 Cosmos DB Change Feed，這是有道理的，但我可能是錯的。

更改 Azure Cosmos DB 的 API 對 Z206E3708AF0917CCA1ZE7 的 stream 支持有多可靠？

它是完全可靠的，但有一些限制。

更改提要的限制之一是它可以“批量”更新。 在內部，更改提要處理器輪詢更改提要，它將獲取所有已更改的項目。 但是，如果一個項目在輪詢之間多次更改，它只會在更改提要中顯示一次。 This is the behavior of the Cosmos DB SQL API Change Feed, and I expect the same limitation applies to the MongoDB change stream, though I don't see it actually documented anywhere in the MongoDB docs.

另一個限制是沒有觀察到刪除。

由於這些限制，更改饋送/更改 stream不是事件溯源解決方案。 如果您想要事件源，那么您需要自己將數據作為事件 model； 沒有任何內置功能可以為您做到這一點。

也就是說，在這些限制范圍內，它是完全可靠的，因為您的代碼將接收更改提要中的每個更改文檔。 這些限制只是意味着多個更新可能會作為一個更改的文檔出現，而刪除的文檔根本不會出現。

API 能否保證最新的更新始終可用？

在您的代碼從更改提要中檢索文檔后，文檔總是有可能發生更改，在這種情況下，更新后的文檔將重新發布到更改提要，您的代碼稍后會再次看到它。 （當然）不能保證您的代碼剛剛從更改提要中獲得的文檔與數據庫中的文檔相同，但最終會保持一致。

我無法自己處理“本地”數據庫的“oplog.rs”集合，API 是否以任何方式支持這個？ 這甚至受到鼓勵嗎？

¯\ (ツ) /¯

收集吞吐量 (RU/s) 是否以某種方式與更改事件頻率相關？

是的。 更改提要本身內置於 Cosmos DB，但更改提要處理具有 RU 成本。 變更提要處理器使用 RU 來輪詢變更提要，從變更提要中讀取文檔，並更新其“書簽”以跟蹤它在變更提要中的位置。

我的理解是頻繁的更新會限制系統，並且更改源根本無法處理日志中的所有事件（而是定期掃描它）。

那是對的。

但是，我想知道依靠這種機制有多安全，並確保不會錯過對數據庫進行的任何關鍵更新。

代碼將始終（最終）接收更新的文檔。 但是，如果您需要單獨查看每個更改，那么您將需要使用事件溯源之類的東西來構建數據。 如果您的應用只關心文檔的最終 state，那么更改提要就可以了。 但是，例如，如果您需要知道someCriticalProperty是否設置為true然后又設置為false ，那么您將需要事件溯源。

切換到輪詢會極大地影響性能，並導致解決方案不可擴展。

投票不一定是壞事。 如上所述，更改饋送處理器使用輪詢。 它還有一個允許橫向擴展的簡潔機制，其中不同的處理器觀察同一個集合可以拆分它們之間的文檔（通過分區鍵）； I'm not sure if/how this would translate to the MongoDB world, but it's a pretty elegant solution for scaling SQL API change feed processors and works quite nicely with Azure Functions (unfortunately, there's no MongoDB change stream trigger for Azure Functions).