Change Streams Production Recommendations更改流生产建议
On this page本页内容
If you drop or rename a collection or database with change streams opened against it, the change stream cursors close when they advance to that point in the oplog. 如果删除或重命名已打开更改流的集合或数据库，则更改流游标在oplog中前进到该点时会关闭。Change stream cursors with the 使用fullDocument : updateLookup option may return null for the lookup document.fullDocument : updateLookup选项更改流游标可能会为查找文档返回null。
Attempting to resume a change stream against a dropped collection results in an error. 试图针对已删除的集合恢复更改流会导致错误。Any data changes that occurred on the collection between the last event the change stream captured and the collection drop event are lost.在捕获的更改流的最后一个事件和集合丢弃事件之间，在集合上发生的任何数据更改都将丢失。
Change stream response documents must adhere to the 16MB BSON document limit. 变更流响应文档必须遵守16MB BSON文档限制。Depending on the size of documents in the collection against which you open a change stream, notifications may fail if the resulting notification document exceeds the 16MB limit. 根据打开更改流的集合中文档的大小，如果生成的通知文档超过16MB的限制，则通知可能会失败。For example, update operations on change streams configured to return the full updated document, or insert/replace operations with a document that is at or just below the limit.例如，对配置为返回完整更新文档的更改流执行更新操作，或者使用达到或略低于限制的文档插入/替换操作。
Replica Sets复制集
For replica sets with arbiter members, change streams may remain idle if enough data-bearing members are unavailable such that operations cannot be majority committed.对于具有仲裁器成员的副本集，如果有足够多的数据承载成员不可用，则更改流可能会保持空闲，从而无法提交多数操作。
For example, consider a 3-member replica set with two data-bearing nodes and an arbiter. 例如，考虑一个具有两个数据承载节点和一个仲裁器的3成员副本集。If the secondary goes down, such as due to failure or an upgrade, writes cannot be majority committed. The change stream remains open, but does not send any notifications.如果辅助系统出现故障（例如由于故障或升级），则无法提交大部分写入。更改流保持打开状态，但不发送任何通知。
In this scenario, the application can catch up to all operations that occurred during the downtime so long as the last operation the application received is still in the oplog of the replica set.在这种情况下，只要应用程序接收到的最后一个操作仍在副本集的操作日志中，应用程序就可以赶上停机期间发生的所有操作。
If significant downtime is estimated, such as for an upgrade or a significant disaster, consider increasing the size of the oplog such that operations are retained for a duration of time greater than the estimated downtime. 如果估计有重大停机时间，例如升级或重大灾难，请考虑增加操作日志的大小，以便在比估计停机时间更长的时间内保留操作。Use 使用rs.printReplicationInfo() to retrieve information on the oplog status, including the size of the oplog and the time range of operations.rs.printReplicationInfo()检索有关操作日志状态的信息，包括操作日志的大小和操作的时间范围。
Sharded Clusters分片集群
Change streams provide a total ordering of changes across shards by utilizing a global logical clock. 变更流通过利用全局逻辑时钟提供跨分片的变更的总顺序。MongoDB guarantees the order of changes are preserved and change stream notifications can be safely interpreted in the order received. MongoDB保证保留更改的顺序，并且可以按照接收的顺序安全地解释更改流通知。For example, a change stream cursor opened against a 3-shard sharded cluster returns change notifications respecting the total order of those changes across all three shards.例如，针对一个三硬盘分片集群打开的变更流游标会返回关于所有三个分片中这些变更的总顺序的变更通知。
To guarantee total ordering of changes, for each change notification the 为了保证更改的总顺序，对于每个更改通知，mongos checks with each shard to see if the shard has seen more recent changes. mongos都会检查每个分片，看看该分片是否看到了最近的更改。Sharded clusters with one or more shards that have little or no activity for the collection, or are "cold", can negatively affect the response time of the change stream as the 具有一个或多个对集合几乎没有活动或“冷”的分片的分片集群可能会对更改流的响应时间产生负面影响，因为mongos must still check with those cold shards to guarantee total ordering of changes. mongos仍然必须与这些冷分片进行检查，以确保更改的总体顺序。This effect may be more apparent with geographically distributed shards, or workloads where the majority of operations occur on a subset of shards in the cluster.这种影响在地理分布的分片中可能更为明显，或者在大多数操作发生在集群中分片子集上的工作负载中。
If a sharded collection has high levels of activity, the 如果一个分片集合的活动水平很高，mongos may not be able to keep up with the changes across all of the shards. mongos可能无法跟上所有分片的变化。Consider utilizing notification filters for these types of collections. 考虑对这些类型的集合使用通知筛选器。For example, passing a 例如，传递一个$match pipeline configured to filter only insert operations.$match管道，该管道被配置为只筛选insert操作。
For sharded collections, update operations with multi : true may cause any change streams opened against that collection to send notifications for orphaned documents.对于分片集合，使用multi:true的更新操作可能会导致针对该集合打开的任何更改流发送孤立文档的通知。
From the moment an unsharded collection is sharded until the time the change stream catches up to the first chunk migration, the 从对未排序集合进行分片的那一刻起，直到更改流赶上第一次块迁移，更改流通知文档中的documentKey in the change stream notification document only includes the _id of the document, not the full shard key.documentKey只包括文档的_id，而不包括完整的分片键。
Indexes and Performance指标和性能
Change streams cannot use indexes. MongoDB does not support creating indexes on the oplog collection. 更改流不能使用索引。MongoDB不支持在oplog集合上创建索引。Therefore, avoid opening a high number of specifically-targeted change streams as these can impact server performance.因此，请避免打开大量专门针对性的更改流，因为这些更改流可能会影响服务器性能。
Change Stream Optimization变更流优化
Starting in MongoDB 5.1, change streams are optimized, providing more efficient resource utilization and faster execution of some aggregation pipeline stages.从MongoDB 5.1开始，更改流得到了优化，提供了更高效的资源利用率和更快的一些聚合管道阶段的执行。
Change Streams and Orphan Documents更改流和孤立文档
Starting in MongoDB 5.3, during range migration, change stream events are not generated for updates to orphaned documents.从MongoDB 5.3开始，在范围迁移过程中，不会为孤立文档的更新生成更改流事件。