服务器之家:专注于服务器技术及软件下载分享
分类导航

Mysql|Sql Server|Oracle|Redis|MongoDB|PostgreSQL|Sqlite|DB2|mariadb|Access|数据库技术|

服务器之家 - 数据库 - MongoDB - MongoDB中优雅删除大量数据的三种方式

MongoDB中优雅删除大量数据的三种方式

2021-11-17 17:36iVictor MongoDB

最近接到一个任务,线上的mongodb积累了大量的无用数据,导致宕机,现在对里面的数据进行批量删除,所以这篇文章主要给大家介绍了关于MongoDB中优雅删除大量数据的三种方式,需要的朋友可以参考下

删除大量数据,无论是在哪种数据库中,都是一个普遍性的需求。除了正常的业务需求,我们需要通过这种方式来为数据库“瘦身”。

为什么要“瘦身”呢?

1、表的数据量到达一定量级后,数据量越大,表的查询性能会越差。

毕竟数据量越大,b+树的层级会越高,需要的io也会越多。

2、表的数据有冷热之分,将很多无用或很少用到的数据存储在数据库中会消耗数据库的资源。

譬如会占用缓存;会增加备份集的大小,进而影响备份的恢复时间等。

所以,对于那些无用的数据,我们会定期删除。

对于那些很少用到的数据,则会定期归档。归档,一般是将数据写入到归档实例或抽取到大数据组件中。归档完毕后,会将对应的数据从原实例中删除。

一般来说,这种删除操作涉及的数据量都比较大。

对于这类删除操作,很多开发童鞋的实现就是一个简单的delete操作。看上去,简单明了,干净利落。

但是,这种方式,危害性却极大。

以 mysql 为例:

  • 会造成大事务
    大事务会导致主从延迟,而主从延迟又会影响数据库的高可用切换。
  • 回滚表空间会不断膨胀
    在mysql 8.0之前,回滚表空间默认是放到系统表空间中,而系统表空间一旦”膨胀“,就不会收缩。
  • 锁定的记录多
    相对而言,更容易导致锁等待。

即使是分布式数据库,如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

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
// 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一次性删除。

具体代码如下:

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
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进行删除。

具体代码如下:

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
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)完,才会给客户端反馈。

看下面这个原理图。

MongoDB中优雅删除大量数据的三种方式

图中是一个一主两从的副本集,设置了w: "majority",代表一个写操作,需要等待副本集中绝大多数节点(本例中是两个)应用完,才能给客户端反馈。

在前面的代码中,无论是remove,deletemany还是bulkwrite方法,都设置了w: "majority"。

之所以这样设置,一方面是为了保证数据的安全性,毕竟删除操作能在多个节点落盘,另一方面,还能有效降低批量操作可能导致的主从延迟风险。

write concern的完整语法如下,

?
1
{ w: <value>, j: <boolean>, wtimeout: <number> }

其中,

w:指定节点数或tags。其有如下取值:

  • <number>:显式指定节点数量。

设置为0,无需server端反馈。

设置为1,只需primary节点反馈。

设置为2,在副本集中,需要一个primary节点(primary节点必需)和一个secondary节点反馈。

需要注意的是,这里的secondary节点必须是数据节点,可以是隐藏节点、延迟节点或priority为 0 的节点,但仲裁节点(arbiter)绝对不行。

一般来说,设置的节点数越多,数据越安全,写入的效率也会越低。

  • majority:副本集大多数节点。

与上面不一样的是,这里的secondary节点不仅要求是数据节点,它的votes(members[n].votes)还必须大于0。

  • <custom write concern name>:指定tags。

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

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

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

具体使用,可参考:https://docs.mongodb.com/manual/tutorial/configure-replica-set-tag-sets/#configure-custom-write-concern

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,命令在执行的过程中,如果遇到了锁等待或节点数不满足要求,会一直阻塞。

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

?
1
2
3
4
5
6
7
8
9
10
11
12
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

其实,最开始的删除程序是下面这个版本。

?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
var delete_date = new date("2021-01-01t00:00:00.000z");
var start_time = new date();
var batch_num = 5000;
while (1 == 1) {
    var cursor = db.test_collection.find({"createtime": {$lt: delete_date}}, {"_id": 1}).sort({"_id": 1}).limit(batch_num);
    delete_ids = []
    cursor.foreach(function (each_row) {
        delete_ids.push(each_row["_id"])
    });
 
    if (delete_ids.length == 0) {
        break;
    }
    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);

