node.js – MongoDB中的changeStream和tailable游标之间有什么区别

我试图确定变更流之间的区别：
https://docs.mongodb.com/manual/changeStreams
https://docs.mongodb.com/manual/reference/method/db.collection.watch/

看起来像这样：

const changeStream = collection.watch();
changeStream.next(function(err, next) {
  expect(err).to.equal(null);
  client.close();
  done();
});

和一个tailable游标：
https://docs.mongodb.com/manual/core/tailable-cursors/

看起来像这样：

const cursor = coll.find(self.query || query)
  .addCursorFlag('tailable', true)
  .addCursorFlag('awaitData', true)  // true or false?
  .addCursorFlag('noCursorTimeout', true)
  .addCursorFlag('oplogReplay', true)
  .setCursorOption('numberOfRetries', Number.MAX_VALUE)
  .setCursorOption('tailableRetryInterval', 200);


 const strm = cursor.stream();   // Node.js transform stream

他们有不同的用例吗？何时使用一个而不是另一个？

Change Streams(MongoDB v3.6中提供)是一项功能,允许您访问实时数据更改,而不会产生拖尾 oplog的复杂性和风险.更改流的主要好处是拖尾oplog：

>利用内置的MongoDB Role-Based Access Control.应用程序只能针对他们具有读取权限的集合打开更改流.精致和特定的授权.
>提供可靠的定义良好的API.更改流返回的change events输出已有详细记录.此外,在实现更改流接口时,所有official MongoDB drivers都遵循相同的specifications.
>作为更改流的一部分返回的更改事件至少会提交到大多数副本集.这意味着发送到客户端的更改事件是持久的.在发生故障转移时,应用程序不需要处理数据回滚.
>通过利用全局逻辑时钟提供跨分片的更改的总排序. MongoDB保证保留更改顺序,并且可以按接收顺序安全地解释更改事件.例如,针对3分片分片群集打开的更改流游标返回更改事件,这些事件遵循所有三个分片中这些更改的总顺序.
>由于订购特性,更改流本身也可以恢复. change event output的_id是恢复令牌. MongoDB官方驱动程序自动缓存此恢复令牌,并且在网络瞬态错误的情况下,驱动程序将重试一次.此外,应用程序也可以通过使用参数resume_after手动恢复.另见Resume a Change Stream.
>使用MongoDB aggregation pipeline.应用程序可以修改更改事件输出.目前有五个管道阶段可用于修改事件输出.例如,在使用$match stage发送之前,可以过滤掉(事件服务器端)更改事件输出.有关详细信息,请参阅Modify Change Stream Output.

when would it be good to use one over the other?

如果您的MongoDB部署版本是3.6,我建议使用MongoDB Change Streams而不是拖尾oplog.

您还可以找到Change Streams Production Recommendations一个有用的资源.