DocumentDB提供的这个新的Change Feed功能非常酷 . 但是，文档说明：
对文档的每次更改仅在更改源中显示一次 . 更改日志中仅包含给定文档的最新更改 . 可能无法进行中间更改 .
基本上，如果文档来自修订版A-> B-> C，当轮询更改订阅源时，我们只会获得“C” . - 我有一种情况，我想看到“A”和“B” .
我知道一些现有的模式可以解决这个问题，但我真的希望利用这个新的Change Feed功能 . 我希望它会返回A，B和C.
此功能的目的是让“工作人员”非常频繁地轮询服务吗？显然， Worker 投票的频率越高，他们跳过文档修订的可能性就越小 . 但是，我不希望因此对集合的性能产生负面影响 .
1 回答
DocumentDB团队成员在这里 . 我将开始说，请在此提出/投票支持该文档的所有版本/代：http://feedback.azure.com/forums/263030-documentdb
Change Feed支持最新版本的目的有两个原因：
数据同步和流处理等许多问题都依赖于最新版本，并且不需要中间版本
此方法的优点是不需要额外的存储来存储所有版本或具有更改Feed可用性的时间段 .
你曾经提到你已经知道了解决方法，但我只是为了别人的利益而说明这个问题：这个问题可以通过反转存储在DocumentDB中的内容来解决 . 也就是说，您可以通过创建新文档将所有版本存储在DocumentDB中，然后通过更新源来合并它们，方法是插入最新版本 .
要回答评论中的问题，您需要 must absolutely use Change Feed over querying by timestamp ，原因如下：
更改Feed更有效率 . 跨分布式数据集查询"order by timestamp"执行全局排序，而更改源在分区时间戳内部分排序 . 此外，没有查询解析开销
由于时钟偏差，分布式系统中的时钟时间不太有意义，并且在一秒/毫秒内区分多个更新可能很重要 . 相反，您需要"logical time"表示数据库中的确切提交顺序 . 使用更改源，分区键中的更新将按照提交的确切顺序进行，并且您将在使用相同逻辑时间戳记的事务中更新所有文档 .
与查询不同，可以跨多个工作人员以分布式方式使用更改源 . 在使用Apache Storm或Azure Functions等下游可扩展计算框架时，这非常棒 .