MongoDB4和MysSQL5.7的读/写和事务处理速度简单对比

系统环境: Ubuntu 18.04
数据库 MysSQL5.7/MongoDB4.0

插入的数据为随机生产,不重复.

MySQL使用的连接库是 sqlalchemy
MongoDB使用的连接库是pymongo

测试分三个部分

  1. 写入测试
  2. 查询测试
  3. 事务测试

MysSQL 5.7 VS MOngoDB 4.0

插入测试

表很简单.只有一个sn字符串的字段.和一个_id.
_id作为主键都是由数据库自行生成的.
mysql表使用的是InnoDB引擎.字符集utf-8
mysql和mongodb都使用批量插入的方法,插入2万条数据.
两者都是有连接池的.

mongodb (w0)分组插入2万条记录耗时 1.798202秒
mongodb (w1)分组插入2万条记录耗时 2.229613秒
mongodb (w:majority)分组插入2万条记录耗时 3.3718秒
mongodb (w1, j1)分组插入2万条记录耗时 3.332055秒
mongodb (w:majority, j1)分组插入2万条记录耗时 3.594414秒
mysql 分组插入2万条记录耗时 33.024626秒

对写测试结果稍微做一下说明:
w和j是mongodb的写关注选项.w0,w1....之类的分别代表写关注处于不同的模式(写关注可以理解为mongodb对写入数据的可靠用使用何种确认方式?).

  • mongodb w0模式 只要网络和硬件没故障,写函数没报错.就认为正确的写入了.这是性能损失最少的工作模式.早期的mongodb默认就是这种模式.这也给了某些人说mongodb会丢数据的口实.虽然这是使用者自己设置不当导致的.但至少这恶名是传开了.哈哈
  • mongodb w1模式 这是现在的mongodb的默认模式.会确认写函数正确返回才会认为是写入数据了.这种情况下.当系统处于失去响应的状态或者将要宕机时还是会丢失数据.不过这个模式已经很可靠了.
  • mongodb w:majority模式 当集群中的超过半数的主机写入函数都正确返回才会认为是写入数据了.
  • mongodb w1 j1模式 在w1的基础上, 还要确认日志完整写入了才会认为是写入数据了.会占用额外的空间.这是单机状态下最高的安全性了.可以认为这个写关注的程度基本上和mysql的正常工作模式类似.
  • mongodb w:majority, j1 当集群中的超过半数的主机写入函数都正确返回,并且日志都完整记录了.才认为是写入数据了.这是mongodb工作时的最高安全模式.一般认为这种模式只会在硬件故障时才有丢失数据的可能.
  • mysql 分组插入是批量插入的意思. 如果模拟实际中的单条数据插入.这个结果估计要后面加个0,还好.那不在本次测试范围之类.

插入测试结果:可以看到,我们即使让mongodb工作在和mysql类似的工作模式下.mongodb还是有着10倍左右的写入速度上的优势.这和其他人的测试结果基本吻合(mongodb的写入速度比mysql高一个数量级)

查询测试

查询测试使用的是同一张表:
表中只有一个字段sn. 没有索引.使用一个数据库不存在的sn进行条件查询以便让数据库遍历所有的记录.
测试的结果如下:

mongodb 1万次查询记录耗时 17.88544秒
mysql 1万次查询记录耗时 86.453012秒

可以看出来,查询的速度差别没写入那么大.(大约是5倍上下的速度差距)

事务测试

事务能力测试的需要至少2张表. 在对第一张表操作后,接着操作第二张表.操作过程中涉及的查询不使用索引.

mongodb 1000次事物操作耗时 5.91422秒
mysql 1000次事物操作耗时 42.471786秒

双方的事务操作速度大概是7倍的差距.

本来还是打算做一个连接(join)查询的测试.不过估计结果也不会有什么太大的改变.就是打住吧.

总结

目前来看,至少在速度上,MongoDB是让MySQL在后面吃灰. 功能上,以前没有的连接查询和事务都已经完美的支持了.如果是没有历史包袱的新项目的话,还是很推荐大家使用MongoDB的.

MysSQL 5.7 VS MOngoDB 4.0

  • 功能上,股让MongoDB提供的功能异常强大.瞅瞅MongoDB的API上那让人眼花缭乱的查询函数.各种函数的嵌套和组合.还有内置javascript支持(可以使用js函数组合出你想要的查询和过滤条件),aggregate和map-reduce.虽然提供了几乎你能想到的各种查询.不好的消息是学习成本跟MySQL相比大幅度上升.对于新手来说,那汗牛充栋的文档数量让人望而却步.学习成本比MySQL不是一星半点.
  • 速度上, 这个毋庸置疑.MongoDB在查询写入事务等方面的速度的那都是一骑绝尘.
  • 稳定性上,这几个测试根本无法对两者的稳定性上作出对比.不过以笔者20多年的工作经验来看,现在的MongoDB的稳定性满足商业运作已经完全没问题了.只是对于更多的人来说.MongoDB需要更多的时间来证明自己的稳定性不输自己的那些老前辈.
最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 214,837评论 6 496
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 91,551评论 3 389
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 160,417评论 0 350
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 57,448评论 1 288
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 66,524评论 6 386
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 50,554评论 1 293
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 39,569评论 3 414
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 38,316评论 0 270
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 44,766评论 1 307
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,077评论 2 330
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 39,240评论 1 343
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 34,912评论 5 338
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 40,560评论 3 322
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 31,176评论 0 21
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 32,425评论 1 268
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 47,114评论 2 366
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 44,114评论 2 352

推荐阅读更多精彩内容