网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
- 锁定的记录多
相对而言，更容易导致锁等待。
即使是分布式数据库，如TiDB，如果一次删除了大量数据，这批数据在进行Compaction时有可能会触发流控。
所以，对于线上的大规模删除操作，建议分而治之。具体来说，就是批量删除，每次只删除一部分数据，分多次执行。
就如何删除大量数据，接下来我们看看MongoDB中的落地方案。
本文主要包括以下四部分内容。
-
MongoDB中删除数据的三种方式。
-
三种方式的执行效率对比。
-
通过Write Concern规避主从延迟。
-
删除过程中碰到的Bug。
MongoDB中删除数据的三种方式
=================
在MongoDB中删除数据，可通过以下三种方式：
- db.collection.remove()
删除单个文档或满足条件的所有文档。
- db.collection.deleteMany()
删除满足条件的所有文档。
- db.collection.bulkWrite()
批量操作接口，可执行批量插入、更新、删除操作。
接下来，对比下这三种方式的执行效率。
三种方式的执行效率对比
===========
环境：MongoDB 3.4.4，副本集。
测试思路：分别使用 remove、deleteMany、bulkWrite 删除 10w 条记录（每批删除 5000 条），交叉执行 5 次。
1. remove
// delete_date是删除条件
var delete_date = new Date(“2021-01-01T00:00:00.000Z”);
// 获取程序开始时间
var start_time = new Date();
// 获取满足删除条件的记录数
rows = db.test_collection.find({“createtime”: {$lt: delete_date}}).count()
print(“total rows:”, rows);
// 定义每批需要删除的记录数
var batch_num = 5000;
while (rows > 0) {
// rows也可理解为剩余记录数
// 如果剩余记录数小于batch_num，则将剩余记录数赋值给batch_num
// 为什么要怎么做，后面会提到。
if (rows < batch_num) {
batch_num = rows;
}
// 获取满足删除条件的最小的5000个_id（ObjectID）
var cursor = db.test_collection.find({“createtime”: {$lt: delete_date}}, {“_id”: 1}).sort({“_id”: 1}).limit(batch_num);
rows = rows - batch_num;
cursor.forEach(function (each_row) {
// 通过remove删除记录，这里指定了"justOne": true，每次只能删除一条记录。
// 为了避免误删除，这里同时指定了主键和删除条件。
db.test_collection.remove({‘_id’: each_row[“_id”], “createtime”: {‘$lt’: delete_date}}, {
“justOne”: true,
w: “majority”
})
});
}
// 获取程序结束时间
var end_time = new Date();
// 两者的差值，即为程序执行时长
print((end_time - start_time) / 1000);
2. deleteMany
实例思路同remove类似，只不过会将待删除的_id放到一个数组中，最后再通过deleteMany一次性删除。
具体代码如下：
var delete_date = new Date(“2021-01-01T00:00:00.000Z”);
var start_time = new Date();
rows = db.test_collection.find({“createtime”: {$lt: delete_date}}).count()
print(“total rows:”, rows);
var batch_num = 5000;
while (rows > 0) {
if (rows < batch_num) {
batch_num = rows;
}
var cursor = db.test_collection.find({“createtime”: {$lt: delete_date}}, {“_id”: 1}).sort({“_id”: 1}).limit(batch_num);
rows = rows - batch_num;
var delete_ids = [];
// 将满足条件的主键值放入到数组中。
cursor.forEach(function (each_row) {
delete_ids.push(each_row[“_id”]);
});
// 通过deleteMany一次删除5000条记录。
db.test_collection.deleteMany({
‘_id’: {“$in”: delete_ids},
“createTime”: {‘$lt’: delete_date}
},{w: “majority”})
}
var end_time = new Date();
print((end_time - start_time) / 1000);
3. bulkWrite
实现思路同deleteMany类似，也是将待删除的_id放到一个数组中，最后再调用bulkWrite进行删除。
具体代码如下：
var delete_date = new Date(“2021-01-01T00:00:00.000Z”);
var start_time = new Date();
rows = db.test_collection.find({“createtime”: {$lt: delete_date}}).count()
print(“total rows:”, rows);
var batch_num = 5000;
while (rows > 0) {
if (rows < batch_num) {
batch_num = rows;
}
var cursor = db.test_collection.find({“createtime”: {$lt: delete_date}}, {“_id”: 1}).sort({“_id”: 1}).limit(batch_num);
rows = rows - batch_num;
var delete_ids = [];
cursor.forEach(function (each_row) {
delete_ids.push(each_row[“_id”]);
});
db.test_collection.bulkWrite(
[
{
deleteMany: {
“filter”: {
‘_id’: {“$in”: delete_ids},
“createTime”: {‘$lt’: delete_date}
}
}
}
],
{ordered: false},
{writeConcern: {w: “majority”, wtimeout: 100}}
)
}
var end_time = new Date();
print((end_time - start_time) / 1000);
接下来，看看三者的执行效率。
| 删除方式 | 平均执行时间（s） | 第一次 | 第二次 | 第三次 | 第四次 | 第五次 |
| — | — | — | — | — | — | — |
| remove | 47.341 | 49.606 | 48.487 | 49.314 | 47.572 | 41.727 |
| deleteMany | 16.951 | 16.566 | 18.669 | 17.932 | 18.66 | 12.928 |
| bulkWrite | 16.476 | 17.247 | 14.181 | 16.151 | 18.403 | 16.397 |
结合表中的数据，可以看出，
-
执行最慢的是remove，执行最快的是bulkWrite，前者差不多是后者的 2.79 倍。
-
deleteMany 和 bulkWrite 的执行效率差不多，但就语法而言，前者比后者简洁。
所以线上如果要删除大量数据，推荐使用 deleteMany + ObjectID 进行批量删除。
通过 Write Concern 规避主从延迟
=======================
虽然是批量删除，但在MySQL中，如果没控制好节奏，还是很容易导致主从延迟。在MongoDB中，其实也有类似的担忧，不过我们可以通过 Write Concern 进行规避。
Write Concern，可理解为写安全策略，简单来说，它定义了一个写操作，需要在几个节点上应用（Apply）完，才会给客户端反馈。
看下面这个原理图。
图中是一个一主两从的副本集，设置了w: “majority”，代表一个写操作，需要等待副本集中绝大多数节点（本例中是两个）应用完，才能给客户端反馈。
在前面的代码中，无论是remove，deleteMany还是bulkWrite方法，都设置了w: “majority”。
之所以这样设置，一方面是为了保证数据的安全性，毕竟删除操作能在多个节点落盘，另一方面，还能有效降低批量操作可能导致的主从延迟风险。
Write Concern的完整语法如下，
{ w: , j: , wtimeout: }
其中，
w：指定节点数或tags。其有如下取值：
- ：显式指定节点数量。
设置为0，无需Server端反馈。
设置为1，只需Primary节点反馈。
设置为2，在副本集中，需要一个Primary节点（Primary节点必需）和一个Secondary节点反馈。
需要注意的是，这里的Secondary节点必须是数据节点，可以是隐藏节点、延迟节点或Priority为 0 的节点，但仲裁节点（Arbiter）绝对不行。
一般来说，设置的节点数越多，数据越安全，写入的效率也会越低。
- majority：副本集大多数节点。
与上面不一样的是，这里的Secondary节点不仅要求是数据节点，它的votes（members[n].votes）还必须大于0。
- ：指定tags。
tag，顾名思义，是给节点打标签。常用于多数据中心部署场景。
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！
econdary节点不仅要求是数据节点，它的votes（members[n].votes）还必须大于0。
- ：指定tags。
tag，顾名思义，是给节点打标签。常用于多数据中心部署场景。
[外链图片转存中…(img-cYAGbJzu-1715796381635)]
[外链图片转存中…(img-2gJPNlJa-1715796381635)]
网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。
一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！