MongoDB三分钟插入100万数据

文章目录

      • 三、小试牛刀露锋芒
      • 一、黑云压城城欲摧
      • 二、山重水复疑无路
      • 四、回首向来萧瑟处,归去,也无风雨也无晴
      • 五、按下葫芦浮起瓢
      • 六、不计较一城一池之得失

三、小试牛刀露锋芒

现网GhsHis表有几百万数据,但是测试环境只有几万数据,想要模拟现网数据量进行测试。

叮嘱测试用js脚本往数据库插入,结果她还是调了接口进行插入。虽然测试环境MongoDB部署的还是分片集群,但是,还是把测试环境搞挂了。

关键时刻,还得开发上场。

有了测试同事的教训,为了研发环境的安全,我用js脚本先插入了一万条数据小试牛刀。结果呢,执行得很慢。考虑到还有主从复制,从
库查询压力也很大。

肯定不能一条一条插。那就批量插入。刚好MongoDB有支持批量插入的命令insertMany,于是试了一下,果真批量插入,速度不同凡
响,快的不是一星半点。

理论上可行,但实践起来还有很多细节要考虑。

要插入一百万数据,肯定不能一次性插入,我们一次插入一万,分一百次插入。写两层for循环轻松搞定。

插入的数据不能一模一样,比如创建时间和进入历史表的时间不能都一样,所以需要动态设置。

尝试插入了二十条数据,虽然动态设置了时间,但是发现最终所有数据都跟最后一条数据时间一毛一样。

我一个写Java的,为啥要让我写Js脚本?我感觉你这是在为难我胖虎。

钱难挣,屎难吃,工资也不是那么好拿的。于是,我又开始了面向百度编程。

很明显是由于对Js语法不了解导致的。百度了两行代码,试了一下可以。

var b = {};
Object.assign(b, a);
b.createDate = NumberLong(new Date().getTime() - Math.round(Math.random() * 10000) + 10000);

之前写的是

var b;
b.createDate = NumberLong(new Date().getTime() - Math.round(Math.random() * 10000) + 10000);

然后就是往数组里面插入数据,使用push方法即可。

统计一下执行脚本的耗时,java的sout使用的是加号拼接,Js使用的是逗号拼接。

var time = new Date().getTime();
print("执行耗时:",new Date().getTime()-time);

让时间具有随机性,调用Js数学类库函数。

NumberLong(new Date().getTime() - Math.round(Math.random() * 10000) + 10000);

最终脚本

var a = {
    "customerId": "123456789",
    "username": "[email protected]",
    "pkgId": "66666666",
    "state": "USE_END",
    "price": 1.0,
    "createDate": NumberLong(1666341382443),
    "orgId": "963852741",
    "deptId": "147258369",
    "remark": "666",
    "inHisTime": NumberLong(1666346588556)
};

var time = new Date().getTime();
for (j = 1; j <= 100; j++) {
    var arr = [];
    for (i = 1; i <= 10000; i++) {
        var b = {};
        Object.assign(b, a);
        if (i % 3 == 0) {
            b.state = "USE_END";
        } else if (i % 3 == 1) {
            b.state = "EXPIRE";
        } else {
            b.state = "TRANSFER";
        }
        b.createDate = NumberLong(new Date().getTime() - Math.round(Math.random() * 10000) + 10000);
        b.inHisTime = NumberLong(b.createDate + Math.round(Math.random() * 10000) + 100);
        arr.push(b);
    }
    db.GhsHis.insertMany(arr);
}
print("执行耗时:",new Date().getTime()-time);

今天是程序员节,祝大家节日快乐!!!

大功告成???

不,这才是万里长征第一步。革命尚未成功,同志仍需努力!!!

数据是构造好了,有了跟现网差不多的数据量级,但是现网问题的复现、测试还没开始呢!!!

一、黑云压城城欲摧

故事背景:现网导出接口导出Excel数据出现了Id重复,几乎是必现。

测试环境不能复现,距离升级只有三天时间了。时间紧,任务重。

找业务人员要了当时导出的那份Excel,将Id列复制到D:\delete1.txt文件,准备用java代码分析一下。

代码思路,使用高速缓冲字符流一次读取一行,将读取到的Id放入List集合,然后遍历List集合,使用Set集合去重,拿到重复的Id以及下标。

public class IOReader {
    public static void main(String[] args) throws IOException {
        BufferedReader bis = null;
        List<String> list = new ArrayList<>();
        try {
            bis = new BufferedReader(new InputStreamReader(new FileInputStream("D:\\delete1.txt")));
            String str = null;
            while ((str = bis.readLine()) != null){
                list.add(str);
            }
        } catch (FileNotFoundException e) {
            e.printStackTrace();
        } finally {
            bis.close();
        }
        System.out.println(list.size());
        Set<String> set = new HashSet<>();
        for(int i=0;i<list.size();i++){
            if(set.contains(list.get(i))){
                System.out.println("重复数据:"+list.get(i)+",下标"+i);
            }else{
                set.add(list.get(i));
            }
        }
    }
}

