Mongodb亿级数据量的性能测试
发表于 23:50|
来源博客园|
作者lovecindywang
摘要：进行了一下Mongodb亿级数据量的性能测试，分别测试如下几个项目： （所有插入都是单线程进行，所有读取都是多线程进行） 1） 普通插入性能 （插入的数据每条大约在1KB左右） 2） 批量插入
导读：近日，博客园作者lovecindywang撰写了一篇题为&Mongodb亿级数据量的性能测试&的文章，全文如下
Mongodb亿级数据量的性能测试，分别测试如下几个项目：
（所有插入都是单线程进行，所有读取都是多线程进行）
1） 普通插入性能 （插入的数据每条大约在1KB左右）
2） 批量插入性能 （使用的是官方C#客户端的InsertBatch），这个测的是批量插入性能能有多少提高
3） 安全插入功能 （确保插入成功，使用的是SafeMode.True开关），这个测的是安全插入性能会差多少
4） 查询一个索引后的数字列，返回10条记录（也就是10KB）的性能，这个测的是索引查询的性能
5） 查询两个索引后的数字列，返回10条记录（每条记录只返回20字节左右的2个小字段）的性能，这个测的是返回小数据量以及多一个查询条件对性能的影响
6） 查询一个索引后的数字列，按照另一个索引的日期字段排序（索引建立的时候是倒序，排序也是倒序），并且Skip100条记录后返回10条记录的性能，这个测的是Skip和Order对性能的影响
7） 查询100条记录（也就是100KB）的性能（没有排序，没有条件），这个测的是大数据量的查询结果对性能的影响
8） 统计随着测试的进行，总磁盘占用，索引磁盘占用以及数据磁盘占用的数量
并且每一种测试都使用单进程的Mongodb和同一台服务器开三个Mongodb进程作为Sharding（每一个进程大概只能用7GB左右的内存）两种方案
其实对于Sharding，虽然是一台机器放3个进程，但是在查询的时候每一个并行进程查询部分数据，再有运行于另外一个机器的mongos来汇总数据，理论上来说在某些情况下性能会有点提高
基于以上的种种假设，猜测某些情况性能会下降，某些情况性能会提高，那么来看一下最后的测试结果怎么样？
备注：测试的存储服务器是 E5620
@ 2.40GHz，24GB内存，CentOs操作系统，打压机器是E5504 @ 2.0GHz，4GB内存，Windows Server 2003操作系统，两者千兆网卡直连。
从这个测试可以看出，对于单进程的方式：
1） Mongodb的非安全插入方式，在一开始插入性能是非常高的，但是在达到了两千万条数据之后性能骤减，这个时候恰巧是服务器24G内存基本占满的时候（随着测试的进行mongodb不断占据内存，一直到操作系统的内存全部占满），也就是说Mongodb的内存映射方式，使得数据全部在内存中的时候速度飞快，当部分数据需要换出到磁盘上之后，性能下降很厉害。（这个性能其实也不算太差，因为我们对三个列的数据做了索引，即使在内存满了之后每秒也能插入2MB的数据，在一开始更是每秒插入25MB数据）
2） 对于批量插入功能，其实是一次提交一批数据，但是相比一次一条插入性能并没有提高多少，一来是因为网络带宽已经成为了瓶颈，二来我想写锁也会是一个原因。
3） 对于安全插入功能，相对来说比较稳定，不会波动很大，我想可能是因为安全插入是确保数据直接持久化到磁盘的，而不是插入内存就完事。
4） 对于一列条件的查询，性能一直比较稳定，别小看，每秒能有的查询次数，每次返回10KB，相当于每秒查询80MB数据，而且数据库记录是2亿之后还能维持这个水平，性能惊人。
5） 对于二列条件返回小数据的查询，总体上性能会比4）好一点，可能返回的数据量小对性能提高比较大，但是相对来说性能波动也厉害一点，可能多了一个条件就多了一个从磁盘换页的机会。
6） 对于一列数据外加Sort和Skip的查询，在数据量大了之后性能明显就变差了（此时是索引数据量超过内存大小的时候，不知道是否有联系），我猜想是Skip比较消耗性能，不过和4）相比性能也不是差距特别大。
7） 对于返回大数据的查询，一秒瓶颈也有800次左右，也就是80M数据，这就进一步说明了在有索引的情况下，顺序查询和按条件搜索性能是相差无几的，这个时候是IO和网络的瓶颈。
8） 在整个过程中索引占的数据量已经占到了总数据量的相当大比例，在达到1亿4千万数据量的时候，光索引就可以占据整个内存，此时查询性能还是非常高，插入性能也不算太差，mongodb的性能确实很牛。
那么在来看看Sharding模式有什么亮点：
1） 非安全插入和单进程的配置一样，在内存满了之后性能急剧下降。安全插入性能和单进程相比慢不少，但是非常稳定。
2） 对于一个条件和两个条件的查询，性能都比较稳定，但条件查询性能相当于单进程的一半，但是在多条件下有的时候甚至会比单进程高一点。我想这可能是某些时候数据块位于两个Sharding，这样Mongos会并行在两个Sharding查询，然后在把数据进行合并汇总，由于查询返回的数据量小，网络不太可能成为瓶颈了，使得Sharding才有出头的机会。
3） 对于Order和Skip的查询，Sharding方式的差距就出来了，我想主要性能损失可能在Order，因为我们并没有按照排序字段作为Sharding的Key，使用的是_id作为Key，这样排序就比较难进行。
4） 对于返回大数据量的查询，Sharding方式其实和单进程差距不是很大，我想数据的转发可能是一个性能损耗的原因（虽然mongos位于打压机本机，但是数据始终是转手了一次）。
5） 对于磁盘空间的占用，两者其实是差不多的，其中的一些差距可能是因为多个进程都会多分配一点空间，加起来有的时候会比单进程多占用点磁盘（而那些占用比单进程少的地方其实是开始的编码错误，把实际数据大小和磁盘文件占用大小搞错了）。
虽然在最后由于时间的关系，没有测到10亿级别的数据量，但是通过这些数据已经可以证明Mongodb的性能是多么强劲了。另外一个原因是，在很多时候可能数据只达到千万我们就会对库进行拆分，不会让一个库的索引非常庞大。在测试的过程中还发现几个问题需要值得注意：
1） 在数据量很大的情况下，对服务进行重启，那么服务启动的初始化阶段，虽然可以接受数据的查询和修改，但是此时性能很差，因为mongodb会不断把数据从磁盘换入内存，此时的IO压力非常大。
2） 在数据量很大的情况下，如果服务没有正常关闭，那么Mongodb启动修复数据库的时间非常可观，在1.8中退出的-dur貌似可以解决这个问题，我简单测试了一下，开启dur对插入和查询性能影响都不是很大。
3） 在使用Sharding的时候，Mongodb时不时会对数据拆分搬迁，这个时候性能下降很厉害，虽然从测试图中看不出（因为我每一次测试都会测试比较多的迭代次数），但是我在实际观察中可以发现，在搬迁数据的时候每秒插入性能可能会低到几百条。
4） 对于数据的插入，如果使用多线程并不会带来性能的提高，反而还会下降一点性能（并且可以在http接口上看到，有大量的线程处于等待）。
5） 在整个测试过程中，批量插入的时候遇到过几次连接被远程计算机关闭的错误，怀疑是有的时候Mongodb不稳定关闭了连接，或是官方的C#客户端有BUG，但是也仅仅是在数据量特别大的时候遇到几次。
原文链接：
推荐阅读相关主题：
网友评论有（0）
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章mongodb如何管理连接的?有必要实现连接池吗?? - 知乎55被浏览19225分享邀请回答/html/1838.html 61 条评论分享收藏感谢收起7添加评论分享收藏感谢收起查看更多回答代码-MongoDB 线程长连接问题
作者：用户
浏览：286 次
MongoDB线程长连接问题我在使用MongoDB的过程当中，遇到如下问题：我的MongoDB一直存在4个ESTABLISHED连接，一直未释放，即使任务已经执行完了。代码如下，其中Client只会在
MongoDB 线程长连接问题
我在使用MongoDB的过程当中，遇到如下问题：
我的MongoDB一直存在4个ESTABLISHED 连接，一直未释放，即使任务已经执行完了。
代码如下，其中Client只会在系统启动的时候初始化一次，当然在系统停止contextDestroyed的时候Client也调用了close：
public class ExportServer extends BasicMongoServer {
public final static Logger LOG = Logger.getLogger(ExportServer.class);
public static MongoClient mongoC
private static DB exportDB;
private static DBCollection exportC
初始化MongoDB Client
public static void init(String add,String username,String password) throws UnknownHostException {
ArrayList&ServerAddress& addr = new ArrayList&ServerAddress&();
for (String s : add.split(",")) {
addr.add(new ServerAddress(s.trim()));
if (addr.size() & 1) {
mongoClient = new MongoClient(addr, getOptions());
mongoClient = new MongoClient(add, getOptions());
mongoClient.setReadPreference(ReadPreference.secondaryPreferred());
exportDB = mongoClient.getDB("export");
exportDB.authenticate(username, password.toCharArray());
exportCollection = exportDB.getCollection("export");
if (exportCollection.getIndexInfo().size() == 0) {
("adding necessary indexes on export history collection");
BasicDBObject compoundIndex = new BasicDBObject();
compoundIndex.put("status", 1);
exportCollection.ensureIndex(compoundIndex);
compoundIndex.clear();
compoundIndex.put("key", 1);
exportCollection.ensureIndex(compoundIndex);
compoundIndex.clear();
compoundIndex.put("uid", 1);
exportCollection.ensureIndex(compoundIndex);
更新document
public static void update(DBObject query, DBObject update) {
exportCollection.update(query, update);
保存docuemnt
public static void save(DBObject obj) {
exportCollection.save(obj);
这些代码当中也没有什么特别操作，包括在应用停止的时候我也会将Client关闭
请问各位是否有任何建议或者解决思路。
用netstat -nlp等，查看一下对应的进程，然后就是对应的代码多看看是否有其他分支退出了，从而没有释放连接
【云栖快讯】浅析混合云和跨地域网络构建实践，分享高性能负载均衡设计，9月21日阿里云专家和你说说网络那些事儿，足不出户看直播，赶紧预约吧！&&
稳定可靠、可弹性伸缩的在线数据库服务，全球最受欢迎的开源数据库之一
6款热门基础云产品6个月免费体验；2款产品1年体验;1款产品2年体验
弹性可伸缩的计算服务，助您降低 IT 成本，提升运维效率
开发者常用软件，超百款实用软件一站式提供出处：http://coderbee.net 现状
业务部门反应网站访问特别慢，负责运维监控的同事说MQ消息队列积压了，中间件的说应用服务器内存占用很高，GC 一直回收不了内存，GC 线程占了近 100% 的 CPU，其他的基本上都在等待，数据库很正常，完全没压力。没啥办法，线程、堆 dump 出来后，重启吧，然后应用又正常了。
这种故障之前其实也碰到过了，分析了当时 dump 出来的堆后发现，处理 MQ 消息的线程池的队列长度达百万级别，占用了超过 1.3G
内存，这些内存都是没法回收的。
程序的实现目前是这样的：关联系统把消息推送到 MQ 上，我们再从 MQ 上拉消息下来处理；每种类型的消息都有一个线程负责从 MQ 上拉消息，拉下来后封装成线程池的任务提交给相应的线程池去执行。代码可以简化为：
package net.coderbee.mq.
import java.util.concurrent.ExecutorS
import java.util.concurrent.E
public class MQListener {
public ExecutorService executor = Executors.newFixedThreadPool(8);
public void onMessage(final Object message) {
executor.execute(new Runnable() {
public void run() {
// 耗时且复杂的消息处理逻辑
complicateHanlde(message);
private void complicateHanlde(Object message) {
这个实现就是导致故障的根源，
Executors.newFixedThreadPool(8) 创建的线程池的任务队列是无边界的：
public static ExecutorService newFixedThreadPool(int nThreads) {
return new ThreadPoolExecutor(nThreads, nThreads,
0L, TimeUnit.MILLISECONDS,
new LinkedBlockingQueue&Runnable&());
当时是关联系统出故障了，他们恢复后，往 MQ 里狂推消息，我们系统里面的 MQListener 不断地从 MQ 拉消息下来，直接塞进线程池里，由于线程池处理消息的速度远远慢于消息进入的速度，所以线程池的队列不断增长，直到把所有的堆内存都占用了，这时不断引发 FullGC，但每次 FullGC 都没法回收到内存，应用也就挂死在那了。
之前那次故障也是线程池队列积压导致的，引起的原因是消息处理逻辑调用了外部接口，由于外部接口的响应非常慢，严重拖慢了消息的处理进度，改成异步调用之后好了些。但问题的根源并没有解决，就像昨天关联系统狂推消息后，我们的系统还是挂了。
我的思路其实很简单，MQ 是用来系统间解耦的，也是一个缓冲，目前的实现是把处理消息的线程池又用作一个 MQ 了，消息不能不受控地进入线程池的任务队列，所以，要换成使用定长的阻塞队列，队列满了就暂停拉取消息。把线程池替换成：
private int nThreads = 8;
private int MAX_QUEUQ_SIZE = 2000;
private ExecutorService executor = new ThreadPoolExecutor(nThreads,
nThreads, 0L, TimeUnit.MILLISECONDS,
new ArrayBlockingQueue&Runnable&(MAX_QUEUQ_SIZE),
new ThreadPoolExecutor.CallerRunsPolicy());
把线程池队列满的时候直接让调用者（也就是
MQListener）执行任务，这样即延缓了消息拉取的速度，当
MQListener 再去拉取消息时，发现线程池有空间时可以提交到线程池，让线程池的工作线程去处理，它继续保持拉取速度。
这样既控制了线程池占用的内存，又可以让消息处理线程池处理不过来时多一个线程处理消息。
由于上面的代码采用调用者执行的方式，那么要考虑消息处理的顺序问题，比如一个订单的处理可能有多个步骤，对应多条 MQ 消息，那么要考虑这些步骤如果乱序了是否可以接受，因为第3步骤的处理消息可能被 MQListener 处理了，而第2步的处理消息还积压在线程池里。
相关 [线程 mq 消息] 推荐：
- 码蜂笔记
业务部门反应网站访问特别慢，负责运维监控的同事说MQ消息队列积压了，中间件的说应用服务器内存占用很高，GC 一直回收不了内存，GC 线程占了近 100% 的 CPU，其他的基本上都在等待，数据库很正常，完全没压力. 没啥办法，线程、堆 dump 出来后，重启吧，然后应用又正常了. 这种故障之前其实也碰到过了，分析了当时 dump 出来的堆后发现，处理 MQ 消息的线程池的队列长度达百万级别，占用了超过 1.3G
内存，这些内存都是没法回收的.
- 开源软件 - ITeye博客
本文主要讲解关于kafka mq的设计思想及个人理解. 关于kafka的详细信息，大家可以参考官网的文献
http://kafka.apache.org/documentation.html这是一篇相当不错的文章，值得仔细研读. 第一个问题：消息队列（Message Queue）是干嘛用的. 首先，要对消息队列有一个基本的理解.
- 企业架构 - ITeye博客
目前常用的消息队列组建无非就是MSMQ和ActiveMQ，至于他们的异同，这里不想做过多的比较. 简单来说，MSMQ内置于微软操作系统之中，在部署上包含一个隐性条件：Server需要是微软操作系统. （对于这点我并去调研过MSMQ是否可以部署在非微软系统，比如:Linux，只是拍脑袋想了想，感觉上是不可以）.
- 编程语言 - ITeye博客
本文实例是基于
WebSphere MQ中将消息发送至远程队列的配置的基础上的，且如果要能正常运行并发送、接收消息，还需要在两个队列管理器（QM_ORANGE和QM_APPLE）上做如下配置或修改.
1.创建名称为DC.SVRCONN的服务器连接通道.
2.将队列管理器的通道认证记录设置为“已禁用”.
- 行业应用 - ITeye博客
假设在IBM MQ中定义的队列管理器的名为QueueManager, 端口1414，CCSID 437 ，创建名为LQ1，LQ2的队列分别用于发送和接收消息， 服务器连接通道名为SVRCONN. 确保在项目的Classpath中导入了以下的jar包：. 如果需使用spring的JmsTemplate方式来读写MQ，还需要导入.
- 编程语言 - ITeye博客
2、定义队列缓冲池最大消息数，如果达到该值，那么队列检入将等待检出低于该值时继续进行. 3、定义检出线程，如果队列缓冲池没有消息，那么检出线程会线程等待中. if(size==0){
//队列缓存池没有消息，等待. if(isIpLock(queueStr)){//假若这个是一个多应用的分布式系统，那么这个判断应该是分布式锁，这里说的锁不是线程停止，而是跳过该消息，滞后处理.
- 藏书人 - 李志官方博客
1，经过深思熟虑，我放弃了十月份做个人小巡演的计划，全心全意投入跨年音乐会的准备工作. 如不出意外，12月31日南京见. 2，如果不出意外，第六张专辑会在十一之前发布. 经过深思熟虑，我决定不做实体，直接放到官网提供下载，能者多劳，愿者给钱. 3，当然对我而言，意外是常态.
- 水御龙神 - 1416 教室
每一个光鲜的封面，都饱含美术编辑的”血泪“和杂志主编的“阴谋”——今天的消息树让我们将掀开封面往里瞅瞅. 最新一期的美国新闻周刊封面，实在让人有点儿难以置信. 优雅的戴安娜王妃突然出现在二十一世纪的街头，旁边是她的儿媳妇Kate，但仔细看，她却不是当年的王妃，变老了，变丑了——这是新闻周刊编辑们想象中的一个五十岁的女人的样子.
坚持分享优质有趣的原创文章，并保留作者信息和版权声明，任何问题请联系：@。