MongoDB 中的 changeStream 和 tailable 游标有什么区别 [英] What is the difference between a changeStream and tailable cursor in MongoDB

问题描述

我正在尝试确定变更流之间的区别:https://docs.mongodb.com/manual/changeStreamshttps://docs.mongodb.com/manual/reference/method/db.collection.watch/

看起来像这样:

const changeStream = collection.watch();changeStream.next(function(err, next) {期望(错误).to.equal(空)；客户端关闭()；完毕();});

和可尾光标:https://docs.mongodb.com/manual/core/tailable-cursors/

看起来像这样:

 const cursor = coll.find(self.query || query).addCursorFlag('tailable', true).addCursorFlag('awaitData', true)//真还是假?.addCursorFlag('noCursorTimeout', true).addCursorFlag('oplogReplay', true).setCursorOption('numberOfRetries', Number.MAX_VALUE).setCursorOption('tailableRetryInterval', 200);const strm = cursor.stream();//Node.js 转换流

他们有不同的用例吗?什么时候用一个比另一个好?

解决方案

更改流(可用在 MongoDB v3.6+ 中)是一项功能，允许您访问实时数据更改，而无需拖尾 oplog.变更流超过拖尾 oplog 的主要好处是:

1. 利用内置的MongoDB 基于角色的访问控制.应用程序只能针对它们具有读取访问权限的集合打开更改流.细化和特定的授权.

2. 提供定义明确且可靠的 API.更改流返回的 change events 输出有详细记录.此外，所有官方 MongoDB 驱动程序都遵循相同的规范 实现变更流接口时.

3. 作为变更流的一部分返回的变更事件至少提交给大部分副本集.这意味着发送到客户端的更改事件是持久的.应用程序不需要在发生故障转移时处理数据回滚.

4. 利用全局逻辑时钟提供跨分片更改的总排序.MongoDB 保证保留更改的顺序，并且可以按照收到的顺序安全地解释更改事件.例如，针对 3 个分片的集群打开的更改流游标返回更改事件，这些更改事件涉及所有三个分片中这些更改的总顺序.

5. 由于排序特性，变更流本质上也是可恢复的.更改事件输出<的_id/a> 是恢复令牌.MongoDB官方驱动会自动缓存这个resume token，在网络暂时性错误的情况下，驱动会重试一次.此外，应用程序还可以通过使用参数 resume_after 手动恢复.另请参阅恢复更改流.

6. 利用 MongoDB 聚合管道.应用程序可以修改更改事件输出.目前有五个流水线阶段可用于修改事件输出.例如，可以在使用 $match 阶段.有关详细信息，请参阅修改更改流输出.

<块引用>

什么时候用一个比另一个好?

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

您还可以找到更改流生产建议有用的资源.

I am trying to determine what the difference is between a changestream: https://docs.mongodb.com/manual/changeStreams https://docs.mongodb.com/manual/reference/method/db.collection.watch/

which looks like so:

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

and a tailable cursor: https://docs.mongodb.com/manual/core/tailable-cursors/

which looks like so:

 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

do they have a different use case? when would it be good to use one over the other?

解决方案

Change Streams (available in MongoDB v3.6+) is a feature that allows you to access real-time data changes without the complexity and risk of tailing the oplog. Key benefits of change streams over tailing the oplog are:

1. Utilise the built-in MongoDB Role-Based Access Control. Applications can only open change streams against collections they have read access to. Refined and specific authorisation.

2. Provide a well defined API that are reliable. The change events output that are returned by change streams are well documented. Also, all of the official MongoDB drivers follow the same specifications when implementing change streams interface.

3. Change events that are returned as part of change streams are at least committed to the majority of the replica set. This means the change events that are sent to the client are durable. Applications don't need to handle data rollback in the event of failover.

4. Provide a total ordering of changes across shards by utilising a global logical clock. MongoDB guarantees the order of changes are preserved and change events can be safely interpreted in the order received. For example, a change stream cursor opened against a 3-shard sharded cluster returns change events respecting the total order of those changes across all three shards.

5. Due to the ordering characteristic, change streams are also inherently resumable. The _id of change event output is a resume token. MongoDB official drivers automatically cache this resume token, and in the case of network transient error the driver will retry once. Additionally, applications can also resume manually by utilising parameter resume_after. See also Resume a Change Stream.

6. Utilise MongoDB aggregation pipeline. Applications can modify the change events output. Currently there are five pipeline stages available to modify the event output. For example, change event outputs can be filtered out (server side) before being sent out using $match stage. See Modify Change Stream Output for more information.

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

If your MongoDB deployment is version 3.6+, I would recommend to utilise MongoDB Change Streams over tailing the oplog.

You may also find Change Streams Production Recommendations a useful resource.

这篇关于MongoDB 中的 changeStream 和 tailable 游标有什么区别的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！