MongoDB数据库顺序读性能评估测试

    最近,公司一项目实施需要对MongoDB数据库的顺序读性能进行评估测试,已备项目实施提供决策依据。
    问题:主单对应的明细表关系,每一条主单在明细表中都有大量的明细存在,而明细单独以单个文档存储在mongodb中会因为key-value关系浪费大量的key值空间。
    解放方法:将明细表中的同一主单对应的明细压缩到一个文档中,提取冗余字段属性,将明细特有key-value组织成一个数组,这样数据相对集中,可以提高mongodb的顺序读性能。
    前提:主单对应的明细条数不能过多,压缩汇聚的明细总体积不能超过当前mongodb支持的单个文档的最大体积,具体看数据库配置,有的限制是16MB,有的32MB,有的是64MB;我们的库最大文档支持16MB。
    测试前准备:在同一个mongodb数据库中存放优化前的数据集合、优化后的数据集合,例如我们优化前的集合是bill_detail、优化后的集合是detail_coll。
    测试方法:测试方法如下表格所示


[mongodb@se122 test1]$ cat
bill_detail_ETL_Patient_IDStr1.sh

currentTime1=`date +%Y%m%d%H%M%S`

echo "start_time:" $currentTime1

mongo --port 27000 wl_insert
/home/mongodb/test1/bill_detail_ETL_Patient_IDStr1.js

currentTime2=`date +%Y%m%d%H%M%S`

echo "finish_time:" $currentTime2

time3=$(($currentTime2 - $currentTime1))

echo "execution time_elapsed:" $time3

[mongodb@se122 test1]$


[mongodb@se122 test1]$ cat
bill_detail_ETL_Patient_IDStr1.js

var cursor = db.ETL_Patient_IDStr.find();

var i=0;

while(cursor.hasNext()){

 var obj =
cursor.next();

 if(i<=1157){

 db.bill_detail.find({"ETL_Patient_IDStr":obj.ETL_Patient_IDStr}).explain("executionStats");

 }

 if(i>1157){

  break;

 }

 i++;

}

[mongodb@se122 test1]$

    测试方法说明:如表格所示,对优化前后的明细表各写四对sh和js脚本,其中每个sh单循环执行一次对应.js脚本,其中.js脚本对优化前后的集合分段执行从磁盘加载到mongo数据库内存的操作,四对sh和js脚本同时执行,将整个优化前或优化后的集合加载到服务器内存。测试前清理服务器内存及缓存,重启数据库,先测试优化后的文档detaill_coll;再清理服务器内存及缓存,重启数据库,后测试优化前的文档bill_detail。
    测试总览表格:


            对比

指标


优化前


优化后


对比度


期望


数据量


55357286


427003


7.70%


减少


集合并行加载时间


932s


432s


46.35%


降低


存储磁盘IO请求数峰值


3917/s


887/s


22.64%


降低


存储磁盘IO吞吐量峰值


15.88MB/s


19.38MB/s


22.04%


提高


mongo数据返回峰值


23.4KB/s


52.8KB/s


55.68%


提高


mongo消耗内存


52.4GB


36GB


31.30%


下降


mongo消耗缓存


66%


50%


16%


下降

    结合一款grafana软件,结果会更直观:
图4 优化后的读操作磁盘IO请求

图5优化前的读操作磁盘IO请求

针对图4、图5,相同查询操作测试下,优化前的物理磁盘IO请求数峰值是3917次/s,优化后的物理磁盘IO请求数峰值降低到887次/s,另外,可以看出,优化前查询操作导致磁盘IO请求居高不下。
图6 优化后的查询操作IO吞吐量

图7 优化前的查询操作IO吞吐量

针对图6、图7,相同查询操作测试下,优化前的物理磁盘IO吞吐量数峰值是15.88MB/s,优化后的物理磁盘IO请求数峰值提高到19.39MB/s,优化后顺序IO提高了磁盘IO读性能,相比优化前提高了3.5MB/s;另外,磁盘IO高峰期,优化后相比优化前在时间上有明显的缩短。
图8 优化后的mongo数据库数据返回

图9 优化前的mongo数据库数据返回

针对图8、图9,相同查询操作测试下,优化前mongo数据库数据返回数峰值是23.4kb/s,优化后的mongo数据库数据返回数峰值提升到52.8kb/s,优化后数据分布有利于数据库顺序读,明显提升了mongo数据库顺序读的性能,同时降低了mongo数据库高负载时间。
图10 优化后的mongo数据库占用主机内存

图11 优化前的mongo数据库占用主机内存

针对图10、图11,
从图10-图11,显示的数据可以看出,优化后相比优化前,mongo数据库占用的主机内存下降31.30%。
    以上图表数据,除了使用grafana软件,也可以使用linux操作系统命令获得。
    测试过程中,使用echo 1 > /proc/sys/vm/drop_caches命令来清空主机缓存,通过ps -ef|grep mongo来查找mongodb的数据库主进程,如下所示131351进程就是啦,使用kill -2 131351命令关闭数据库,再重启来清空数据库内存的占用。
