【Mongodb-01】Mongodb亿级数据性能测试和压测

2024-06-15 21:52
文章标签 数据 性能 压测 测试 mongodb 01 亿级

本文主要是介绍【Mongodb-01】Mongodb亿级数据性能测试和压测，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

mongodb数据性能测试

  • 一，mongodb数据性能测试
        • 1，mongodb数据库创建和索引设置
        • 2，线程池+批量方式插入数据
        • 3，一千万数据性能测试
        • 4，两千万数据性能测试
        • 5，五千万数据性能测试
        • 6，一亿条数据性能测试
        • 7，压测
        • 8，总结

一，mongodb数据性能测试

如需转载，请标明出处：https://zhenghuisheng.blog.csdn.net/article/details/139505973

之前公司将用户的游戏数据存储在mysql中，就是直接将json数据存储到mysql数据库里面，几个月不到，数据库里面已经有两亿条数据，而且每行中每个json数据量也比较大，导致占用的磁盘容量也比较大，因此为了解决mysql带来多方面的瓶颈，最终选择使用mongodb来代替mysql。为了测试mongodbdb的性能以及是否满足需求，因此做了以下测试，对mongodb在高流量时验证其增删改查的效率，以及对其进行压测

服务器配置：2核4g轻量级服务器 磁盘容量 70GB

每条数据大概在500个字节，索引有一个id主键索引，还有一个parentId和category的联合唯一索引，这里两个字段能保证唯一性，因此用唯一索引效率更优

1，mongodb数据库创建和索引设置

首先在Java代码中创建一个实体类，用这个类作为json对象插入到文档中即可。

@Data
public class Archive {private String id;//账号idprivate String parentId;private String category;private String content;
}

随后在mongodb中创建一个数据库，然后再该库下面建立一个名为 archive 的集合，mongodb的集合就是类似于mysql的表，两者概念是一样的。由于后期数据量可能非常大，因此根据mongodb官方文档所说，在数据插入前，尽量提前建立索引，为了满足业务需求，这里选择创建一个联合索引，由于我这边业务能保证要加索引的两个字段的唯一性，因此选择直接添加唯一索引

db.users.createIndex({parentId: 1,category:1}, {unique: true})

如果navicate操作不方便的话，可以安装一个 Mongodb Compass 可视化工具，如下图，很多操作都是可以在这个可视化图形界面上面直接操作的
在这里插入图片描述

2，线程池+批量方式插入数据

由于这边主要是io操作将数据插入，不需要计算之类的，因此选择使用io密集型线程池，接下来自定义一个线程池

