删除满足条件的所有文档。
- 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,顾名思义,是给节点打标签。常用于多数据中心部署场景。
如一个集群,有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开发的新手,还是希望在技术上不断提升的资深开发者,这些资料都将为你打开新的学习之门!
如果你觉得这些内容对你有帮助,需要这份全套学习资料的朋友可以戳我获取!!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!
技能,往往是自己摸索成长,自己不成体系的自学效果低效漫长且无助。**
因此收集整理了一份《2024年Java开发全套学习资料》,初衷也很简单,就是希望能够帮助到想自学提升又不知道该从何学起的朋友,同时减轻大家的负担。
[外链图片转存中…(img-Jlcqjqrt-1715829310345)]
[外链图片转存中…(img-ZaDkGrrH-1715829310345)]
[外链图片转存中…(img-Ni5Wx2HA-1715829310346)]
既有适合小白学习的零基础资料,也有适合3年以上经验的小伙伴深入学习提升的进阶课程,基本涵盖了95%以上Java开发知识点,不论你是刚入门Java开发的新手,还是希望在技术上不断提升的资深开发者,这些资料都将为你打开新的学习之门!
如果你觉得这些内容对你有帮助,需要这份全套学习资料的朋友可以戳我获取!!
由于文件比较大,这里只是将部分目录截图出来,每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频,并且会持续更新!