[root@se122 ~]# ps -ef|grep mongo
mongodb   66833      1  5 Aug01 ?        13:48:42 mongos --configdb 10.117.130.121:27001 --logpath /home/mongodb/mongodata/logs/mongos.log --port 27000 --fork
root      72060  71965  0 10:58 pts/1    00:00:00 grep --color=auto mongo
root      75111  75073  0 Aug09 pts/7    00:00:00 su - mongodb
mongodb   75112  75111  0 Aug09 pts/7    00:00:00 -bash
root     107805      1  0 Aug08 ?        00:00:00 su - mongodb
mongodb  107806 107805  0 Aug08 ?        00:00:00 -bash
mongodb  107849 107806  0 Aug08 ?        00:00:01 mongo --port 27000
mongodb  131351      1  0 Aug08 ?        00:23:21 mongod --dbpath /home/mongodb/mongodata/rs1 --logpath /home/mongodb/mongodata/logs/rs1.log --port 27011 --directoryperdb --syncdelay 15 --fork
[root@se122 ~]# 
[root@se121 ~]#  iostat -txk 2  #使用该命令可以持续获得磁盘IO使用情况
Linux 3.10.0-327.10.1.el7.x86_64 (se121) 08/09/2016 _x86_64_ (32 CPU)
08/09/2016 10:03:01 AM
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.67    0.00    0.63    0.03    0.00   98.67

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.00   46.50   12.50  1170.00    98.25    42.99     0.18    3.03    3.83    0.04   0.56   3.30
dm-0              0.00     0.00   12.00   10.50   764.00    93.25    76.20     0.02    0.78    1.42    0.05   0.76   1.70
dm-1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
dm-2              0.00     0.00   35.00    2.00   412.00     5.00    22.54     0.16    4.34    4.59    0.00   0.45   1.65
dm-3              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

08/09/2016 10:03:03 AM
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.81    0.00    0.49    1.17    0.00   97.53

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     2.50  966.50   28.00  6724.00   138.75    13.80     1.28    1.29    1.33    0.00   0.93  92.95
dm-0              0.00     0.00  241.50   17.00  3672.00    79.00    29.02     0.38    1.46    1.56    0.00   1.30  33.70
dm-1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
dm-2              0.00     0.00  725.00   13.50  3048.00    59.75     8.42     0.91    1.23    1.25    0.00   1.22  90.20
dm-3              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

08/09/2016 10:03:05 AM
avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.30    0.00    0.23    0.09    0.00   99.37

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sda               0.00     0.00  809.00    2.50  3312.50     7.00     8.18     0.88    1.09    1.09    0.20   1.08  87.70
dm-0              0.00     0.00    4.50    0.50    18.50     2.00     8.20     0.01    1.10    1.22    0.00   0.60   0.30
dm-1              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
dm-2              0.00     0.00  804.50    2.00  3294.00     5.00     8.18     0.88    1.09    1.09    0.25   1.09  88.20
dm-3              0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00
[BEGIN] 2016/8/9 10:06:26
free -s 10 -m 10   #使用该命令可以持续获得主机内存、缓存的使用数据
              total        used        free      shared  buff/cache   available
Mem:         128662       15784      110015         137        2862      112370
Swap:          4095          28        4067

              total        used        free      shared  buff/cache   available
Mem:         128662       16595      109069         137        2998      111560
Swap:          4095          28        4067



              total        used        free      shared  buff/cache   available
Mem:         128662       49774       70199         137        8689       78381
Swap:          4095          28        4067
经过单位换算后,就可以完成测试总览表格了。
    总结,文档聚合优化,使得数据相对集中,有利于mongodb的顺序读,对于需要mongodb短时间内加载大量数据到内存或获取到应用服务器是有利的。
    声明:实验过程、结果及对mongodb认识,如果有不妥的地方,我接受批评指正。

时间: 2024-11-24 08:16:20

MongoDB数据库顺序读性能评估测试的相关文章

走向DBA[MSSQL篇] 从SQL语句的角度 提高数据库的访问性能

原文:走向DBA[MSSQL篇] 从SQL语句的角度 提高数据库的访问性能 最近公司来一个非常虎的dba  10几年的经验 这里就称之为蔡老师吧 在征得我们蔡老同意的前提下  我们来分享一下蔡老给我们带来的宝贵财富 欢迎其他的dba来拍砖  目录 1.什么是执行计划?执行计划是依赖于什么信息.2. 统一SQL语句的写法减少解析开销3. 减少SQL语句的嵌套4. 使用"临时表"暂存中间结果5. OLTP系统SQL语句必须采用绑定变量6. 倾斜字段的绑定变量窥测问题7. begin tra

MongoDB数据库中索引(index)详解_MongoDB