通过代码分析发现,确实存在重复Id。因为Id是唯一的,出现重复有悖常理。因为有现表和历史表,表结构大差不差。导出又可以同时导出历史表和现表。查看代码发现,在将现表数据移入历史表的时候,先插入的历史表,然后删除的现表,这样在极端情况下,是可能出现导出重复Id的。

事情会这么简单吗?很明显不会。

二、山重水复疑无路

随着代码的继续深入,我发现对于导出所有的情况,代码已经做了去重处理,并无明显Bug。

带着内心的疑问,我又找到了业务人员。仔细询问了他操作的细节。

操作流水号?操作Id?很明显,业务人员并不关注这些,只是丢给了我一个用户名。

我进入用户表一查,好家伙,一个用户名对应十几个用户。

我又问了他操作时所属的部门,这才将将初步定位了嫌疑人。

案发时间在昨天,还好时间不久,一切证据还未被抹除。

现网Kabana日志只展示七天,超过七天的就只能去磁盘看。需要申请一堆的权限,耗时又费力,大家一般都不愿意申请。

将时间定格在昨天,将嫌疑人锁死在刚才找到的Id。果真寻到了案发现场。

本着不放过一切蛛丝马迹的原则,我仔仔细细地查看了案发时的证据,但并未发现什么特别的有价值的证据。

导出Excel的过程是这样的,前台请求中台,中台请求后台。每次最多导出1000条,中台分次请求后台。

我看了一下每次导出的时间间隔竟然相差14秒,确实有点大。这算是案发现场唯一的收获了。

是中台设置的请求时间还是后台接口竟然如此慢?

我去测试环境试了一下,很快。那就是后台接口慢喽。

案件一下陷入了僵局,扑朔迷离的案情属实让人焦头乱额。

大脑飞速地转动着,思索着还有哪些未考虑到的场景。

我又去看了一下导出Excel,这算是直接证据了,要好好分析一下。

凭借着精湛的业务能力和三年多的工作经验,灵光一现,我机智地发现了出现重复的数据位于每一页开头的位置。

一个Idea浮现在了我的脑海。

我激动地翻找代码,想要佐证自己的想法。果真如我所想,初步定位到了问题所在。

知错,改错,验错。第一步总算是完成了。

改错也很简单,几秒钟搞定。知错几小时,改错几秒钟。

接力棒交接到了测试同事的手中,我总算可以松一口气了。

四、回首向来萧瑟处,归去,也无风雨也无晴

测试按我所说,未能成功复现问题。球呀,又到了我的手里。

作为全场最靓的仔,这点事肯定难不倒英明神武的我。

现网每一次操作时间间隔有14秒,有充足的时间来进行我们想要的操作。测试环境只有三秒,时间不等人,拼的是手速。

交代一下我定位出来的问题:我怀疑是排序字段选择不当造成导出Id重复。

啥?排序字段还能引起导出Id重复?我只是工作了三年的实习生,你别蒙我!

别急,听我细细道来。因为导出是既可以选择现表,也可以选择历史表,它们的排序规则都是一样的:创建时间逆序。问题就出在这里,现表使用创建时间没有问题,但是历史表就有问题了,创建时间早的不一定进入历史表的时间就早。

举个例子,导出的第二页,第1001条到第2000条数据。在正导出第二页的时候,有一个创建时间恰好位于第1001条到第2000条之间的数据被插入,那么根据创建时间逆序排序,原来第2000条数据就会被排到第2001条数据的位置,表现出来就是第2001条数据Id重复。

找出数据量在10000条以上的部门,然后选一个一万条左右的部门导出。

db.GhsHis.aggregate([{$group:{_id:"$deptId",total:{$sum:1}}},{$match:{total:{$gt:10000}}}],{allowDiskUse: true})

管道有100M内存限制。设置allowDiskUse:true,允许使用磁盘存储数据。

由于测试环境数据量用户量不足,一瞬间没有那么多数据失效然后进入历史表。如此苛刻的复现条件只能是手动来提供。

三秒的操作时间,理论上是来得及操作的。但是,可能不具有普适性。测试又复现失败了。

不知道测试同事心中此时作何感想。(叼毛,按你说的方法复现不了问题?)

为了维护我在同事心中的靓仔形象。啪,很快呀,我又写了一个脚本。

