MongoDB的真正性能

转载 2015年11月20日 15:28:53


最近开始研究MySQL和MongoDB,发现这方面资料不多。尤其是真正的说到点子上的文章,太少了。

有一些对比测试的文章基本上都是瞎测,测试方法都测到了马腿上,得出的结论基本上都是NoSQL毫无价值

容我借用Russell Smith 的那句话:不是MongoDB不行,是你不懂。

让我来分析一下MongoDB的真正性能吧。

有说MongoDB慢

  反对:不设其他唯一索引的情况下,只用_id 在普通办公电脑上每秒插入几万,在普通x86服务器上每秒插入十几万,你好意思说这个性能低?比mysql强出一个数量级。

      赞同:检索是真的慢,和sql数据库不同,越复杂的条件搜索MangoDB越吃亏,CPU和IO的双重压力。面对那些直接把SQL查询改写成MangoDB的用法,别转了,你不会收获任何性能提升。

      你不行:说你不行还是真的不行,MongoDB领导了NoSQL运动,NoSQL请注意,我们最主要反对的就是SQL的方法论,按SQL方法使用MangoDB你只能收获失望。再想想MongoDB的设计思想:文档化。_id 就是文件名,MongoDB是个文件系统。全文检索?别闹了,用文件名找文件,一个文件名对应一个文件,你绝对不会失望。

那么MongoDB究竟应该怎么用呢?

首先,忘记SQL

你应该忘记你学过的那些优雅无敌的SQL,不是说为了提升检索性能,扔索引就有好处。

有一个简单的事实如下:只有一个默认的_id 索引,此时插入性能为1,你再加一个索引,插入性能约1/2,再加一个约1/3 ,以此类推......

如果这个事实对你是很震撼的,那说明你还没有忘记SQL,接着忘。

MongoDB的索引对插入性能有着不可忽略的拖后腿效应,所以,我们应该使用且仅使用 _id 作为插入key,作为查询key,作为所有的那个key。

其次,直接忘记搜索这件事。

把MongoDB当做你的硬盘,给他文件名去操作文件.这就是Key-Value数据库的做法,你稍加设计就能这么用。

那么其实你所有的操作可以简化为两个指令,逻辑上 就是一个字典

你给他_id,往字典里插一个数据,或者拿一个数据。

Save({_id:xxx,.....})

FindOne({_id:xxx})

要想高性能,善用那个_id,把你原来准备当主键的那个玩意,hash成_id.

把你原来准备的查询条件,什么?查询,拿_id来,别的全砍掉。

第三、这不是数据表

记住,这不是数据表,一个_id对应的东西不是一行数据,而是一个文件。

文件存储和表存储有什么不同呢?

我举个例子,比如我们要存储用户列表和每个用户的道具列表。

数据表的做法是建一张用户表,一张道具表,道具表里有个字段表示他属于哪个用户。

然后,你就离不开万恶的查询了。

然后如果一个用户有100条道具,100万用户意味着道具表有一亿条记录。

这时候就开始考验你的小数据库了,但这都是过去式了,这一亿的道具,用MongoDB,根本不是个事儿

因为MongoDB的方法是当做文件存,只设计一个用户集合,每个用户的信息是一个文件,然后这100个道具就分开存在每个用户的文件里。

然后来比较一下,我们取得用户的记录,然后从中拿出100个道具,NoSQL方法。

查一亿的表,找出属于某个用户的记录。

熟快熟慢?

然后你可能回想,SQL方法,我也可以搞个道具字段,把用户的100个道具用某种协议打包,然后操作啊,一样可以取得巨大的优化呀。

没错,你的想法很好,你正在用NOSQL的方式用SQL。

第四、文件存储的精华之处

如果问题止于此处,MongoDB就毫无优势可言了,如果这个方法在SQL数据库上也是如此容易使用,那还费劲搞MongoDB干什么?

我们再折腾一点,如果每个道具还要存100条转手记录,你还是可以打包,但你这个打包字段已经1M了。

于是每次存取这个打包字段都是一个系统工程了,还要负担1M的流量。

MongoDB这边呢?我们可以直接对文件的一部分进行读写,比如我只返回一个用户的第二个道具的信息,和返回第二个道具的第1~30条转手记录。

这,是一种怎样的差距啊。

你想要一张美女的照片,你朋友有,但是他只有一个压缩包,他那里没有解包工具,于是他把整个包传给了你。他想问你要一张照片,但是他没有压缩工具,为了存档需要,他让你再压进包里传给他。

