DocumentDB Change Feed - 如何查看文档的所有更改

Question

DocumentDB提供的这个新的Change Feed功能非常酷.但是,文档说明:

对文档的每次更改仅在更改Feed中出现一次.更改日志中仅包含给定文档的最新更改.可能无法进行中间更改.

基本上,如果文档来自修订版A-> B-> C,当轮询更改订阅源时,我们只会获得"C". - 我有一种情况,我想看到"A"和"B".

我知道有一些现有模式可以解决这个问题,但我真的希望利用这个新的Change Feed功能.我希望它会返回A,B和C.

此功能的目的是让"工作人员"非常频繁地轮询服务吗？显然,工人投票越频繁,他们越不可能跳过对文档的修订.但是,我不希望因此对集合的性能产生负面影响.

Answer 1

DocumentDB团队成员在这里.我将开始说,请在此提出/投票支持所有版本/代的文档:http://feedback.azure.com/forums/263030-documentdb

Change Feed支持最新版本的目的有两个原因:

1. 数据同步和流处理等许多问题都依赖于最新版本,并且不需要中间版本
2. 这种方法的优点是不需要额外的存储来存储所有版本或具有更改馈送可用性的时间段.

你曾经提到你已经知道了解决方法,但我只是为了别人的利益而说明这个问题:这个问题可以通过反转存储在DocumentDB中的内容来解决.也就是说,您可以通过创建新文档将所有版本存储在DocumentDB中,然后通过更新最新版本通过更改源合并它们.

要回答评论中的问题,您必须绝对使用Change Feed而不是按时间戳查询,原因如下:

1. Change Feed效率更高.在分布式数据集中查询"按时间戳排序"执行全局排序,而更改源在部分时间内在分区时间戳中进行排序.此外,没有查询解析开销
2. 由于时钟偏差,时钟时间在分布式系统中意义不大,并且在一秒/毫秒内区分多个更新可能很重要.相反,您需要表示数据库中确切提交顺序的"逻辑时间".使用更改源,分区键中的更新按照提交的确切顺序排列,并且您可以在标记有相同逻辑时间戳的事务中更新所有文档.
3. 与查询不同,Change Feed可以跨多个工作人员以分布式方式使用.在使用Apache Storm或Azure Functions等下游可扩展计算框架时,这非常棒.