最全MongoDB中如何优雅地删除大量数据,2024年最新膜拜

avatar
作者
猴君
阅读量:0

img
img

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

需要这份系统化资料的朋友,可以戳这里获取

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

  • 锁定的记录多

相对而言,更容易导致锁等待。

即使是分布式数据库,如TiDB,如果一次删除了大量数据,这批数据在进行Compaction时有可能会触发流控。

所以,对于线上的大规模删除操作,建议分而治之。具体来说,就是批量删除,每次只删除一部分数据,分多次执行。

就如何删除大量数据,接下来我们看看MongoDB中的落地方案。

本文主要包括以下四部分内容。

  1. MongoDB中删除数据的三种方式。

  2. 三种方式的执行效率对比。

  3. 通过Write Concern规避主从延迟。

  4. 删除过程中碰到的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 |

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

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

img
img

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

需要这份系统化资料的朋友,可以戳这里获取

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

econdary节点不仅要求是数据节点,它的votes(members[n].votes)还必须大于0。

  • :指定tags。

tag,顾名思义,是给节点打标签。常用于多数据中心部署场景。

[外链图片转存中…(img-cYAGbJzu-1715796381635)]
[外链图片转存中…(img-2gJPNlJa-1715796381635)]

网上学习资料一大堆,但如果学到的知识不成体系,遇到问题时只是浅尝辄止,不再深入研究,那么很难做到真正的技术提升。

需要这份系统化资料的朋友,可以戳这里获取

一个人可以走的很快,但一群人才能走的更远!不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人,都欢迎加入我们的的圈子(技术交流、学习资源、职场吐槽、大厂内推、面试辅导),让我们一起学习成长!

广告一刻

为您即时展示最新活动产品广告消息,让您随时掌握产品活动新动态!