这个朋友就是你的用户表的一行,如果换成真实世界的事件是多么的不可思议,这就是在一个字段里打包数据的问题。

MongoDB的一条记录就是一个脑筋更正常的朋友,你要他一张照片,他从包里找出来给你。你给他一张照片,他分门别类的放置到他的包里去。

用文件的思维去访问,MongoDB是一个更好的朋友。

审视一下你项目中的大部分的数据需求,是不是都可以用这种方式去组织呢?

如果是,加入NOSQL吧,我们的口号是:很暴力不SQL

还有什么好处 

1.不用逻辑关心的水平切分

  无需多言,对MongoDB而言,这是运维人员的工作了

2.不用对齐的数据结构

  不用对齐意味着你不用为以前表结构变化的迁移烦恼,有些文件里有一个部分,有些没有,这对MongoDB而言,很正常。

MongoDB的真正性能

最近开始研究MySQL和MongoDB,发现这方面资料不多。尤其是真正的说到点子上的文章,太少了。 有一些对比测试的文章基本上都是瞎测,测试方法都测到了马腿上,得出的结论基本上都是NoSQL毫无...
  • sanshizi
  • sanshizi
  • 2014年05月12日 15:55
  • 301

MongoDB的真正性能

最近开始研究MySQL和MongoDB,发现这方面资料不多。尤其是真正的说到点子上的文章,太少了。 有一些对比测试的文章基本上都是瞎测,测试方法都测到了马腿上,得出的结论基本上都是NoSQL毫无...
  • july_2
  • july_2
  • 2014年03月27日 16:03
  • 509

MongoDB的真正性能

最近开始研究MySQL和MongoDB,发现这方面资料不多。尤其是真正的说到点子上的文章,太少了。 有一些对比测试的文章基本上都是瞎测,测试方法都测到了马腿上,得出的结论基本上都是NoSQL...
  • fstars
  • fstars
  • 2017年04月02日 19:56
  • 555

MongoDB的真正性能

原文:http://www.cnblogs.com/crazylights/archive/2013/05/08/3066056.html 最近开始研究MySQL和MongoDB,发...
  • k21325
  • k21325
  • 2016年11月21日 15:55
  • 209

MongoDB的真正性能

随笔 - 157  文章 - 2  评论 - 265 MongoDB的真正性能 最近开始研究MySQL和MongoDB,发现这方面资料不多。尤其...
  • linuxheik
  • linuxheik
  • 2016年08月29日 18:12
  • 1781

Mongodb亿级数据量的性能测试

进行了一下Mongodb亿级数据量的性能测试,分别测试如下几个项目: (所有插入都是单线程进行,所有读取都是多线程进行) 1) 普通插入性能 (插入的数据每条大约在1KB左右) 2) 批量插...
  • zrjdds
  • zrjdds
  • 2016年08月09日 09:48
  • 2662

mongodb读写性能分析

mongodb读写性能分析标签(空格分隔): Mongodb【写】可能影响插入数据性能评估:服务器硬件、索引(建立过多索引)、插入时是否指定_id、单机or分片、是否副本集、是否安全写入 数据库版本:...
  • zero1036
  • zero1036
  • 2017年04月13日 09:16
  • 1641

MongoDB与MySQL的插入、查询性能测试

1. 背景介绍 1.1  MongoDB的简单介绍 在当今的数据库市场上,MySQL无疑是占有一席之地的。作为一个开源的关系型数据库,MySQL被大量应用在各大网站后台中,承担着信息存储的重要作用...
  • clh604
  • clh604
  • 2014年02月21日 10:26
  • 45049

MongoDB 与 MySQL 性能测试分析

1、 I/O读写情况从插入情况下的TPS数据可以看出, MySQL、HandlerSocket和Mongodb的数据有比较明显的差别,这主要跟他们的内部实现和测试方式有关系。测试场景下MySQL采用的...
  • HeatDeath
  • HeatDeath
  • 2017年06月01日 15:34
  • 655

Mysql与MongoDB对比测试

测试环境:php5.2、mysql5.0、MongoDB2.0.6、xbug 测试脚本: Mysql测试脚本:
  • e421083458
  • e421083458
  • 2013年04月25日 13:53
  • 9823
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:MongoDB的真正性能
举报原因:
原因补充:

(最多只允许输入30个字)