产品中心
删除大量数据，无论是在哪种数据库中，都是一个普遍性的需求。除了正常的业务需求，我们需要通过这种方式来为数据库“瘦身”。
1、表的数据量到达一定量级后，数据量越大，表的查询性能会越差。
毕竟数据量越大，B+树的层级会越高，需要的IO也会越多。
2、表的数据有冷热之分，将很多无用或很少用到的数据存储在数据库中会消耗数据库的资源。
譬如会占用缓存；会增加备份集的大小，进而影响备份的恢复时间等。
所以，对于那些无用的数据，我们会定期删除。
对于那些很少用到的数据，则会定期归档。归档，一般是将数据写入到归档实例或抽取到大数据组件中。归档完毕后，会将对应的数据从原实例中删除。
一般来说，这种删除操作涉及的数据量都比较大。
对于这类删除操作，很多开发童鞋的实现就是一个简单的DELETE操作。看上去，简单明了，干净利落。
但是，这种方式，危害性却极大。
以 MySQL 为例：
即使是分布式数据库，如TiDB，如果一次删除了大量数据，这批数据在进行Compaction时有可能会触发流控。
所以，对于线上的大规模删除操作，建议分而治之。具体来说，就是批量删除，每次只删除一部分数据，分多次执行。
就如何删除大量数据，接下来我们看看MongoDB中的落地方案。
本文主要包括以下四部分内容。
在MongoDB中删除数据，可通过以下三种方式：
db.collection.remove()
删除单个文档或满足条件的所有文档。
db.collection.deleteMany()
删除满足条件的所有文档。
db.collection.bulkWrite()
批量操作接口，可执行批量插入、更新、删除操作。
接下来，对比下这三种方式的执行效率。
环境：MongoDB 3.4.4，副本集。
测试思路：分别使用 remove、deleteMany、bulkWrite 删除 10w 条记录（每批删除 5000 条），交叉执行 5 次。
图中是一个一主两从的副本集，设置了w: “majority”，代表一个写操作，需要等待副本集中绝大多数节点（本例中是两个）应用完，才能给客户端反馈。
在前面的代码中，无论是remove，deleteMany还是bulkWrite方法，都设置了w: “majority”。
之所以这样设置，一方面是为了保证数据的安全性，毕竟删除操作能在多个节点落盘，另一方面，还能有效降低批量操作可能导致的主从延迟风险。
Write Concern的完整语法如下，
https://docs.mongodb.com/manual/tutorial/configure-replica-set-tag-sets/。j：是否需要等待对应操作的日志持久化到磁盘中。
在MongoDB中，一个写操作会涉及到三个动作：更新数据，更新索引，写入oplog，这三个动作要么全部成功，要么全部失败，这也是MongoDB单行事务的由来。
对于每个写操作，WiredTiger都会记录一条日志到 journal 中。
日志在写入journal之前，会首先写入到 journal buffer（最大128KB）中。
Journal buffer会在以下场景持久化到 journal 文件中：
这类操作包括：针对oplog最新位置点的扫描查询；Causally consistent session中的读操作；对于Secondary节点，每次批量应用oplog后。
由 storage.journal.commitIntervalMs 参数指定。
当 journal 文件的大小达到100MB时会自动创建一个新的journal 文件。
wtimeout：超时时长，单位ms。
不设置或设置为0，命令在执行的过程中，如果遇到了锁等待或节点数不满足要求，会一直阻塞。
如果设置了时间，命令在这个时间内没有执行成功，则会超时报错，具体报错信息如下：
Journaling[2] Write Concern
