iCMS

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

好喜欢专业转载优质博客文章的地方哦~

集群的结构,大家可以查看我的另一遍文章,Mongodb的三种集群 在最后一种集群中,介绍到。

目前使用的数据就是最后一个测试集群,留下的数据。

简单介绍一下,四个分片的配置

192.168.99.6 双核 2G 500G(机械硬盘)

192.168.99.7 双核 4G 500G(机械硬盘)

192.168.99.8 双核 4G 500G(机械硬盘)

192.168.99.11 双核 4G 500G(机械硬盘)

mongos和conf服务器的配置也是差不多,就不贴出来了,不是很重要。

很遗憾的是,片健当初只选择了ID主健,当时一时冲动,没想好,这可能给查询给不方便。

首先,看看单条数据文档大小

{

"_id" : ObjectId("5a39d1541b5bd02374f0844a"),

"OrderNo" : "636493641800005836",

"ShipperID" : 8427,

"CarOwnerID" : 3625,

"SendProvince" : "福建省",

"SendCity" : "莆田市",

"DestProvince" : "福建省",

"DestCity" : "莆田市",

"TranPrice" : "1014",

"CancelStatus" : 3,

"Status" : 100,

"SettlementDate" : null,

"SettleTranPrice" : "2279",

"SafePrice" : "528",

"TotalPrice" : "6036",

"CarryPrice" : "845",

"CreateTime" : ISODate("2017-12-20T02:56:20.000Z")

}

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

四个分片服务器,各自数据量和文件大小,一共100亿

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

192.168.99.6 数量量:2603773123 数据库大小:158G 日志Log大小:67M

192.168.99.7 数量量:2602259209 数据库大小:158G日志Log大小:1.5G

192.168.99.8 数量量:2534980799 数据库大小:154G 日志Log大小:47G

192.168.99.11 数量量:2601317529 数据库大小:158G日志Log大小:68M

数据量四个分片,比较均衡,数据库大小差不多,就是这个日志,差距很大哎,我去下载来看看,都什么梗在内面。46G内网的速度10M/S,下载都要一个小时,不查看了

查询总行数,第一次查询大概花费7-9秒,第二次有缓存,只需0.039秒,应该是缓存的原因。现在问题,我来加一个有条件的总行数查询。

db.getCollection('Order').count({'Status':100})

这下就不行了吧,可以看到各个分片的CPU和内存都涨上去了。然后,查询界面一直转,出事了,整整过去了15分钟,还在转,这铁定是要出事了。

除了根据ID查询之外,只要加搜索条件,都卡到不行。到此为止,我不得,不删除这100亿条数据。因为数据过多,很多查询都要费很大的时间,甚至无法获取结果。

我们删除数据先写入小部分数据,比如10亿,进行数据分析。性能比较吧。

看来 “_Id”并不是一件很好片健,在这个100亿的数据写入中,四个分片服务器,只要一个比较忙,原因就是片健 "_Id"(递增值),使得集群出一个“热点”分片,然后集群再通过均衡器(mongos)迁移到其它分片。

在这里,小小普及一下片健和工作原理。

片健的选取很关健,会直接影响集群的效率,并且很难再重选片健,特别是大数据。

相关资料我也懒得说,直接你们就去看文档我贴点资料给你们看

如何选取片健

我这里重新测试数据,就选择哈希片健吧,比较简单有效。就是查询的也是随机的,这样的话,效率会低。

//模拟数据写入服务器

192.168.99.5

//mongos服务器

192.168.99.9

//分片服务器

192.168.99.6

192.168.99.7

192.168.99.8

192.168.99.10

192.168.99.11

192.168.99.15

192.168.99.16

//配置服务器

192.168.99.12

192.168.99.13

192.168.99.14

sh.shardCollection("shop.Order",{ _id : "hashed" } ) //哈希片键

具体怎么搭建,大伙参考头上的链接的文章。相比前一篇,这回测试服务器,又增加了三台。

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

搭建好了。

虽然选择了哈希片键,但是不知道为什么,还是出现热点服务器

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

七个分片服务器,只有这一台,比较忙,这台也是主分片。其它的分片的CPU和内存都闲的很啊。头痛。这又是为什么。

准备下班了,留模拟服务器,写一宿吧。明天使用MapReduce进行大数据分析。就不深入研究了,没有太多时间。

写了一宿,写了五亿条数据。

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

但是,不旦出现热点分片,还出出数据不平均的情况。热点分片储存达2亿条,其它分片储存5千万条

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

先查查,这是什么原因吧。终于查出原因,因为昨晚加入的三台测试服务器,有二台时间不同。所以出现这个问题。这个问题在集群搭建中也出现。

昨天我己同步过时间的了。不知道为什么,这二台真的差十几秒时间。可能昨晚眼花了。

时间完全同步之后。集群也恢复了正常。使用哈希片健之后,集群的七个分片都开始工作。CPU和内存都占用。

只能把昨晚的五亿数据,全部删除,现在重新生成,大概10万/秒的速度。

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

网卡的工作效率,己达峰值,办公室的交换机,路由器都是百M级的,也就是11M左右的速度,就是峰值了。

虽然七台分片器的还是使用率不高。但是mongos的服务器网卡和交换机,路由器,的工作状态,已达峰值。在目前的情况,置换新设备的可能性,大概接近零。

先这样吧,连续写两个小时间,下午使用MapReduce进行大数据分析,性能估计看不出来了。因为下午,估计也就1亿条数据。

目前测试发现一个现象mongos网卡不到峰值,8-9M的时候,工作最正常,各个分片,CPU和内存都正常。一旦把mongos的网卡扛到峰值,虽然输入速度每秒提升了2W条。但是各个分片的CPU和内存,明显不按比例快速增长。

好吧,大概写了二到三个小时,写了5千万条。就这样测试吧

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

头痛,1000条的分片服务器,条件查询要11秒。当然没有索引

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

在mongos上面,查询,看看性能如何吧,一共5千万条。除了主健,都没有索引

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

find()加上条件,响应还是很快的。

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

limit的查询

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

sort排序

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

直接就查不出来,换一个小数据的分片查查吧,五百分的数据分片。这么就有6秒

Mongodb百亿级数据添加,修改,删除,查询等性能测试【四】

行吧,又有正经事要办了。先笔记一下。以后再测吧。mongodb大规模写入的性能还是可以的。查询的话,还是很慢。主要是搜索的数据体变大了。

0

上一篇:

:下一篇

精彩评论

暂无评论...
验证码 换一张
取 消