终于等到你——MySQL 5.7与PostgreSQL 9.6的百万QPS大比拼 - 知乎


本站和网页 https://zhuanlan.zhihu.com/p/24992338 的作者无关,不对其内容负责。快照谨为网络故障时之索引,不代表被搜索网站的即时页面。

终于等到你——MySQL 5.7与PostgreSQL 9.6的百万QPS大比拼 - 知乎首发于破产码农无障碍写文章登录/注册终于等到你——MySQL 5.7与PostgreSQL 9.6的百万QPS大比拼破产码农《MySQL技术内幕》、《MySQL内核》作者352 人赞同了该文章MySQL与PG(PostgreSQL)谁的性能更强是一个很有意思的话题,知乎上的回答貌似都在说PG能将MySQL远远的甩在身后,甚至有些回答的同学还给出了性能测试的截图。就区区看到的回答来看,测试的方法基本都很业余。2015年做过MySQL与PostgreSQL的测试对比:MySQL PK PostgreSQL,不服,跑个分呗(第一季)但是由于后续测试服务器被借调,因此未能完成后续的测试。不过社区有人完成了这样的测试,而且找了MySQL与PG领域最为顶级的专家来进行调优,测试结果应该说非常具有公信力。需要说明的是,这个测试数据全部缓存在内存,测试服务器4 CPU、72Core、HT,一共144逻辑核。同学们可以将这个测试看成这两个数据库的最大性能,也可以观察这两个数据库在扩展性方面的对比。好了,不多说,直接放上MySQL 5.7 vs PostgreSQL 9.6的测试结果。测试采用sybench的测试模型,首先看根据主键进行查询的SELECT测试:图中MySQL-5.7 Dimitri表示官方MySQL数据库,MySQL-5.7 Sveta使用的是Percona MySQL 5.7.15版本。从上图来看MySQL 5.7对比官方版本PG 9.6在性能上要好非常多,QPS可达160万,PG 最高140万。在并发100个线程后,官方PG的性能下降比较明显。PG社区已定位问题所在,又是cache aligne所引发的,这个问题MySQL几年前已经发现,代码上也做了大量的优化。不过我们的程序员在开发时很少考虑这个问题,或许都对性能都不是很敏感。记得有一年网易校招的笔试题,我出了一题关于cache align的相关问题,可以说同学们几乎是全军覆没。pgxact-algin就是打上patch后的PG性能,貌似打上补丁后PG性能得到了极大的提示。最高QPS可以有170W(但官方目前还没整合该patch,需要在其他场景下对此patch做进一步验证)。整体来看,在打上patch后,PG与MySQL在主键SELECT上不分轩轾。对sysbench的RO(READ ONLY)测试来看,PG做的要比MySQL好,但是奇怪的是Percona版本比官方版本要差非常多。其实,这个测试结果有点出乎我的意料,因为range查询和ORDER BY这样的查询来看,索引组织表会更有优势。不过总体来看两者最大差距10%,基本还是一个水准,高并发下能达到100万QPS。在sysbench的RW(读写)场景下,官方MySQL 5.7表现出了最好的性能,领先PG的幅度较大,超过4万 TPS(72万QPS)。async和trx=2表示允许事务非持久话,在生产上使用的可能性较小。从最终测试来看,可以看出PG的性能并没有比MySQL好,在sysbench读写测试的场景下MySQL会更有优势。总体来看,两者在OLTP上的表现都非常棒,但MySQL在生态和互联网应用上的成熟度来看毫无疑问具有领导地位。可以发现关系型数据库在全内存下的表现单实例已能超过150W QPS,即使读写也能达到72W QPS。而环顾四周,Redis和Memcached这类纯内存KV数据库似乎都无法达到这个高度。这是可能是一个有意思的话题,未来缓存怎么选择?用Redis还是MySQL Memcahced Plugin呢?前端的缓存速度还不如RDBMS?分布式呢?一个分布式集群QPS 100W?说不定一台MySQL又可以搞定了呢?很多粉丝还没有养成阅读后点赞和转发的习惯,希望大家在阅读后顺便点赞与转发,以示鼓励!长期坚持原创真的很不容易,多次想放弃。坚持是一种信仰,专注是一种态度!编辑于 2017-01-23 12:07MySQLPostgreSQL数据库​赞同 352​​32 条评论​分享​喜欢​收藏​申请转载​文章被以下专栏收录破产码农《MySQL技术内幕》、《MySQL内核》作者