@Slf4j
public class ThreadPoolUtil {public static ThreadPoolExecutor pool = null;public static synchronized ThreadPoolExecutor getThreadPool() {if (pool == null) {//获取当前机器的cpuint cpuNum = Runtime.getRuntime().availableProcessors();int maximumPoolSize = cpuNum * 2 ;pool = new ThreadPoolExecutor(maximumPoolSize - 2,maximumPoolSize,5L,   //5sTimeUnit.SECONDS,new LinkedBlockingQueue<>(),  //数组有界队列Executors.defaultThreadFactory(), //默认的线程工厂new ThreadPoolExecutor.AbortPolicy());  //直接抛异常，默认异常}return pool;}
}

第二步就是定义一个线程任务，到时将任务丢到线程池里面，其代码如下，该任务实现Callable接口，每个线程插入10万条，每次批量插入100条数据，大概就是需要1000次

@Data
public class ArchiveTask implements Callable {private MongoTemplate mongoTemplate;public ArchiveTask(MongoTemplate mongoTemplate){this.mongoTemplate = mongoTemplate;}@Overridepublic Object call() throws Exception {List<Archive> list = new ArrayList<>();for (int i = 1; i <= 100000; i++) {Archive archive = new Archive();archive.setCategory("score");archive.setId(SnowflakeUtils.nextOrderId());archive.setParentId(SnowflakeUtils.nextOrderId());Map<String,String> map = new HashMap<>();StringBuilder sb = new StringBuilder();for (int j = 0; j < 15; j++) {sb.append(UUID.randomUUID());}map.put("key" + i, sb.toString());archive.setContent(JSON.toJSONString(map));list.add(archive);if (i%100 == 0){mongoTemplate.insertAll(list);list.clear();	//手动gc，100个对象没被引用会被回收list = new ArrayList<>();}}return null;}
}

最后定义一个测试类或者一个接口，我这边使用接口，部分代码如下，循环100次，就是会创建100个线程任务，随后将这个线程任务丢到线程池中，100乘以100000就是1千万条数据

@Resource
private MongoTemplate mongoTemplate;
static ThreadPoolExecutor threadPool = ThreadPoolUtil.getThreadPool();
@GetMapping("/add")
public void test(){for (int i = 0; i < 100; i++) {ArchiveTask archiveTask = new ArchiveTask(mongoTemplate);threadPool.submit(archiveTask);}log.info("数据添加完成");
}
3，一千万数据性能测试

mongodb性能测试，此时archive 集合中已有10134114条数据，平均每条数据大小674字节，1千多万条，此时的存储大小为5.5个g，索引的总大小为459m

接下来通过唯一索引查询一条数据，这里直接通过parentId查询一条数据，此时数据还是在不断插入的

db.archive.find({parentId:"2405291858848274156091867143"})

是的，如下图所示，1000多万条数据里面查询，只需要25ms即可将数据放回，当然这里没有在高流量的情况下进行压测。

在这里插入图片描述

4，两千万数据性能测试

此时archive集合来到了两千万条，每条数据和之前一样，平均大小是674字节，数据总大小来到了10.92G，内存大小12.65g，索引总大小是913m
在这里插入图片描述

接下来测试查询效率，依旧使用上面的这个parentId，由于设置的是parentId+category的联合唯一索引，接下来两个参数一起查

db.archive.find({parentId:"2405291858848274156091867143",category:"score"})

2000万的数据查询结果如下，只需要21ms，和上面的25ms慢了将近4ms，但是这4ms可以忽略

在这里插入图片描述

5，五千万数据性能测试

由于70G的磁盘容量已经只剩48G，因此在content字段将500字节的值调小，调整到150个字节，以便能插入更多数据。将上面的StringBuilder拼接的15个uuid改成1个uuid

map.put("key" + i,UUID.randomUUID().toString());

此时数据来到50245694条数据，每条数据平均大小372kb，总存储大小12.66g，内存中的总大小17.45g，索引大小目前只有2.8g

在这里插入图片描述

为了保证拿到的parentId是一次没有查询过的，手动的插入一批数据，手动单条插入20条数据，耗时600ms，在插入数据时会改变索引，插入数据会稍微慢些。此时的插入操作都是在多线程插入大量数据的时候测试的

db.archive.insertOne({parentId:"2024111222337",category:"score1",content:"cbasbsadhpasdbsaodgs"})
db.archive.insertOne({parentId:"2024111222337",category:"score2",content:"cbasbsadhpasdbsaodgs"})
....

此时第一次查询这条数据，共耗时153ms，共查出20条数据

在这里插入图片描述

再第二次查询之后，花费78ms，内部应该也是会将查询结果加入到缓存中，方便第二次查询

在这里插入图片描述

在上面的插入操作中由于会破坏到索引结构，因此耗时久一点。接下来看这个更新操作，

db.archive.updateOne({ parentId: "2024111222337",category:"score1" },{ $set: { content: "cbasbsadhpasdbsaodgsscore" } }
);

其结果如下，更新了一条数据，只花费了13毫秒的时间，因此更新操作速度是很快的。由于这里每一条数据都是唯一数据，因此不测试批量更新

在这里插入图片描述

最后测试删除数据，将这20条数据全部删除，总共花费18毫秒

在这里插入图片描述

6，一亿条数据性能测试

数据通过多线程+批量插入的方式来到一亿条，存储大小15.5g，索引长度是6g

db.archive.countDocuments()  //查询共有多少条数据
100082694

在这里插入图片描述

接下来往里面重新插入一部分数据，往里面插入20条数据，大概花费160多ms，插入数据会导致索引重构，所以耗时久一些，批量插入性能会更快。重新插入的数据可以保证这条数据没被查过，并且知道parentId是什么

db.archive.insertOne({parentId:"20240531101059",category:"score1",content:"abcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxyabcdefghijklmnopqrstuvwxy"})
....

接下来测试查询数据，只需要19ms

db.archive.find({parentId:"20240531101054"},{parentId:1,category:1}) //只返回部分字段
db.archive.find({parentId:"20240531101058"})

在这里插入图片描述

更新数据如下，只需要10ms

db.archive.updateOne({ parentId: "20240531101059",category:"score1" },{ $set: { content: "cbasbsadhpasdbsaodgsscore" } }
);

在这里插入图片描述

7，压测

以下压测都是数据达到1亿之后进行测试的，并且都是使用的2核4g的服务器

在1s内同时1000个线程插入数据，每个线程插入20条数据，中位数24，吞吐量391

在这里插入图片描述

在1s内10000个线程插入数据，也是每个线程批量插入20条数据，可以发现就算是2核4g这么垃圾的轻量级服务器，10000qps也是毫无压力的

在这里插入图片描述

插入数据会破坏索引，相对于修改和查询是更慢的，接下来测试1s内10000个线程同时执行增改查，吞吐量可以达到2251.7

在这里插入图片描述

部分代码片段如下，让10000个线程随机的执行增改查的操作，在1s内是毫无压力的

在这里插入图片描述

8，总结

通过上面的数据以及mongodb的响应来看，mongodb的性能还是非常不错的。看看GPT对这种数据的评价，gpt也认为mongodb是非常合适的。当然不管什么数据和业务，只要其本质是 json 数据，不管json内部结构多复杂，用mongodb都是非常合适的。mongodb还适合存一些订单数据，地理数据，大数据等等，其应用范围是非常广泛的

在这里插入图片描述

这篇关于【Mongodb-01】Mongodb亿级数据性能测试和压测的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/1064679。

相关文章

Vue3 的 shallowRef 和 shallowReactive：优化性能

Vue3 的 shallowRef 和 shallowReactive：优化性能

大家对 Vue3 的 ref 和 reactive 都很熟悉，那么对 shallowRef 和 shallowReactive 是否了解呢？ 在编程和数据结构中，“shallow”（浅层）通常指对数据结构的最外层进行操作，而不递归地处理其内部或嵌套的数据。这种处理方式关注的是数据结构的第一层属性或元素，而忽略更深层次的嵌套内容。 1. 浅层与深层的对比 1.1 浅层（Shallow） 定义
阅读更多...
大模型研发全揭秘：客服工单数据标注的完整攻略

大模型研发全揭秘：客服工单数据标注的完整攻略

在人工智能（AI）领域，数据标注是模型训练过程中至关重要的一步。无论你是新手还是有经验的从业者，掌握数据标注的技术细节和常见问题的解决方案都能为你的AI项目增添不少价值。在电信运营商的客服系统中，工单数据是客户问题和解决方案的重要记录。通过对这些工单数据进行有效标注，不仅能够帮助提升客服自动化系统的智能化水平，还能优化客户服务流程，提高客户满意度。本文将详细介绍如何在电信运营商客服工单的背景下进行
阅读更多...
基于MySQL Binlog的Elasticsearch数据同步实践

基于MySQL Binlog的Elasticsearch数据同步实践

一、为什么要做 随着马蜂窝的逐渐发展，我们的业务数据越来越多，单纯使用 MySQL 已经不能满足我们的数据查询需求，例如对于商品、订单等数据的多维度检索。 使用 Elasticsearch 存储业务数据可以很好的解决我们业务中的搜索需求。而数据进行异构存储后，随之而来的就是数据同步的问题。 二、现有方法及问题 对于数据同步，我们目前的解决方案是建立数据中间表。把需要检索的业务数据，统一放到一张M
阅读更多...
关于数据埋点，你需要了解这些基本知识

关于数据埋点，你需要了解这些基本知识

产品汪每天都在和数据打交道，你知道数据来自哪里吗？ 移动app端内的用户行为数据大多来自埋点，了解一些埋点知识，能和数据分析师、技术侃大山，参与到前期的数据采集，更重要是让最终的埋点数据能为我所用，否则可怜巴巴等上几个月是常有的事。   埋点类型 根据埋点方式，可以区分为： 手动埋点半自动埋点全自动埋点 秉承“任何事物都有两面性”的道理：自动程度高的，能解决通用统计，便于统一化管理，但个性化定
阅读更多...
性能测试介绍

性能测试介绍

性能测试是一种测试方法，旨在评估系统、应用程序或组件在现实场景中的性能表现和可靠性。它通常用于衡量系统在不同负载条件下的响应时间、吞吐量、资源利用率、稳定性和可扩展性等关键指标。 为什么要进行性能测试 通过性能测试，可以确定系统是否能够满足预期的性能要求，找出性能瓶颈和潜在的问题，并进行优化和调整。 发现性能瓶颈：性能测试可以帮助发现系统的性能瓶颈，即系统在高负载或高并发情况下可能出现的问题
阅读更多...
使用SecondaryNameNode恢复NameNode的数据

使用SecondaryNameNode恢复NameNode的数据

1）需求： NameNode进程挂了并且存储的数据也丢失了，如何恢复NameNode 此种方式恢复的数据可能存在小部分数据的丢失。 2）故障模拟 （1）kill -9 NameNode进程 [lytfly@hadoop102 current]$ kill -9 19886 （2）删除NameNode存储的数据（/opt/module/hadoop-3.1.4/data/tmp/dfs/na
阅读更多...
异构存储（冷热数据分离）

异构存储（冷热数据分离）

异构存储主要解决不同的数据，存储在不同类型的硬盘中，达到最佳性能的问题。 异构存储Shell操作 （1）查看当前有哪些存储策略可以用 [lytfly@hadoop102 hadoop-3.1.4]$ hdfs storagepolicies -listPolicies （2）为指定路径（数据存储目录）设置指定的存储策略 hdfs storagepolicies -setStoragePo
阅读更多...
Hadoop集群数据均衡之磁盘间数据均衡

Hadoop集群数据均衡之磁盘间数据均衡

生产环境，由于硬盘空间不足，往往需要增加一块硬盘。刚加载的硬盘没有数据时，可以执行磁盘数据均衡命令。（Hadoop3.x新特性） plan后面带的节点的名字必须是已经存在的，并且是需要均衡的节点。 如果节点不存在，会报如下错误： 如果节点只有一个硬盘的话，不会创建均衡计划： （1）生成均衡计划 hdfs diskbalancer -plan hadoop102 （2）执行均衡计划 hd
阅读更多...
字节面试 | 如何测试RocketMQ、RocketMQ？

字节面试 | 如何测试RocketMQ、RocketMQ？

字节面试：RocketMQ是怎么测试的呢？ 答： 首先保证消息的消费正确、设计逆向用例，在验证消息内容为空等情况时的消费正确性； 推送大批量MQ，通过Admin控制台查看MQ消费的情况，是否出现消费假死、TPS是否正常等等问题。（上述都是临场发挥，但是RocketMQ真正的测试点，还真的需要探讨） 01 先了解RocketMQ 作为测试也是要简单了解RocketMQ。简单来说，就是一个分
阅读更多...
性能分析之MySQL索引实战案例

性能分析之MySQL索引实战案例

文章目录 一、前言二、准备三、MySQL索引优化四、MySQL 索引知识回顾五、总结 一、前言 在上一讲性能工具之 JProfiler 简单登录案例分析实战中已经发现SQL没有建立索引问题，本文将一起从代码层去分析为什么没有建立索引？ 开源ERP项目地址：https://gitee.com/jishenghua/JSH_ERP 二、准备 打开IDEA找到登录请求资源路径位置
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2