“去IOE” 之 MySQL与PostgreSQL的抉择

2024-06-09 10:32

本文主要是介绍“去IOE” 之 MySQL与PostgreSQL的抉择,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!

前言

上周参加了2015年的中国数据库大会,差不多从第二届开始就每年都会北京参会,从最早的嘉宾到这次的会场主持人,也算见证了中国数据库大会的发展吧。记得最早的时候大会只有两天,分会场也比较小,而现在各种大会变为了三天,分会场也越来越细化,赞助商也从以前的出版社演变为各种高大上的软硬件公司,这是主办方的成功,也是整个数据库从业人员的骄傲。然而,这次会议讨论的最多的依然是去IOE问题,但是原来的主角从MySQL换成了PostgreSQL。在之前的去IOE之MySQL问答系列中,笔者其实已经回答过了这部分的问题,然而不可避免的收到了来自PostgreSQL阵营非善意的“攻击”,故展开这个话题,尽量做到职责内的公正,公平,公开。


PostgreSQL

PostgreSQL官方宣称的是:“The world’s most advanced open source database”。most advanced我不知道是怎么定义的,因为PosgreSQL还是传统B+树索引的数据库,在一些场景下,比如全插入场景,其还是会比其他一些数据库要来得差很多,比如TokuDB,MongoDB。撇开这部分的因素,不得不承认PostgreSQL是最为强大的开源数据库,但是Oracle依然才是最为强大的关系型数据库。PostgreSQL阵营一直标榜自己在优化器和Oracle可移植性方面的优势,我想这对比MySQL或许是成立的。然而,如果上述都成立的话,为什么PostgreSQL在装机量,流行度等指标上上远远地被后起之秀MySQL给超越了呢?全球前20大网站完全看不到PostgreSQL的身影呢?在写本篇文章的时候,我倏地想到了一个类似的问题,业界公认手机质量最好的Nokia,最终为什么会倒下?

PostgreSQL另一个痛点,我想很多人没有会意识到的,就是在在线事务(OLTP)方面的性能问题。PostgreSQL在功能方面或许是比较完整的,但是真的要进入到生产环节,看的不再是简单的功能,因为大部分用户都明白日常所使用的仅是数据库提供的20%功能。MySQL 5.7现在已经可以轻松达到50W QPS的性能,并支持通过NoSQL接口可以达到100W QPS,这是PostgreSQL为什么没有能在互联网时代站住脚跟的一个重要原因之一。在线事务对性能的要求之苛刻,是普通用户所无法感知的。

PostgreSQL最大的优势是在线分析的场景,因为其优化器对于Join的支持堪称全面,对于复杂查询有着良好的支持,从Oracle迁移到PostgreSQL的成本会比较低。基于PostgreSQL的GreenPlum也已经开源,因此PostgreSQL目前在这方便是较为领先的。


MySQL

MySQL数据库官方的口号是:“ The world’s most popular open source database.”。对比PostgreSQL,这句话简直无法攻击,并且MySQL官方的目标也一直是成为最为流行的数据库。通过互联网浪潮,移动互联的时代,MySQL是真的做到了。

MySQL的优势是开源与开放性架构,使其拥有有着各种分支版本与存储引擎可供选择。除了官方的InnoDB存储引擎,还有TokuDB,Infobright引擎可在特定场合下进行使用。也正是因为MySQL的开源与开放,使得大量的开发人员加入到了MySQL的环抱。MySQL是一个非常成功的开源项目,可能很多人忽略了这个重要的因素。

MySQL被Oracle收购后表现的越来越好,一方面是功能越来越与Oracle数据库接近,很多时候给我的感觉就是开源的Oracle数据库,另一个重要的改进就是bug越来越少,甚至很多遗留了有近10年的bug也已一一修复。官方这样严谨的态度,使得MySQL逐渐站稳了并开始蚕食一部分的企业市场,世界500强的选择就是最好的证明。

MySQL在性能与流行度上的优势我不想再做过多的笔墨,因为这是任何人都无法回避的事实。MySQL数据库之前被PostgreSQL阵营攻击就是优化器,对于多表JOIN的性能以及不支持Hash Join。然而,很多人没有意识到,MySQL已经在5.6版本支持了MRR(Multi-Range Read),ICP(Index Condition Pushdown),BKA(Batched Key Access )Join这些优化,多表的JOIN性能已经得到了很大幅度的提升。不能否则,MySQL依然不支持Hash Join,但是这些优化的引入已经使得MySQL的Join性能提升到了一个新台阶。同时,在在线分析的领域,用户真的不关心使用Hash Join可以5分钟出报表,而是用MySQL需要8分钟,这些时间完全是可以容忍的。然在在线事务领域,0.1的时间都是所不能容忍的。因此,本人在这里呼吁,尝试升级MySQL到5.6,5.7版本,而不要依然停留在5.1或者5.5版本

