mongodb 3.2性能测试

测试环境

机器配置

linux container

  • 4C/16G/300GSSD
  • 8C/32G/300GSSD

测试对象

版本 引擎 参数配置

4C/16G

8C/32G
mongodb3.2.6 wiredTiger
  • cacheSizeGB:12
  • syncPeriodSecs: 1
  • collectionConfig:
    blockCompressor: snappy
  • indexConfig:
    prefixCompression: true
  • cacheSizeGB:24
  • syncPeriodSecs: 1
  • collectionConfig:
    blockCompressor: snappy
  • indexConfig:
    prefixCompression: true
tokumx1.5 tokumx
cacheSize=12G

syncdelay=5


cacheSize=24G

syncdelay=5

tokumx2.0.2 tokumx cacheSize=12G
checkpointPeriod=10
cleanerIterations=10
directio=false
cleanerPeriod=2
syncdelay=5

cacheSize=24G
checkpointPeriod=10
cleanerIterations=10
directio=false
cleanerPeriod=2
syncdelay=5

测试场景

  • 测试单节点环境
  1. 100%insert
  2. 单节点_50%update50%read
  3. 5%update5%insert90%read
  4. 100%read
  5. wiredtiger_syncPeriodSecs_60与1比较
  6. sharding集群性能压测
  • 说明
  1. 场景1-4每次加载1000W数据,数据大小约13G
  2. 场景5加载5000W数据,数据大小约75G

测试方法

  • YCSB压测

测试结果

场景1:单节点_100%insert (load data)

场景2:单节点_50%update50%read

场景3:单节点_5%update5%insert90%read

场景4:单节点_100%read

场景5:wiredtiger_syncPeriodSecs_60_1

场景6:sharding集群性能测试

结论

  • load性能比较,wiredtiger优势十分明显,速度大约是同配置tokumx的5倍,且RT较短
  • 只读性能,wiredTiger性能和tokumx,比较,性能较差,但稳定;
  • 复杂情况下,wiredTiger性能较好,可支撑更高并发度的线程调用;
  • 如果不基于磁盘和网络吞吐量考虑,三个以下节点的 sharding 从性能上没有价值,现阶段结果看来,尽可能多的部署 mongos,能有效提升总体的集群利用率。
时间: 2025-01-01 03:48:29

mongodb 3.2性能测试的相关文章

MongoDB vs TokuMX 性能测试

参考文章:http://www.sarahmei.com/blog/2013/11/11/why-you-should-never-use-mongodb/ 重点是关注三个方面: 1. 如何测试 2. 如何用工具获取测试数据 3. 如何进行replacation集群的高性能配置

性能测试分析软件汇总–开源、商业全部收集

本文共包含:商业性能测试.监控.分析工具和免费.开源性能测试监控分析工具:共涉及java.php.net等各种开发语言平台,有系统性能分析.文件系统分析.微博.系统分析.数据性能分析等各种工具,可以说本文包含了现有的所有的性能测试监控分析工具工具133种. Java程序性能分析工具 VisualVM VisualVM是一个集成多个JDK命令行工具的可视化工具.可以作为Java应用程序性能分析和运行监控的工具.开发人员可以利用它来监控.分析线程信息,浏览内存堆数据.系统管理员可以利用它来监测.控制

不使用spring的情况下原生java代码两种方式操作mongodb数据库

由于更改了mongodb3.0数据库的密码,导致这几天storm组对数据进行处理的时候,一直在报mongodb数据库连接不上的异常.   主要原因实际上是和mongodb本身无关的,因为他们改的是配置文件的密码,而实际上这个密码在代码中根本就没有使用,他们在代码中已经把用户验证信息写死.   在协助他们解决这个问题的时候,我看到他们代码中在和mongodb数据库交互时使用了已经不被建议使用的方法,于是便抽时间尝试了一下另一种被建议的方式实现各功能.   当然了,生产环境中用的是mongodb集群

不使用spring的情况下用java原生代码操作mongodb数据库的两种方式

由于更改了mongodb3.0数据库的密码,导致这几天storm组对数据进行处理的时候,一直在报mongodb数据库连接不上的异常.   主要原因实际上是和mongodb本身无关的,因为他们改的是配置文件的密码,而实际上这个密码在代码中根本就没有使用,他们在代码中已经把用户验证信息写死.   在协助他们解决这个问题的时候,我看到他们代码中在和mongodb数据库交互时使用了已经不被建议使用的方法,于是便抽时间尝试了一下另一种被建议的方式实现各功能.   当然了,生产环境中用的是mongodb集群

我为什么放弃MySQL?最终选择了MongoDB

最近有个项目的功能模块,为了处理方便,需要操作集合类型的数据以及其他原因.考虑再三最终决定放弃使用MySQL,而选择MongoDB. 两个数据库,大家应该都不陌生.他们最大的区别就是MySQL为关系型数据库,而MongoDB为非关系型数据库.常见的关系型数据库有:MySQL.Oracle.DB2.SQL Server.Postgre SQL等,非关系型数据库有MongoDB.Redis.Memcached.HBse等等. 1.关系型数据库? 非关系型数据库? 关系型数据库可以理解为依赖一个模型来

【转】Mongodb亿级数据量的性能测试

进行了一下Mongodb亿级数据量的性能测试,分别测试如下几个项目: (所有插入都是单线程进行,所有读取都是多线程进行) 1) 普通插入性能 (插入的数据每条大约在1KB左右) 2) 批量插入性能 (使用的是官方C#客户端的InsertBatch),这个测的是批量插入性能能有多少提高 3) 安全插入功能 (确保插入成功,使用的是SafeMode.True开关),这个测的是安全插入性能会差多少 4) 查询一个索引后的数字列,返回10条记录(也就是10KB)的性能,这个测的是索引查询的性能 5) 查

mongodb 3.0 WT 引擎性能测试(转载)

网上转载来的测试,仅供参考.原文地址:http://www.mongoing.com/benchmark_3_0 本测试过程使用了2类机器. 测试均在单机器,单实例的情况下进行. 机器A(cache 12G,即内存>数据): 数据:{_id:默认,Name:"Edison",Num:随机数} 使用引擎:WiredTiger 索引:除了_id的索引外,Num字段也有索引. OS:centos6.5 64 Cpu:8核 E5 2407 2.4GHZ RAM:16G Disk:300G

MongoDB 3.2版WiredTiger存储引擎性能测试

MongoDB 3.2版WiredTiger存储引擎性能测试 作者:chszs,未经博主允许不得转载.经许可的转载需注明作者和博客主页:http://blog.csdn.net/chszs MongoDB 3.2于最近发布了,它使用WiredTiger作为其默认的存储引擎.这五年来,MongoDB从诞生到流行,发展可谓是相当迅猛. MongoDB 3.0就开始支持"可插拔的存储引擎"功能,因此在3.2版使用WiredTiger也在情理之中.WiredTiger引擎基于B-Tree算法,

Mongodb亿级数据量的性能测试

Mongodb亿级数据量的性能测试 ——转载 进行了一下Mongodb亿级数据量的性能测试,分别测试如下几个项目: (所有插入都是单线程进行,所有读取都是多线程进行) 1) 普通插入性能 (插入的数据每条大约在1KB左右) 2) 批量插入性能 (使用的是官方C#客户端的InsertBatch),这个测的是批量插入性能能有多少提高 3) 安全插入功能 (确保插入成功,使用的是SafeMode.True开关),这个测的是安全插入性能会差多少 4) 查询一个索引后的数字列,返回10条记录(也就是10K