mongoDB vs mysql 性能对比测试

测试环境:

  型号名称：    iMac
  处理器名称：    Intel Core 2 Duo
  处理器速度：    3.06 GHz
  处理器数量：    1
  总核心数：    2
  L2 高速缓存：    3 MB
  内存：    4 GB
  总线速度：    1.07 GHz

测试方案：

js脚本向mongo向一个collection里插入一百万个文档

用mongo的ruby driver做CRDU操作

ruby脚本向mysql的表插入100万条记录

用AR做CRDU操作

 

测试AR的CRDU与mongo ruby driver的CRDU性能

 

测试结果：

 

mysql vs mongo

                                                      |      AR |   MONGO
---------------------------------------------------------------------------
Model.create                                     x1000 |   1.235 |  0.337
Resource#update                                  x1000 |   0.765 |  0.079
Resource#destroy                                   x10 |   0.009 |  0.00074

Model.first                                      x1000 |   0.279 |  0.223

Model.find(id)                                   x1000 |   0.240 |  0.304
Model.find not use index                           x10 |   6.359 |  5.04
Model.find not use index                              x10 |  18.952 |  10.479  ( mysql:big field, mongo:find sub-doc)           

 

结果分析：

 

虽然mysql记录与mongo的文档不是完全一致的，但在同一水平上。

 

1. 基本查找：找first与通过id查找，两者差不多

 

2. 无索引查找：mongo要比mysql快一点 。最后一行数据是指mysql有大字段，而mongo则对子文档字段作查找。

 

3. create, update, destroy, mongo基本要比mysql快一个数量级 。

 

测试脚本见附件

 

评论

16 楼 forchenyun 2011-04-17  

百万级别，mysql不是问题，建议你可以看看mongo的亿级别数据量测试：
http://blog.nosqlfan.com/html/1388.html
一般来说，IO密集型应用，缓存命中率是性能的唯一评测点

15 楼 calvinlyc 2011-04-14  

..........2个完全不同的东西，去比他干什么呢

14 楼 pingfeng 2011-04-13  

Saito 写道

From Mississippi 写道

    The three operations that this chapter focused on (inserts, removes, and updates) seem
instantaneous because none of them waits for a database response. They are not asyn-
chronous; they can be thought of as “fire-and-forget” functions: the client sends the
documents to the server and immediately continues. The client never receives an “OK,
got that” or a “not OK, could you send that again?” response.
    The benefit to this is that the speed at which you can perform these operations is terrific.
You are often only limited by the speed at which your client can send them and the
speed of your network. This works well most of the time; however, sometimes some-
thing goes wrong: a server crashes, a rat chews through a network cable, or a data center
is in a flood zone. If the server disappears, the client will happily send some writes to
a server that isn’t there, entirely unaware of its absence. For some applications, this is
acceptable. Losing a couple of seconds of log messages, user clicks, or analytics in a
hardware failure is not the end of the world. For others, this is not the behavior the
programmer wants (payment-processing systems spring to mind).

Mongodb CUD上快是肯定且有代价的.
或许你可以在safe mode上再跟mysql"平等"的测试一下.
Mongodb1.8 release的Journaling对引用后段的问题会有所帮助,不过怀疑会降低些许Mongodb的性能.没测试过.

确实，在产品开发中打开了安全模式。如用mongoid的save也没有发现成功和失败的返回。
有时间再测一下安全模式。

13 楼 pingfeng 2011-04-13  

rocy 写道

js 和 ruby 两种语言也不在一个量级上啊..
都用ruby来做麻烦么?

是都是用ruby来写，只是100万个文档生成的时候用js做的。

“js脚本向mongo向一个collection里插入一百万个文档

用mongo的ruby driver做CRDU操作

ruby脚本向mysql的表插入100万条记录

用AR做CRDU操作”

12 楼 pingfeng 2011-04-13  

yongdi2 写道

学习下。lz是华为的吧，看工牌带子

参加QCon会议的带子，不是华为的带子，呵呵

11 楼 skzr.org 2011-04-12  

freish 写道

一个用ruby，一个用js，外部环境都不同，还谈何比较！

是阿,没有想象中的快

10 楼 Saito 2011-04-12  

From Mississippi 写道

    The three operations that this chapter focused on (inserts, removes, and updates) seem
instantaneous because none of them waits for a database response. They are not asyn-
chronous; they can be thought of as “fire-and-forget” functions: the client sends the
documents to the server and immediately continues. The client never receives an “OK,
got that” or a “not OK, could you send that again?” response.
    The benefit to this is that the speed at which you can perform these operations is terrific.
You are often only limited by the speed at which your client can send them and the
speed of your network. This works well most of the time; however, sometimes some-
thing goes wrong: a server crashes, a rat chews through a network cable, or a data center
is in a flood zone. If the server disappears, the client will happily send some writes to
a server that isn’t there, entirely unaware of its absence. For some applications, this is
acceptable. Losing a couple of seconds of log messages, user clicks, or analytics in a
hardware failure is not the end of the world. For others, this is not the behavior the
programmer wants (payment-processing systems spring to mind).