MySQL替换Oracle另一个被诟病的就是没有Oracle的透明网关(Transparent Gateway)功能,MySQL自带的Fedorate存储引擎支持MySQL数据库间的查询,不支持异构数据库之前的查询。然而,这个问题已经给MariaDB解决,用户只需要通过Connect存储引擎,就能达到类似Oracle透明网关的功能

另外,还有用户提出MySQL不支持分区的全局索引,物化视图等,其实这些都可以通过变通的方法实现,这在我的书籍《MySQL技术内幕:InnoDB存储引擎》与《MySQL技术内幕:SQL编程》都有提及,而且也在网易、淘宝这样的互联网公司使用。

即使官方的MySQL无法满足你的需求,但是用户依然有InfoBright与TokuDB存储引擎的选择。InfoBright是列存的数据库引擎,非常适用于在线分析领域,这点连PostgreSQL都无法进行匹敌。TokuDB是一种类似LSM数据结构的数据引擎,在大并发的插入生产环境下,其对比各种传统数据库都有着显著的优势,即使对比PostgreSQL与Oracle数据库本身。总之,MySQL能够在各种维度满足用户对于数据库的各种需求

PosgreSQL与MySQL对比,最为关键的是整个人才的储备。看看中国的互联网公司基本都已将MySQL数据库作为标配,而PostgreSQL甚至连备胎都无法入选。MySQL在互联网行业积累了大量的高可用架构,分布式架构与灾备经验,但是PostgreSQL几乎为0。再看看图书市场,PostgreSQL凤毛菱角,而MySQL则有很好的书籍供DBA,开发人员,架构师等学习。然即使如此,MySQL离Oracle数据库本身的积累还有很长的路要走。


去IOE

去IOE最早是由淘宝提出,旨在去除IT架构中的IBM小型机,Oracle数据库,EMC存储。去IE是比较简单的事情,因为这仅是硬件的替换。另外,X86技术也越来越成熟,稳定性与小机的差距不断缩小。然而去Oracle数据库才是淘宝去IOE的难点与精华所在。整个去Oracle历时3,4年的时间。其中伴随着功能内部工程师的质疑,大量Oracle人才的流失,但最终已经证明了MySQL数据库替代Oracle的可行性。

笔者高兴的是传统企业也开始有这样的“觉悟”开始逐步进行去IOE的尝试,不管这种尝试是主动还是被动,但都是值得尊敬的行为。原因在于去Oracle数据库这件事情并不那么简单。数据库是传统企业最为核心的资产,任何损失都是不可接受的。而去年银监会的39号文件也坚定了传统企业的去IOE决心。

去IOE风潮显现,一大帮的公司开始进入到这个领域,希望借助这阵风来大赚一笔。这点本无可非议,市场与技术相辅相成。然而,有一个非常不好的现象是,很多公司是为了迎合某些领导的需要,而不是真正的为传统企业构建面向互联网+的安全可控的技术架构。而这其中有着一些不为人知的因素。

首当其冲的是领导们的绩效,传统企业做事,以绩效为导向,这与互联网行业并无不同。但是互联网行业有着技术积累,而且对于技术的选型与转型有着相当的耐心,从淘宝去Oracle用了3,4年就可以看出。而目前摆在传统企业领导面前的现实却是,39号文件要求各银行业金融机构对安全可控信息技术的应用以不低于15%的比例逐年增加,直至2019年达到不低于75%的总体占比。

遇到一些传统企业的朋友,领导要求他们用PostgreSQL替换Oracle数据库,原因在于这是“最快”的替换Oracle成本,但是他们站在IT从业人员的角度来看这件事是不对的,有种敢怒不敢言。当然,这其中也有部分商业公司在其中推动的关系。但是明白人心里都知道,PostgreSQL国内从业人员寥寥,之前在中国没有大规模的使用经验与架构设计,大多停留在找个文档折腾下的水平上。所谓“最快”的替换方案仅是因为不用进行存储过程的移植,如果只是这样使用PostgreSQL,那么仅是应付上层的文件,而没有真正领会到文件的精神。更有商业公司号称有PostgreSQL的专家,然而非常经不起推敲,玩过GreenPlum的就是PostgreSQL专家?而且GreenPlum也仅做研究性质的用途?与专家交流后发现其对锁与并发,高可用这块的掌握更是让人触目惊心。

所以笔者一再和身边的朋友说,去IOE不是一件一蹴而就的事情,需要给MySQL时间,否则这件好事情会像着另一个方向而发展,甚至重复当年年Sybase替换Oracle的事件发生。但是好消息是这次的领导们终于开始认识到互联网的重要性,理解了安全可控对于一个国家的重要性,而互联网公司的成熟经验具有很好的借鉴意义。


