英文:
Azure Cosmos DB Change Feed with MongoDB API (Not change stream!)
问题
以下是翻译好的部分：
"我一直在努力理解Azure Cosmos DB官方文档。
这个链接显示变更源可以与“MongoDB”一起使用：Azure Cosmos DB中的变更源。
但以下段落让我感到困惑：
所以我的问题是Azure Cosmos DB的变更源是否可以与MongoDB API一起使用（不使用变更流）？
关于这个问题，网络上的文档很少，我找不到有用的信息。
对我来说，变更源应该得到支持，因为Mongo API只是Cosmos DB上的一层，但任何事情都有可能。
如果支持变更流而不支持变更源，是否可以定义操作日志（oplog）的保留时间或大小？如果不行，那么默认值是什么？（同样几乎无法在互联网上找到这方面的信息）"
英文:
I've been struggling to understand the Azure Cosmos DB official docs.
This link shows that change feed can work with the "MongoDB" : Change feed in Azure Cosmos DB
But the following paragraph is what is confusing me:
So my question is following can Azure Cosmos DB Change Feed work with MongoDB API (Not using change stream!)?
The documentation on this on the web is scarce and I can't find useful information on this subject.
To me it would make sense that change feed is supported since the Mongo API is just a layer over Cosmos DB but nothing would surprise me.
In case change stream is supported but not change feed, is it possible to define the oplog retention time or size, if not what are the defaults? (Again almost impossible information to find on the internet).
答案1
得分: 1
Azure Cosmos DB 的更改Feed可以与MongoDB API一起工作（不使用更改流！）
基本上不行。
过去，至少可以通过连接到SQL API端点来实现，但是新创建的Mongo帐户上现在已经阻止或不可用。
通过该路线使用更改feed时，呈现的文档是BSON文档的SQL API表示，但我认为从未有任何关于如何反序列化它的文档或支持。
然而，遗憾的是，这条路线已被关闭，因为没有提供用于将CosmosDB的“ChangeStreams”用作Azure函数触发源并在物理分区之间进行并行处理的替代功能（尽管在调用“GetChangeStreamTokens”之后，技术上可以以非常类似的方式实现）。
我的理解是，更改流只是Mongo API界面，用于公开更改feed，因此它基本上以完全相同的方式实现，具有相同的限制。即它没有单独的oplog，因为它没有更改历史记录的记录。它只是按LSN顺序遍历分区中的文档。
而且，由于更改feed目前不公开删除操作，也不保证所有文档版本（在文档多次写入的情况下），更改流也不能保证（因此需要指定[“$in”：[“insert”，“update”，“replace”]]）。
英文:
> can Azure Cosmos DB Change Feed work with MongoDB API (Not using
> change stream!)
Basically no.
It used to be at least unofficially possible by connecting to the SQL API endpoint but this is now blocked or unavailable on newly created Mongo accounts.
The documents surfaced when using the change feed via that route were the SQL API representations of BSON documents though and I don't think deserializing that was ever at all documented or supported.
It is unfortunate that this route has been closed off however because there is no replacement functionality provided out the box for using the CosmosDB "ChangeStreams" as a trigger source for an Azure function and parallelising across physical partitions (even though technically it could be implemented very similarly after calling "GetChangeStreamTokens").
My understanding is that change streams is just the Mongo API interface for exposing change feed though so it is basically implemented exactly the same way and has the same limitations. i.e. it has no separate oplog as it has no record of change history. It is just traversing the documents within a partition in order of LSN.
And because change feed does not currently expose deletes or guarantee all document versions (in the case that a document is written multiple times) neither can change streams - which is why it is required to specify $in: ["insert", "update", "replace"]).
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论