测试MangoDB的真正性能

有说MongoDB慢

10年积累的做网站、成都做网站经验,可以快速应对客户对网站的新想法和需求。提供各种问题对应的解决方案。让选择我们的客户得到更好、更有力的网络服务。我虽然不认识你,你也不认识我。但先做网站后付款的网站建设流程,更有中卫免费网站建设让你可以放心的选择与我们合作。

反对:不设其他***索引的情况下,只用_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,往字典里插一个数据,或者拿一个数据。

 
 
 
  1. Save({_id:xxx,.....}) 
  2. 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而言,很正常。

原文链接:http://www.cnblogs.com/crazylights/archive/2013/05/08/3066056.html

【编辑推荐】

  1. Craigslist采用MongoDB替代MySQL
  2. MongoDB源码分析--Command体系架构
  3. Mongodb源码分析--内存文件映射(MMAP)
  4. 浅析Mongodb源码之游标Cursor
  5. 如何解决PHP+MySQL出现乱码的现象

【责任编辑: 彭凡 TEL:(010)68476606】

当前标题:测试MangoDB的真正性能
标题来源:http://www.mswzjz.com/qtweb/news2/166652.html

网站建设、网络推广公司-创新互联,是专注品牌与效果的网站制作,网络营销seo公司;服务项目有等

广告

声明:本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主,如果涉及侵权请尽快告知,我们将会在第一时间删除。文章观点不代表本网站立场,如需处理请联系客服。电话:028-86922220;邮箱:631063699@qq.com。内容未经允许不得转载,或转载时需注明来源: 创新互联