总结

MySQL数据库早已不是原来的迷你数据库,其在功能性与性能方面都已经大幅提升,随着SSD的崛起,MySQL数据库已经完全可以替换Oracle数据,而PostgreSQL还需要很长的路要走。但市场是开放的,就像Oracle称雄的年代,还有DB2,Sybase这样的数据库与之一较长短。我相信互联网时代,依然是百花齐放的年代,没有谁可以一直占领优势,即便是MySQL也没有这个能力。

这篇关于“去IOE” 之 MySQL与PostgreSQL的抉择的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!



http://www.chinasem.cn/article/1044925

相关文章

最详细安装 PostgreSQL方法及常见问题解决

《最详细安装PostgreSQL方法及常见问题解决》:本文主要介绍最详细安装PostgreSQL方法及常见问题解决,介绍了在Windows系统上安装PostgreSQL及Linux系统上安装Po... 目录一、在 Windows 系统上安装 PostgreSQL1. 下载 PostgreSQL 安装包2.

SQL中redo log 刷⼊磁盘的常见方法

《SQL中redolog刷⼊磁盘的常见方法》本文主要介绍了SQL中redolog刷⼊磁盘的常见方法,将redolog刷入磁盘的方法确保了数据的持久性和一致性,下面就来具体介绍一下,感兴趣的可以了解... 目录Redo Log 刷入磁盘的方法Redo Log 刷入磁盘的过程代码示例(伪代码)在数据库系统中,r

mysql中的group by高级用法

《mysql中的groupby高级用法》MySQL中的GROUPBY是数据聚合分析的核心功能,主要用于将结果集按指定列分组,并结合聚合函数进行统计计算,下面给大家介绍mysql中的groupby用法... 目录一、基本语法与核心功能二、基础用法示例1. 单列分组统计2. 多列组合分组3. 与WHERE结合使

Mysql用户授权(GRANT)语法及示例解读

《Mysql用户授权(GRANT)语法及示例解读》:本文主要介绍Mysql用户授权(GRANT)语法及示例,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录mysql用户授权(GRANT)语法授予用户权限语法GRANT语句中的<权限类型>的使用WITH GRANT

Mysql如何解决死锁问题

《Mysql如何解决死锁问题》:本文主要介绍Mysql如何解决死锁问题,具有很好的参考价值,希望对大家有所帮助,如有错误或未考虑完全的地方,望不吝赐教... 目录【一】mysql中锁分类和加锁情况【1】按锁的粒度分类全局锁表级锁行级锁【2】按锁的模式分类【二】加锁方式的影响因素【三】Mysql的死锁情况【1

SQL BETWEEN 的常见用法小结

《SQLBETWEEN的常见用法小结》BETWEEN操作符是SQL中非常有用的工具,它允许你快速选取某个范围内的值,本文给大家介绍SQLBETWEEN的常见用法,感兴趣的朋友一起看看吧... 在SQL中,BETWEEN是一个操作符,用于选取介于两个值之间的数据。它包含这两个边界值。BETWEEN操作符常用

MySQL索引的优化之LIKE模糊查询功能实现

《MySQL索引的优化之LIKE模糊查询功能实现》:本文主要介绍MySQL索引的优化之LIKE模糊查询功能实现,本文通过示例代码给大家介绍的非常详细,感兴趣的朋友一起看看吧... 目录一、前缀匹配优化二、后缀匹配优化三、中间匹配优化四、覆盖索引优化五、减少查询范围六、避免通配符开头七、使用外部搜索引擎八、分

MySql match against工具详细用法

《MySqlmatchagainst工具详细用法》在MySQL中,MATCH……AGAINST是全文索引(Full-Textindex)的查询语法,它允许你对文本进行高效的全文搜素,支持自然语言搜... 目录一、全文索引的基本概念二、创建全文索引三、自然语言搜索四、布尔搜索五、相关性排序六、全文索引的限制七

数据库面试必备之MySQL中的乐观锁与悲观锁

《数据库面试必备之MySQL中的乐观锁与悲观锁》:本文主要介绍数据库面试必备之MySQL中乐观锁与悲观锁的相关资料,乐观锁适用于读多写少的场景,通过版本号检查避免冲突,而悲观锁适用于写多读少且对数... 目录一、引言二、乐观锁(一)原理(二)应用场景(三)示例代码三、悲观锁(一)原理(二)应用场景(三)示例

SQL表间关联查询实例详解

《SQL表间关联查询实例详解》本文主要讲解SQL语句中常用的表间关联查询方式,包括:左连接(leftjoin)、右连接(rightjoin)、全连接(fulljoin)、内连接(innerjoin)、... 目录简介样例准备左外连接右外连接全外连接内连接交叉连接自然连接简介本文主要讲解SQL语句中常用的表