集群的结构,大家可以查看我的另一遍文章, 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")
}
四个分片服务器,各自数据量和文件大小,一共 100 亿
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" } ) //哈希片键
搭建好了.
虽然选择了哈希片键,但是不知道为什么,还是出现热点服务器
七个分片服务器,只有这一台,比较忙,这台也是主分片.其它的分片的 CPU 和内存都闲的很啊.头痛.这又是为什么.
准备下班了,留模拟服务器,写一宿吧.明天使用 MapReduce 进行大数据分析.就不深入研究了,没有太多时间.
写了一宿,写了五亿条数据.
但是,不旦出现热点分片,还出出数据不平均的情况.热点分片储存达 2 亿条,其它分片储存 5 千万条
先查查,这是什么原因吧.终于查出原因,因为昨晚加入的三台测试服务器,有二台时间不同.所以出现这个问题.这个问题在集群搭建中也出现.
昨天我己同步过时间的了.不知道为什么,这二台真的差十几秒时间.可能昨晚眼花了.
时间完全同步之后.集群也恢复了正常.使用哈希片健之后,集群的七个分片都开始工作.CPU 和内存都占用.
只能把昨晚的五亿数据,全部删除,现在重新生成,大概 10 万 / 秒的速度.
网卡的工作效率,己达峰值,办公室的交换机,路由器都是百 M 级的,也就是 11M 左右的速度,就是峰值了.
虽然七台分片器的还是使用率不高.但是 mongos 的服务器网卡和交换机,路由器,的工作状态,已达峰值.在目前的情况,置换新设备的可能性,大概接近零.
先这样吧,连续写两个小时间,下午使用 MapReduce 进行大数据分析,性能估计看不出来了.因为下午,估计也就 1 亿条数据.
目前测试发现一个现象 mongos 网卡不到峰值,8-9M 的时候,工作最正常,各个分片,CPU 和内存都正常.一旦把 mongos 的网卡扛到峰值,虽然输入速度每秒提升了 2W 条.但是各个分片的 CPU 和内存,明显不按比例快速增长.
好吧,大概写了二到三个小时,写了 5 千万条.就这样测试吧
头痛,1000 条的分片服务器,条件查询要 11 秒.当然没有索引
在 mongos 上面,查询,看看性能如何吧, 一共 5 千万条.除了主健,都没有索引
find() 加上条件,响应还是很快的.
limit 的查询
sort 排序
直接就查不出来,换一个小数据的分片查查吧, 五百分的数据分片.这么就有 6 秒
行吧,又有正经事要办了.先笔记一下.以后再测吧.mongodb 大规模写入的性能还是可以的.查询的话,还是很慢.主要是搜索的数据体变大了.
来源: https://www.cnblogs.com/NET-BLOG/p/8242825.html