var a = {
    "customerId": "123456789",
    "username": "[email protected]",
    "pkgId": "66666666",
    "state": "USE_END",
    "price": 1.0,
    "createDate": NumberLong(1666341382443),
    "orgId": "963852741",
    "deptId": "147258369",
    "remark": "666",
    "inHisTime": NumberLong(1666346588556)
};
function sleep(number){
    var now = new Date();
    var exitTime = now.getTime() + number;
    while (true) {
        now = new Date();
        if(now.getTime() > exitTime){
          return;
        }
    }
}
var timeArr=[1641864542173,1641864263779,1637305936014,1637293032528,1636098374840,1624608384592,1621040814675,1617868030123,1617866906466];
timeArr.forEach(function(t){
    var b = {};
    Object.assign(b, a);
    b.createDate = NumberLong(t);
    sleep(200);
    db.GhsHis.insert(b);
});

开发呀,你不讲武德,你跟我说用手操作,你竟然偷偷写脚本。

还不是为了操作的普适性,为了问题在测试环境必现,你以为我想写脚本呀?

说起来云淡风轻,实际上斩棘披荆。

老规矩:先解释一下代码思路。找出了九个时间点,这九个时间点都是位于第二页的。然后遍历,每隔200毫秒,以该时间点为创建时间,插入一条数据,代表的是此时有一条创建时间位于第二页的数据被插入历史表,以此来模拟现网操作。

Java线程睡眠一行代码就够了,Js竟然还得自己写,当然都是百度的了。

那这九个时间点是怎么找出来的?

db.GhsHis.find({"deptId" : "147258369","state":{$in:["EXPIRE","USE_END","TRANSFER"]}}).sort({"createDate":-1}).skip(1100)

skip那里改成1200,一直到1900,找出9个创建时间。

我将脚本给了测试,让他在第一页导出之后,第二页正在导出的时候,立刻执行该脚本。

结果呢,翻车了,还是没有复现。

大意呀,我没有改进入历史表的时间。因为我改了排序规则,新规则使用进入历史表的时间和创建时间两个字段来逆向排序。

b.inHisTime= NumberLong(new Date().getTime());

又把脚本给了测试,问题成功复现!靓仔的形象得到了强有力的维护!自己的形象要靠自己来维护。

五、按下葫芦浮起瓢

然后,测试升级版本,开始验错,到了校验我改错的时候了。

结果又翻车了!!!每次都能复现问题,改了跟没改一样,我怕不是改了个毛线?

这下好了,靓仔彻底变叼毛了。

细细端详代码,思忖着究竟是哪里出了问题?原来是排序字段的排序方式有问题。

之前是按照创建时间逆向排序,我想都没想,就沿用了之前的方式,根据进入历史表的时间和创建时间两个字段来逆向排序。(当进入历史表时间相同,按照创建时间来逆向排序)

我怎能重蹈前任的覆辙呢?我跟他们又有什么区别?我改错又有什么意义呢?只是从一个坑爬到了另一个坑。

大意,还是大意呀。不仅丢了燕云十八州,连荆襄九郡都丢了。

痛定思痛,痛改前非。

还是时间太紧急了,搞得我很急躁,都不能冷静思考了,犯了如此低级的错误。总得给自己找个借口安慰一下英明神武明察秋毫的自己。

改成正向排序以后,问题果然解决了。问题不会复现了。Nice !

现网问题到这里已经解决了,不会再导出重复的Id了。

六、不计较一城一池之得失

bug已经解决,但是优化永无止境。查询导出1000条耗费14秒,太慢了。

查询慢,第一反应肯定是没加索引。查看现网GhsHis表的索引。

db.GhsHis.getIndexes()

发现表里索引挺多的,但是,排序字段createDate竟然没加索引!

分析一下查询导出语句的执行计划,“stage” : “SORT”,证明排序没有使用索引,在内存中做了排序,且做了全表扫描。

db.GhsHis.find({"deptId" : "147258369","state":{$in:["EXPIRE","USE_END","TRANSFER"]}})
.sort({"createDate":-1}).skip(1000).limit(1000).explain("executionStats")

鉴于已经修改了排序规则,所以我给进入历史表时间和创建时间建了联合索引。{background:true}这句一定要加,否则会锁表。

db.GhsHis.ensureIndex({inHisTime:1,createDate:1},{background:true})

state字段与deptId字段数据区分度不高,暂时不加索引。

db.GhsHis.find({"deptId" : "147258369","state":{$in:["EXPIRE","USE_END","TRANSFER"]}}).sort({"inHisTime":1,"createDate":1}).skip(1000).limit(1000).explain("executionStats")

再次查看执行计划,“stage” : “IXSCAN”,说明使用了索引,只扫描了几千条数据,查询时间也只有几十毫秒了。

MongoDB的执行计划比起Mysql而言更加复杂难懂,后续有时间再做深入研究学习,今日尚且浅尝辄止!

你可能感兴趣的:(#,MongoDB,1024程序员节,MongoDB批量插入,MongoDB索引)