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. 此方法的优点是不需要额外的存储来存储所有版本或具有更改Feed可用性的时间段。

您已经提到您已经了解了解决方法，但我只是为了其他人的利益而声明这一点：这个问题可以通过反转存储在DocumentDB中的内容来解决。也就是说，您可以通过创建新文档将所有版本存储在DocumentDB中，然后通过更新最新版本通过更改源合并它们。

要回答评论中的问题，必须绝对使用更改Feed而不是按时间戳查询，原因如下：

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