系统环境: Ubuntu 18.04
数据库 MysSQL5.7/MongoDB4.0
插入的数据为随机生产,不重复.
MySQL使用的连接库是 sqlalchemy
MongoDB使用的连接库是pymongo
测试分三个部分
- 写入测试
- 查询测试
- 事务测试
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需要更多的时间来证明自己的稳定性不输自己的那些老前辈.