Mongodb百亿级数据添加，修改，删除，查询等性能测试【四】
2018-01-12 15:56
656 查看
集群的结构，大家可以查看我的另一遍文章，Mongodb的三种集群 在最后一种集群中，介绍到。
目前使用的数据就是最后一个测试集群，留下的数据。
简单介绍一下，四个分片的配置
mongos和conf服务器的配置也是差不多，就不贴出来了，不是很重要。
很遗憾的是，片健当初只选择了ID主健，当时一时冲动，没想好，这可能给查询给不方便。
首先，看看单条数据文档大小
四个分片服务器，各自数据量和文件大小，一共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秒，应该是缓存的原因。现在问题，我来加一个有条件的总行数查询。
这下就不行了吧，可以看到各个分片的CPU和内存都涨上去了。然后，查询界面一直转,出事了，整整过去了15分钟，还在转，这铁定是要出事了。
除了根据ID查询之外，只要加搜索条件，都卡到不行。到此为止，我不得，不删除这100亿条数据。因为数据过多，很多查询都要费很大的时间，甚至无法获取结果。
我们删除数据先写入小部分数据，比如10亿，进行数据分析。性能比较吧。
看来 “_Id” 并不是一件很好片健，在这个100亿的数据写入中，四个分片服务器，只要一个比较忙，原因就是片健 "_Id"（递增值）,使得集群出一个“热点” 分片，然后集群再通过均衡器（mongos）迁移到其它分片。
在这里，小小普及一下片健和工作原理。
片健的选取很关健，会直接影响集群的效率，并且很难再重选片健，特别是大数据。
相关资料我也懒得说，直接你们就去看文档我贴点资料给你们看
如何选取片健
我这里重新测试数据，就选择哈希片健吧，比较简单有效。就是查询的也是随机的，这样的话，效率会低。
具体怎么搭建，大伙参考头上的链接的文章。相比前一篇，这回测试服务器，又增加了三台。
搭建好了。
虽然选择了哈希片键，但是不知道为什么，还是出现热点服务器
七个分片服务器，只有这一台，比较忙，这台也是主分片。其它的分片的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大规模写入的性能还是可以的。查询的话，还是很慢。主要是搜索的数据体变大了。
目前使用的数据就是最后一个测试集群，留下的数据。
简单介绍一下，四个分片的配置
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大规模写入的性能还是可以的。查询的话，还是很慢。主要是搜索的数据体变大了。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- 通过loadrunner 11常规通用的C语言API类型的Vuser 方式，测试验证MySQL数据库插入、查询、修改、删除数据性能脚本实例
- 稳扎稳打Silverlight(58) - 4.0通信之WCF RIA Services: 通过 Domain Service, 以 MVVM 模式实现数据的添加、删除、修改和查询
- 通过 Domain Service, 以 MVVM 模式实现数据的添加、删除、修改和查询
- Oracle的学习二：表管理(数据类型、创建/修改表、添加/修改/删除数据、数据查询)
- 稳扎稳打Silverlight(58) - 4.0通信之WCF RIA Services: 通过 Domain Service, 以 MVVM 模式实现数据的添加、删除、修改和查询
- 用户名查询、手机号查询、选择城市、选择状态、选择月份、ID排序、添加数据、批量发货、批量删除、敏感字、修改数据）
- 稳扎稳打Silverlight(58) - 4.0通信之WCF RIA Services: 通过 Domain Service, 以 MVVM 模式实现数据的添加、删除、修改和查询
- 添加，查询，修改，删除测试方法及常见bug说明
- MongoDB与PHP的扩展进行添加、修改、查询、删除等操作基础教程
- Oracle的学习二：表管理(数据类型、创建/修改表、添加/修改/删除数据、数据查询)
- 测试Hibernate添加查询修改删除学生信息（一对多的关系）
- 稳扎稳打Silverlight(58) - 4.0通信之WCF RIA Services: 通过 Domain Service, 以 MVVM 模式实现数据的添加、删除、修改和查询
- MongoDB创建表步骤，Mongo常用的数据库操作命令，查询，添加，更新，删除_MongoDB 性能监测
- 稳扎稳打Silverlight(58) - 4.0通信之WCF RIA Services: 通过 Domain Service, 以 MVVM 模式实现数据的添加、删除、修改和查询
- MongoDB创建表步骤，Mongo常用的数据库操作命令，查询，添加，更新，删除_MongoDB 性能监测
- Silverlight 3 关于数据添加，删除，修改，条件查询的一点代码
- 稳扎稳打Silverlight(58) - 4.0通信之WCF RIA Services: 通过 Domain Service, 以 MVVM 模式实现数据的添加、删除、修改和查询
- 稳扎稳打Silverlight(58) - 4.0通信之WCF RIA Services: 通过 Domain Service, 以 MVVM 模式实现数据的添加、删除、修改和查询
- 稳扎稳打Silverlight(58) - 4.0通信之WCF RIA Services: 通过 Domain Service, 以 MVVM 模式实现数据的添加、删除、修改和查询
- 稳扎稳打Silverlight(58) - 4.0通信之WCF RIA Services: 通过 Domain Service, 以 MVVM 模式实现数据的添加、删除、修改和查询