MongoDB中如何优雅地删除大量数据(1)

删除满足条件的所有文档。

• 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 |

结合表中的数据，可以看出，

1. 执行最慢的是remove，执行最快的是bulkWrite，前者差不多是后者的 2.79 倍。

2. 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，顾名思义，是给节点打标签。常用于多数据中心部署场景。

如一个集群，有5个节点，跨机房部署。其中3个节点在A机房，另外2个节点在B机房，因为对数据的安全性、一致性要求很高，我们希望写操作至少能在A机房的2个节点落盘，B机房的1个节点落盘。

对于这种个性化的需求，只有通过tags才能实现。

具体使用，可参考：Configure Replica Set Tag Sets — MongoDB Manual。

j：是否需要等待对应操作的日志持久化到磁盘中。

在MongoDB中，一个写操作会涉及到三个动作：更新数据，更新索引，写入oplog，这三个动作要么全部成功，要么全部失败，这也是MongoDB单行事务的由来。

对于每个写操作，WiredTiger都会记录一条日志到 journal 中。

日志在写入journal之前，会首先写入到 journal buffer（最大128KB）中。

Journal buffer会在以下场景持久化到 journal 文件中：

• 副本集中，当有操作等待oplog时。

这类操作包括：针对oplog最新位置点的扫描查询；Causally consistent session中的读操作；对于Secondary节点，每次批量应用oplog后。

• Write Concern 设置了 j: true。

• 每100ms。

由 storage.journal.commitIntervalMs 参数指定。

• 创建新的 journal 文件时。

当 journal 文件的大小达到100MB时会自动创建一个新的journal 文件。

wtimeout：超时时长，单位ms。

不设置或设置为0，命令在执行的过程中，如果遇到了锁等待或节点数不满足要求，会一直阻塞。

如果设置了时间，命令在这个时间内没有执行成功，则会超时报错，具体报错信息如下：

rs:PRIMARY> db.test.insert({“a”: 1}, {writeConcern: {w: “majority”, wtimeout: 100}})

WriteResult({

“nInserted”: 1,

“writeConcernError”: {

“code”: 64,

“codeName”: “WriteConcernFailed”,

“errInfo”: {

“wtimeout”: true

},

“errmsg”: “waiting for replication timed out”

}

})

删除过程中遇到的Bug

===========

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

最后

一次偶然，从朋友那里得到一份“java高分面试指南”，里面涵盖了25个分类的面试题以及详细的解析：JavaOOP、Java集合/泛型、Java中的IO与NIO、Java反射、Java序列化、Java注解、多线程&并发、JVM、Mysql、Redis、Memcached、MongoDB、Spring、Spring Boot、Spring Cloud、RabbitMQ、Dubbo 、MyBatis 、ZooKeeper 、数据结构、算法、Elasticsearch 、Kafka 、微服务、Linux。

这不，马上就要到招聘季了，很多朋友又开始准备“金三银四”的春招啦，那我想这份“java高分面试指南”应该起到不小的作用，所以今天想给大家分享一下。

请注意：关于这份“java高分面试指南”，每一个方向专题（25个）的题目这里几乎都会列举，在不看答案的情况下，大家可以自行测试一下水平 且由于篇幅原因，这边无法展示所有完整的答案解析
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
OP、Java集合/泛型、Java中的IO与NIO、Java反射、Java序列化、Java注解、多线程&并发、JVM、Mysql、Redis、Memcached、MongoDB、Spring、Spring Boot、Spring Cloud、RabbitMQ、Dubbo 、MyBatis 、ZooKeeper 、数据结构、算法、Elasticsearch 、Kafka 、微服务、Linux。

这不，马上就要到招聘季了，很多朋友又开始准备“金三银四”的春招啦，那我想这份“java高分面试指南”应该起到不小的作用，所以今天想给大家分享一下。

[外链图片转存中…(img-1zToLpE1-1713474484700)]

请注意：关于这份“java高分面试指南”，每一个方向专题（25个）的题目这里几乎都会列举，在不看答案的情况下，大家可以自行测试一下水平 且由于篇幅原因，这边无法展示所有完整的答案解析
《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！