Change MongoDB Streams性能优化通常

简介：基于MongoDB的运行程序经过Change Streams性能可以繁难的成功对某个汇合，数据库或许整个集群的数据变卦的订阅，极大的繁难了运行对数据库变动的感知，然而Change Streams对局部数据的变动并没有提供对应的事情（创立索引，删除索引，shardCollection）等，本文引见一种新的事情订阅形式，来完善上述无余，并讨论经过并发预读的形式，来优化原生Change Streams的性能。

一、前言

MongoDB作为一款低劣的NOSQL数据库，允许海量存储，查问才干丰盛以及低劣的性能和牢靠性，大局部云厂商都提供了兼容MongoDB协定的服务，用户经常使用宽泛，深受国际外用户和企业的认可。

MongoDB从3.6版本开局提供了Change Stream个性，经过该个性，运行程序可以实时的订阅特定汇合、库、或整个集群的数据变卦事情，相比该个性推出之前经过监听oplog的变动来成功对数据变卦的感知，十分的易用，该个性同时允许正本集和集群场景。

Change Streams性能目前允许大局部数据操作的事情，然而关于与局部其余操作，如创立索引，删除索引，ColMod, shardCollection并不允许，而且目前Change Streams外部成功是经过Aggregate命令的形式成功的， 关于分片集群场景下， 在mongos节点是经过复线程会聚的形式成功从shard节点上oplog的拉取和处置，当实例写入压力很大的状况下，感知数据的实时变动会有提前，性能有待优化，关于ChangeStreams目前的性能疑问，官网也有过讨论。

本文经过深化剖析的Change Stream成功机制，联合客户实践经常使用场景，提出了一种新的多并发预读的事情监听形式，来处置上述疑问，并运行到客户实践迁徙和数据库容灾的场景中。

二、Change Steams 机制引见

Change Streams允许对单个汇合，DB，集群启动事情订阅，当业务程序经过watch的形式动员订阅后，面前出现了什么，让咱们一同来剖析一下。

Change Streams外部成功是经过Aggregate的形式成功的，所以watch面前，对应的是客户端向MongoDB Server动员了一个Aggregate命令，且对Aggregate的pipeline 参数中，减少了一个$changeStream的Stage, 联合客户端其余参数，一同发给MongoDB Server。

当Mongo Server收到Aggregate命令后，解析后，会依据详细的恳求，组合一个新的Aggregate命令，并把该命令发给对应的Shard节点，同时会在游标控制器（CursorManger）中注册一个新的游标（cursor），并把游标Id前往给客户端。

当Shard Server端收到Aggregate命令后，构建pipeline流水线，并依据pipeline参数中包含了Change Steams参数，确定原始扫描的汇合为oplog，并创立对该汇合上扫描数据的原始cursor, 和对应的查问方案口头器（PlanExecutor），构建PlanExecutor时刻，用了一个不凡的口头Stage, 即ProxyStage成功对整个Pipeline的封装，此外也会把对应的游标ID前往给Mongos节点。

客户端应用从Mongos节点拿到游标ID, 在该游标上始终的口头getMore恳求，服务端收到getMore恳求后，最后经过cursor的next调用，转发恳求到shard节点，拿到数据后，归并后前往可客户端，成功了整个Change Streams事情的订阅。

Shard上pipeline详细口头的细节不在本文重点引见范围，这些就不详细展开了。

原生Change Stream目前经常使用上有如下限度：

1. 允许DDL事情不完善

Change Stream目前允许的事情如下：

显然上述事情并没有齐全笼罩MongoDB外部所有的数据变卦的事情。

此外，关于在汇合上监听的Change Streams， 当出现汇合或许所属的DB被删除后，会触发一个invalidate Event， 该事情会把Change Streams的cursor封锁掉，造成Change Streams不可继续启动，关于经过Change Streams来成功容灾的场景，显然是不够友好的，须要从新建设新的Change Streams监听。

2. 事情拉取性能有待优化

如上述剖析，的Change Streams恳求发到Mongos节点后，经过复线程的形式向每个Shard节点发送异步恳求命令来成功数据的拉取，并做数据归并，假设将该形式交流为多线程并发拉取，关于分片表来说，性能会有优化。

三、 并行Change Streams架构和原理

3.1 并发Change Streams架构引见

针对上述的一些经常使用限度，咱们联合实践客户经常使用需求，提出一种新的并发Change Streams（Parallel Change Streams）的形式，来尝试处置上述疑问。

为了优化原生Change Streams的性能，咱们在Mongos 节点引入如下几个新的组件：

与Shard是一对一的相关。每个Change Streams Buffer 自动1GB，在Buffer满之前，该Buffer无条件的向对应的Shard(secondary节点)拉取Change Streams数据。

Merged Queue是一个内存队列，是Change Streams Buffer的消费者，是 Bucket的消费者。Merged Queue 归并一切Shard的Change Streams Buffer，并期待适宜的机遇依照规定放入对应Client的Bucket。

Bucket 是一个内存队列，是MergedQueue的消费者，是Client的消费者。每个Client对应一个Bucket。每个Bucket保养该Bucket内一切文档的的汇合。