相对于效率对比章节的版本,这个版本的代码简洁不少。

  1. 不用额外获取需要删除的记录数。
  2. batch_num在整个执行过程中也是不变的。

但用这个版本在线上删除数据时,发现了一个问题。

在删除到最后一批时,程序会hang在那里。重试了多次依然如此。分析如下:

  • 最后一批的文档数小于batch_num时,会出现这个问题。

删除同实例下另外一个集合,也出现了类似的问题。

但在测试环境,删除一个简单的集合却没有复现出来,怀疑这个bug与线上集合的记录过长有关。

  • cursor只是一个迭代对象,并不是查询结果。基于cursor可以分批返回记录,类似于python中的迭代器。

最后一批也不是完全没有返回,而是在返回100条之后才hang在那里。

  • 不使用sort没有这个问题。

为什么要使用sort呢?这样可保证得到的id是有序且在物理上的存储是相邻的。这样,在执行批量删除操作时,效率也会相对较高。

经过实际测试,当要删除的数据量较大时,使用sort的效率确实比不使用的要高。

如果删除的数据量较小,使不使用sort则没多大区别。

总结

从最佳实践的角度出发,无论是在哪种数据库中,如果都删除(更新)大量数据,都建议分而治之,分批执行。

在mongodb中,如果要删除大量数据,推荐使用deletemany + objectid进行批量删除。

为了保证操作的安全性及规避批量操作带来的主从延迟风险,建议在执行删除操作时,将write concern设置为w: "majority"。

到此这篇关于mongodb中优雅删除大量数据的文章就介绍到这了,更多相关mongodb删除大量数据内容请搜索服务器之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持服务器之家!

参考

[1] journaling

[2] write concern

原文链接:https://www.cnblogs.com/ivictor/p/15457454.html

延伸 · 阅读

精彩推荐
  • MongoDBMongoDB系列教程(五):mongo语法和mysql语法对比学习

    MongoDB系列教程(五):mongo语法和mysql语法对比学习

    这篇文章主要介绍了MongoDB系列教程(五):mongo语法和mysql语法对比学习,本文对熟悉Mysql数据库的同学来说帮助很大,用对比的方式可以快速学习到MongoDB的命...

    MongoDB教程网3252020-05-01
  • MongoDBmongodb数据库基础知识之连表查询

    mongodb数据库基础知识之连表查询

    这篇文章主要给大家介绍了关于mongodb数据库基础知识之连表查询的相关资料,文中通过示例代码介绍的非常详细,对大家学习或者使用mongodb具有一定的参...

    ZJW02155642020-05-22
  • MongoDBMongoDB的索引

    MongoDB的索引

    数据库中的索引就是用来提高查询操作的性能,但是会影响插入、更新和删除的效率,因为数据库不仅要执行这些操作,还要负责索引的更新 ...

    MongoDB教程网2532020-05-12
  • MongoDB在mac系统下安装与配置mongoDB数据库

    在mac系统下安装与配置mongoDB数据库

    这篇文章主要介绍了在mac系统下安装与配置mongoDB数据库的操作步骤,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪...

    CXYhh1219312021-11-14
  • MongoDBWindows下MongoDB配置用户权限实例

    Windows下MongoDB配置用户权限实例

    这篇文章主要介绍了Windows下MongoDB配置用户权限实例,本文实现需要输入用户名、密码才可以访问MongoDB数据库,需要的朋友可以参考下 ...

    MongoDB教程网3082020-04-29
  • MongoDBMongodb索引的优化

    Mongodb索引的优化

    MongoDB 是一个基于分布式文件存储的数据库。由 C++ 语言编写。接下来通过本文给大家介绍Mongodb索引的优化,本文介绍的非常详细,具有参考借鉴价值,感...

    MRR3252020-05-05
  • MongoDBMongoDB查询之高级操作详解(多条件查询、正则匹配查询等)

    MongoDB查询之高级操作详解(多条件查询、正则匹配查询等)

    这篇文章主要给大家介绍了关于MongoDB查询之高级操作(多条件查询、正则匹配查询等)的相关资料,文中通过示例代码介绍的非常详细,对大家的学习或者...

    w田翔3872020-12-19
  • MongoDBMongoDB多条件模糊查询示例代码

    MongoDB多条件模糊查询示例代码

    这篇文章主要给大家介绍了关于MongoDB多条件模糊查询的相关资料,文中通过示例代码介绍的非常详细,对大家学习或者使用MongoDB具有一定的参考学习价值...

    浅夏晴空5902020-05-25