我正在尝试确定更改流之间的区别: 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
他们有不同的用例吗?什么时候使用一个而不是另一个?
答案 0 :(得分:5)
Change Streams(在MongoDB v3.6 +中提供)是一项功能,允许您访问实时数据更改,而不会产生拖尾oplog的复杂性和风险。更改流 over 尾随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。
什么时候使用一个而不是另一个?
如果您的MongoDB部署版本是3.6+,我建议使用MongoDB Change Streams而不是拖尾oplog。
您还可以找到Change Streams Production Recommendations有用的资源。
答案 1 :(得分:2)
使用tailable游标,您可以对所有集合进行所有更改。使用changeStream,您只能看到对所选集合的更改。更少的流量和更可靠。