Mongodb CUD上快是肯定且有代价的.
或许你可以在safe mode上再跟mysql"平等"的测试一下.
Mongodb1.8 release的Journaling对引用后段的问题会有所帮助,不过怀疑会降低些许Mongodb的性能.没测试过.

9 楼 freish 2011-04-12  

一个用ruby，一个用js，外部环境都不同，还谈何比较！

8 楼 orcl_zhang 2011-04-12  

引用

不能直接拿这两者性能吧，他们的定位都不同。mysql是关系型数据训，而mongodb是基于文档的。


后者对关系型数据支持不好，而且没有事务机制，而mongo擅长存储日志，系统动态等没有什么关联，且不太重要的信息。

不知道，有没有用mogodb，和mysql的混合数据库的经验分享下，有的话透露下，我想尝试下。还有mogodb有木有db缓存？或者这方面的插件之类的。

7 楼 rocy 2011-04-11  

js 和 ruby 两种语言也不在一个量级上啊..
都用ruby来做麻烦么?

6 楼 dxm1986 2011-04-11  

<div class="quote_title">pingfeng 写道</div>
<div class="quote_div">
<p><span style="font-size: medium;">测试环境:</span>
<br><br>
  型号名称：    iMac<br>
  处理器名称：    Intel Core 2 Duo<br>
  处理器速度：    3.06 GHz<br>
  处理器数量：    1<br>
  总核心数：    2<br>
  L2 高速缓存：    3 MB<br>
  内存：    4 GB<br>
  总线速度：    1.07 GHz<br><br><span style="font-size: medium;">测试方案：</span>
<br><br>
用js脚本向mongo向一个collection里插入一百万个文档</p>
<p>用ruby脚本向mysql的表插入100万条记录</p>
<p> </p>
<p>测试AR的CRDU与mongo ruby driver的CRDU性能</p>
<p> </p>
<p><span style="font-size: medium;">测试结果：</span>
</p>
<p> </p>
<p>mysql vs mongo<br><br>
                                                      |      AR |   MONGO<br>
---------------------------------------------------------------------------<br>
Model.create                                     x1000 |   1.235 |  0.337<br>
Resource#update                                  x1000 |   0.765 |  0.079<br>
Resource#destroy                                   x10 |   0.009 |  0.00074</p>
<p>Model.first                                      x1000 |   0.279 |  0.223</p>
<p>Model.find(id)                                   x1000 |   0.240 |  0.304<br>
Model.find not use index                           x10 |   6.359 |  5.04<br>
Model.find not use index                              x10 |  18.952 |  10.479  ( mysql:big field, mongo:find sub-doc)            </p>
<p> </p>
<p><span style="font-size: medium;">结果分析：</span>
</p>
<p> </p>
<p>虽然mysql记录与mongo的文档不是完全一致的，但在同一水平上。</p>
<p> </p>
<p>1. 基本查找：找first与通过id查找，<span style="color: #0000ff;">两者差不多</span>
</p>
<p> </p>
<p>2. <span style="color: #0000ff;">无索引查找：mongo要比mysql快一点</span>
。最后一行数据是指mysql有大字段，而mongo则对子文档字段作查找。</p>
<p> </p>
<p>3. create, update, destroy, <span style="color: #0000ff;">mongo基本要比mysql快一个数量级</span>
。</p>
<p> </p>
<p>测试脚本见附件</p>
<p> </p>
</div>
<p>不能直接拿这两者性能吧，他们的定位都不同。mysql是关系型数据训，而mongodb是基于文档的。</p>
<p> </p>
<p>后者对关系型数据支持不好，而且没有事务机制，而mongo擅长存储日志，系统动态等没有什么关联，且不太重要的信息。</p>

5 楼 yongdi2 2011-04-11  

学习下。lz是华为的吧，看工牌带子

4 楼 tcray 2011-04-11  

云中苍月 写道

tcray 写道

nosql快倒是快啊 但是目前阶段还是无法取代关系数据库啊 复杂的查询就是nosql的一个软肋

应用场景不同用不同的产品，用了nosql就别考虑复杂查询，单一产品不可能完美。

同意  看看自己的东西更注重哪个方面吧  没有完美的东西

3 楼 油炸大龙虾 2011-04-11  

个人认为还是比较一下集群以后的效率才有意义。
复杂查询是设计的问题，mongo无视

2 楼 云中苍月 2011-04-11  

tcray 写道

nosql快倒是快啊 但是目前阶段还是无法取代关系数据库啊 复杂的查询就是nosql的一个软肋

应用场景不同用不同的产品，用了nosql就别考虑复杂查询，单一产品不可能完美。

1 楼 tcray 2011-04-11  

nosql快倒是快啊 但是目前阶段还是无法取代关系数据库啊 复杂的查询就是nosql的一个软肋