Merged Queue不停的从头部拿出尽或许多的数据，并从前往后的依照hash(document.ns)%n的规定放入对应的Bucket, document.ns是指这个文档的NameSpace， 所以同一个汇合的数据必定在一个Bucket外面。

3.2 对DDL事情的增强

并发Change Stream除了允许原生的Change Stream外，还新增允许如下事情：

本文以ShardCollection为例来说明如何成功新增DDL事情的允许：

当口头ShardCollection命令的时刻，Config节点会向该汇合的主Shard发送一个shardsvrShardCollection命令，主Shard收到改恳求后，咱们在该命令的处置流程中记载了一个type为noop的oplog, 并把该命令的详细内容写入到oplog的o2字段外面，以此来成功shardcollecton事情的追踪。

之后在处置Change Streams流程的pipeline中，咱们对noop事情启动剖析，假设其中内容包含了shardCollection事情相关的标志，则提取该事情，并前往给下层。

3.3 如何经常使用

1 假构想创立并发change Stream，须要先经过如下命令创立bucket和cursor：

参数说明如下：

parallelChangeStream ：开启并行changeStream

nBuckets：要创立的bucket的数目

nsRegex：可选，定义要订阅的汇合，一个正则表白式。

startAtOperationTime：可选，示意订阅的事情从哪个时期点开局。

前往值：

Cursors ：前往的Mongos侧的Cursor ID。

当失掉到一切Cursor ID后，客户端就可以并发的(每个CursorId一个线程)经过getMore命令始终的从服务端拉取结果了。

断点续传

ParallelChangeStream的断点续传经过startAtOperationTime成功，因为每个cursor的消费进展不一样，复原的断点应该决定n个cursor的消费值的最小值。

四、性能对比

针对新的Parallel Change Stream和原生的Change Streams ，咱们做了较长时期的对比测试剖析，一切测试场景驳回的测试实例如下：

实例规格：4U16G， 2个Shard（正本集） ，2个Mongos，

磁盘容量：500G

测试数据模型：经过YCSB 预置数据，单条记载1K , 单个分片表1000w条记载。

上方分几个场景区分引见：

1. 集群形式1分片表场景测试

测试方法：

1） 创立一个Hash分片的汇合，预置16 Chunk

2） 启动YCSB , 对该汇合启动Load数据操作，Load数据量为1000w ，设置的Oplog足够大，保障这些操作还在Oplog中

3） 区分启动原生Change Streams 和 Parallel Change Streams，经过指定startAtOperationTime来观察订阅1000w条记载区分须要破费的时期。

4） 因为是单个表, nBuckets 为1

测试数据如下：

2. 集群模2分片表场景测试

测试方法：

1） 创立2个Hash分片的汇合，预置16 Chunk

2） 启动YCSB , 同时对这2个汇合启动Load数据操作，每个汇合Load数据量为1000w ，设置的Oplog足够大，保障这些操作还在Oplog中

3） 区分启动原生Change Streams和Parallel Change Streams，经过指定startAtOperationTime来观察订阅0w条记载区分须要破费的时期。

4） 因为是2个表, nBuckets 为2

测试数据如下：

3. 集群形式4分片表场景测试

测试方法：

1） 创立4个Hash分片的汇合，预置16 Chunk

2） 启动YCSB , 同时对这4个汇合启动Load数据操作，每个汇合Load数据量为1000w ，设置的Oplog足够大，保障这些操作还在Oplog中

3） 区分启动原生Change Streams和Parallel Change Streams，经过指定startAtOperationTime来观察订阅0w条记载区分须要破费的时期。

4） 因为是4个表, nBuckets 为4

测试数据如下：

总结：经过实践测试可以看进去， Parallel Change Streams这种形式性能有极大的优化，实践上咱们后续依据实例规格，经过调整外部Bucket和Buffer的缓存大小，性能还可以继续优化，同时随着分片表数据量和Shard节点数量的变多，和原生Change Streams 的性能长处会愈加显著。

五、并发Change Streams经常使用场景剖析

并发Change Streams十分适宜在MongoDB集群的容灾场景，运行可以有针对性的设置对特定的汇合或许DB启动监听，可以实时的感知到源端实例的数据变动，并极速的运行到目的端，全体成功较低RPO。

此外，并发Change Streams也可以运行到PITR场景中， 经过并发Change Streams良好的性能，实时成功灵活数据的跟踪并记载，使得PITR的可复原时期更短。

六、未来展望

的并行Change Streams的成功中，merge queue中的事情散发到bucket的事情中，咱们驳回的战略是基于事情的NameSpace的HASH值，传递给对应的bucket中，这种战略关于单汇合的场景，性能优化有限，后续咱们方案同时提供基于事情的ID内容的HASH值，把事情散发到不同的bucket中，这种形式能进一步的优化系统并发性能，带来更好的性能优化成果。

七、总结

经过引入一种新的并发Change Streams的形式，允许更多类别的MongoDB事情的订阅，同时在事情监听的性能方面相比原生有较大的提高，可以宽泛运行在数据库实例容灾， PITR，数据在线迁徙业务场景中，为客户带来更好的体验。