索引:特殊的数据结构,存储表的数据的一小部分以实现快速查询 优点: 1.大大减少了服务器需要扫描的数据量 2.索引可以帮助服务器避免排序或使用临时表 3.索引可以将随机io转换为顺序io 索引评估:三星(非常好) 一星:索引如果能将相关的记录放置到一起 二星:索引中数据的存储顺序与查找标准中顺序一致 三星:如果索引中包含查询中所需要的全部数据:(覆盖索引) DBA书:关系型数据库索引设计与优化 索引类别: 顺序索引 散列索引:将索引映射至散列桶上,映射是通过散列函数进行的 评估索引的标准: 访问

MongoDB数据库index索引的用法和作用

索引最大的作用就是提高query的查询性能,如果没有索引,mongodb需要scan整个collection的所有的documents,并筛选符合条件的document,如果有索引,那么query只需要遍历index中有限个索引条目即可,况且index中的条目是排序的,这对"order  by"操作也非常有利. 索引:特殊的数据结构,存储表的数据的一小部分以实现快速查询 优点: 1.大大减少了服务器需要扫描的数据量 2.索引可以帮助服务器避免排序或使用临时表 3.索引可以将随机io转换

基于C#的MongoDB数据库开发应用(4)--Redis的安装及使用

在前面介绍了三篇关于MongoDB数据库的开发使用文章,严格来讲这个不能归类于MongoDB数据库开发,不过Redis又有着和MongoDB数据库非常密切的关系,它们两者很接近,Redis主要是内存中的NoSQL数据库,用来提高性能的:MongoDB数据库则是文件中的NoSQL数据库,做数据序列号存储使用的,它们两者关系密切又有所区别.本篇主要介绍Redis的安装及使用,为后面Redis和MongoDB数据库的联合使用先铺下基础. 1.Redis基础及安装 Redis是一个开源的使用ANSI C

DRDS实例性能评估分析

一.DRDS实例性能评估分析目标 通常我们在分布式数据库选项过程中会对DRDS实例进行性能评估分析,我认为主要包含以下3个目的: 1.评估DRDS性能,判断DRDS是否满足预期的性能需求 2.获取DRDS性能容量及各负载条件下性能表现,为容量规划提供参考依据 3.定位诊断DRDS性能瓶颈及原因并调整优化   二.性能评估分析主要性能指标   1.资源指标: CPU 利用率:DRDS 服务节点的CPU资源平均利用率 网络输入流量:DRDS 服务节点的网络输入流量的总和 网络输出流量:DRDS 服务

MongoDB数据库介绍及安装

有很多Nosql的最新资讯 http://blog.nosqlfan.com/   MongoDB是一个高性能,开源,无模式的文档型数据库,是当前NoSql 数据库中比较热门的一种.它在许多场景下可用于替代传统的关系型数据库或键/值存储方式.Mongo使用C++开发.Mongo的官方网站地址是:http://www.mongodb.org/,读者可以在此获得更详细的信息. Java代码   小插曲:什么是NoSql?   NoSql,全称是 Not Only Sql,指的是非关系型的数据库.下一

SQL Server中多表连接时驱动顺序对性能的影响

原文:SQL Server中多表连接时驱动顺序对性能的影响   本文出处:http://www.cnblogs.com/wy123/p/7106861.html (保留出处并非什么原创作品权利,本人拙作还远远达不到,仅仅是为了链接到原文,因为后续对可能存在的一些错误进行修正或补充,无他)   最近在SQL Server中多次遇到开发人员提交过来的有性能问题的SQL,其表面的原因是表之间去的驱动顺序造成的性能问题,具体表现在(已排除其他因素影响的情况下),存储过程偶发性的执行时间超出预期,甚至在调

MongoDB · 特性分析 · 网络性能优化

从 C10K 说起 对于高性能即时通讯技术(或者说互联网编程)比较关注的开发者,对C10K问题(即单机1万个并发连接问题)应该都有所了解.『C10K』概念最早由 Dan Kegel 发布于其个人站点,即出自其经典的<The C10K problem>一文[1]. 于是FreeBSD推出了kqueue,Linux推出了epoll,Windows推出了IOCP.这些操作系统提供的功能就是为了解决C10K问题. 常用网络模型 方案 名称 接受连接 网络 IO 计算任务 1 thread-per-co

智能SQL优化工具--SQL Optimizer for SQL Server(帮助提升数据库应用程序性能,最大程度地自动优化你的SQL语句 )

原文:智能SQL优化工具--SQL Optimizer for SQL Server(帮助提升数据库应用程序性能,最大程度地自动优化你的SQL语句 ) SQL Optimizer for SQL Server 帮助提升数据库应用程序性能,最大程度地自动优化你的SQL语句   SQL Optimizer for SQL Server 让 SQL Server DBA或者T-SQL开发人员能够主动地识别潜在的SQL性能问题,通过扫描和分析SQL语句进行人工智能自动SQL优化.Dell SQL Opt