MongoDB的真正性能

转载 2016年08月29日 18:12:53

MongoDB的真正性能

最近开始研究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 性能瓶颈分析

一、前情简介  半个月前,公司的MongoDB压力由于用户量暴增导致压力急剧增加,读写能力下降。  因为对于Mongos 的集群分片机制的了解和测试还不是很充分,所以开始使用最简单的办法来解决...

morphia操作mongodb对日期范围查询

1. mongodb中日期类型: 2. 命令行中,日期范围查询: 3.采用morphia操作日期查询:

Mongodb亿级数据量的性能测试

进行了一下Mongodb亿级数据量的性能测试,分别测试如下几个项目: (所有插入都是单线程进行,所有读取都是多线程进行) 1) 普通插入性能 (插入的数据每条大约在1KB左右) ...
  • joeyon
  • joeyon
  • 2015-07-23 12:54
  • 2059

Mongodb性能调优 -性能优化建议

摘要 1. MongoDB 适用场景简介 2. Mongodb 性能监控与分析 3. Mongodb 性能优化建议 关于Mongodb的几个大事件 1.根据美国数据库知识大全官网...

MongoDB中的日期查询命令的记录:大于、小于、等于、范围内、(mongoVUE 操作记录)

问题: 1,ISODate("2016-01-01T00:00:00Z"),这个是什么日期格式。 2,mongo vue的时间类型属性的相关查询。包括,大于某个时间,小于某个时间,在某一段时间范围。 ...

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

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

php非阻塞访问url 解析socket阻塞与非阻塞,同步与异步

php非阻塞访问url代码: function fsockopen_curl($hostname, $url){ $fp = fsockopen($hostname, 80, $e...

Mongodb VS Mysql 查询性能

Mongodb VS Mysql 查询性能 转自:http://www.wdcode.org/archives/452.html 最近想用 Mongodb 做些存储层的事情。目前主要用在 ...

MongoDB 性能优化:分析执行计划

前言cursor.explain("executionStats") 和 db.collection.explain("executionStats") 方法提供一个 查询的性能统计情况。这些数据输出...

生产环境部署MongoDB集群——性能优化

一、软件包选择 确保使用最新的稳定版本,确保生产环境总是使用64位版本。 二、操作系统选择 MongoDB支持Windows,Linux,MacOS和Solaris,建议生产环境部署在linux操作...
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:深度学习:神经网络中的前向传播和反向传播算法推导
举报原因:
原因补充:

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