为何在国内MySQL成为主流,PG只能屈居二线?

知乎 2024-03-11 11:24:00
最近,小编在知乎上看到这样一个问题:

 

 
 

PostgreSQL也很强大,为何在中国大陆MySQL成为主流,PostgreSQL屈居二线呢?

 
 

 

PostgreSQL能否替代MySQL?我感觉PostgreSQL非常强大,很多地方超过了MySQL。

 

举几个例子:

1.丰富的数据类,支持数组、字典、json、序列号

2.强大的审计函数

3.强大的索引,易于sql调优

 

PostgreSQL在许多地方,有MySQL无法比拟的优势。但是在中国大陆,许多公司的核心业务库,都是MySQL,PostgreSQL则屈居二线,作为审计类的数据库来使用。

 

为什么不让PostgreSQL来扛大梁呢,而要用MySQL,PostgreSQL不合适么?

 

MySQL和PostgreSQL在功能上各有千秋,为什么没能在业界中形成“平分天下”的局面呢?小编精选了几位知乎网友的精彩回答,分享给大家学习交流(仁者见仁,智者见智,勿引战~)

 

 
 
 
1号知乎网友:大宽宽
 
 
 

 

 

以下均为个人感觉,没做过统计,就当个参考吧。

 
MySQL和Postgres的早期完全是两个极端。MySQL更像是个“基本上满足关系数据库语法的大号KV”,对关系型数据库的高级功能支持得很不好。我入行时接触的MySQL 5.1和MyISAM存储引擎,不支持ACID,但有如下几点在当时的互联网公司看来是非常合适:
 
1. 互联网公司为了扩展,长期的经验是,仅仅把数据库当作是一个“存储”,而非存储+核心数据逻辑的计算节点。大量的计算都在业务服务器上进行,而业务服务器可以无限水平扩展,无需担心有状态的数据迁移问题;
 
2. 因为没有提供很多高级功能和数据一致性的保障,MySQL对于简单的sql支持的反而更加直接,在速度上有很大的优势
 
3. 对于OLTP,完全不需要复杂的数据处理功能。简单的select ... from ... where id = xxx; insert into xxx;update xxx set xxx=xxx where id = xxxx是OLTP的主流功能。基于这些功能的ORM的出现大大提高了生产效率;对于OLAP,尽管Postgres查询分析功能很强,但是一般互联网公司的数据量实在太大,用Postgres这种数据库根本无法处理。通常会用MapReduce、Hive、Pig等大数据处理工具来分析;
 
4. 多线程模型,天然对高并发支持良好。而pg一直是多进程模型。进程的创建会更慢,更耗内存。虽然有些PG的连接池方案,但是MySQL在这方面“开箱即用”;
 
5. Postgres早期并不支持“逻辑复制”。物理复制意味着存储格式的细节完全暴露,不兼容的版本无法直接组成主从同步,于是无法做滚动升级。这就意味着在升级数据库时,必须停服,把整个集群升级后再恢复。而MySQL从一开始就是逻辑复制(这其实是由于MySQL一直是server和存储引擎分层的架构,逻辑复制发生在server层)。这个缺陷会让Postgres的运营不受业务开发者的待见。谁也不希望自己的业务停服。
 
反过来再看Postgres的优点,会发现对于OLTP并没有太大的吸引力:
 
1. 丰富的数据类型:通常用处不大,常用类型足够了。如果有复杂类型,业务上自己序列化,存储成varchar就行。可以用json,PB,avro等。序列化反序列化都发生在业务服务器,更好维护和优化;
 
2. 强大的审计函数:互联网早期活下来是一切,审计并不是核心需求(通常需要严格审计的领域早就会用Oracle/msSQL,不差钱);
 
3. 强大的索引:Postgres的自定义索引功能很强大。但是对于MySQL,关键的几列有索引就够了,不需要复杂的高级索引。我承认早期MySQL的查询优化器智商堪忧,但如果要改,一句explain,然后force index也就是了,对于开发人员简单直接。有一段时间LBS很流行,当时MongoDB很潮地直接支持了空间索引。当时大家纷纷“NoSQL”,就更不会看Postgres一眼。然后到了大概2015年,MySQL 5.7也支持空间索引了。
 
4. Posgres的MVCC实现牛不?牛。serial snapshot isolation是很强,但是到了需要变更数据严格一致的时候,select ... for update又不是不能用:)
 
5. 对于序列号,sequence是很好。但是互联网公司对于简单场景用auto increment,对于生产场景就直接用分布式序列号生成服务了。Postgres的序列号产生器~偏鸡肋。
 
6. Postgres的全文索引很强,但强得过ES?强得过专门定制的搜索引擎系统?要知道搜索业务最关键的是把“最匹配搜索人需要的搜索结果返回出来”,而不是仅仅“能搜到一堆不分主次但满足关键字匹配的结果”。
 
因此早期MySQL变成了事实上的互联网企业OLTP的事实标准。不管干啥业务,MySQL都不可或缺。在行业里跳槽来跳槽去的程序员普遍对MySQL也更熟悉。大量围绕MySQL的商业服务都成为了行业主流。新一代分布式数据库,像TiDB为了吸引用户,首先要做的是“兼容MySQL的语法”。
 
再往后,MySQL增加了更多“关系型数据库该有的”功能,比如完全支持ACID的innodb成为默认存储引擎,比如5.7的json原生支持,8.0的window function/CTE。而Postgres也增加了更多的“互联网功能”,但是时机已经过去了。大家MySQL跑着业务好好的,而切换数据库绝对不是仅仅像某些ORM标榜的换一个Dialect就行的,整个编程模型,性能表现,运维工具和流程都要有巨大的变化。如非必要,犯不着为了一个“most advanced”的标语去折腾,更不会为了数据库爱好者的情怀做伤害利益的事情。
 
 
 
2号知乎网友:罗诗亚
 
 
 

 

 

我已经不写代码、做技术管理一段时间了,但是有些支持工程师做技术选型的经验,根据业务上的需求来聊一聊吧。这里一半是我们技术选型时TL告诉我的,一半是我个人代码实践的经验。
 
数据库这种早期用了就基本不能换的东西是有滞后性的,你看到现在MySQL的现状,是“5年前MySQL是国内几乎唯一选择”造成的情况。5年前Postgres就已经在欧美初创项目里比较受欢迎了,国内公司数据量、体量是国外公司无法比的,毕竟用户人数多,随便都上亿,而且国外这几年新项目活得好的公司都是B2B,有几十万上百万用户量就很不错了。
 
Postgres有scaling issue(扩展问题?这个词中文怎么说),一个表2-3T就不行了,不做大量优化查询速度就以秒开始做单位了,这是云数据库提供商不会告诉你的。他们只会告诉你Postgres的优点。题外话,NoSQL也有类似的坏处。但是除非在生产环境中踩过坑,没有人会告诉你的。在技术社区里喷某个解决方案不行是会被鄙视的,特别是大公司,有这种体量业务的工程师是没时间跟你说这种扫兴的话的。
 
Postgres的好处之一是有好几年给新语言的ORM比MySQL成熟,对全栈工程师更友好。欧美的全栈工程师一般是脚本语言后端(Node、RoR、Python)加上前端。国内更流行的是强类型语言(Java)后端,一般不会同时前端的,Java + MySQL是真香。欧美这种全栈工程师的弱点就是对后端没有那么深的理解,这里就不细聊了。
 
前几年不需要运维支持就能部署的云服务提供商(Digital Ocean、Heroku)只支持Postgres。同上,全栈工程师一般是没有运维能力的。EC2上给你装个MySQL?RDS的文档能看懂就很不错了好吗~
 
MySQL对于你说的那些Postgres优点,都在国内有业界已经验证过,实施经验人数也很多的最佳解决方案。而且那些优点,是工程师做得爽而已,跟业务没啥实质性的关系。而踩过Postgres坑的这种人招不到,才是阻碍业务的第一大要素。
 
最后,为什么都是data类才用PG,因为data不是业务组,运维支持力度没那么大,也没有实时性能上的压力,上面的坏处不是什么坏处,好处却是可见的,能够提高开发速度的。
 
写得不对的请勿喷,哈哈。
 
 
 
3号知乎网友:灵剑
 
 
 

 

 

这可能还真的跟PHP有点关系,PHP很早的版本就有内置的mysql支持,很多Linux发行版都可以一键安装LAMP套件(Apache + MySQL + PHP),基本不用配置就可以开始用。其实国内PHP流行的时候已经有pgsql的支持了,但是习惯和早期沿袭的资料的影响仍然是巨大的。因为MySQL用得多,自然熟悉MySQL的DBA也多,熟悉pgsql的DBA少,也就进一步影响了其它语言的选型。
 
对于当时的大部分开发者和公司来说,PGSQL的那些高级功能反正也不会用,自然就跟不存在没什么两样。
 
 
 
4号知乎网友:聿明leslie
 
 
 

 

 

说说鄙人的见解。
 
从技术而言,PG 功能丰富,SQL 支持得很完备,强大的数据类型,严谨的关系模型,很难从关系模型去找出PG的不合理之处,多年积累,连全文索引词库都非常丰富,据说对于一些简单的搜索,都可以摆脱搜索引擎了,优化器做得很好,在代价选择上 PG 实现了基因算法,这一点连Oracle 也没有做到。
 
读过一部分 PG 的代码和 MySQL 的代码,对比起来,PG 的代码写得非常工整,注释也很细致,真的可以称得上code 教科书级别的工程,一定是一帮有情怀的coder 写出来的,对比起来,MySQL 就是一坨……
 
可是这个问题是一个工程性问题,就不要用这些方面来衡量一个工程问题!
 
历史总是时势造英雄,看看MySQL 火起来的那段时间,正是互联网爆发式增长的那几年。由于PG 丰富的功能,所以它显得太重了,多进程并发,再加上早期的存储做得不够好,太吃资源。那个时代,内存和存储都是比较昂贵的资源,早期的PG 性能也不太好,由于关系模型支持得很好,用起来会有诸多限制,学习成本会比较高。
 
比起这些,MySQL 要轻量很多,到现在这也是它的一个优点,在互联网这个特定的场景中,大家为了追求快速迭代和拓展性,使用的 SQL 功能不会太多,都够用。
 
而PG 由于更严谨的 SQL 关系模型,很多用法都限制得比较死,MySQL 却要灵活很多,你的劣势就出来了。这个让用户用起来很爽,但是对于兼容 MySQL 的兼容实现者很痛苦;有些 feature 在特定的场景中用起很便利,但是在通用的模型中却禁不起推敲,要不要兼容它呢?用户很难感知到这些,除非测试去乱试,一般人不会那么无聊,这就是工程上的权衡。很难说谁好谁坏。
 
 
而用的人多了,相关的使用经验会汇总到社区,形成部署方案、工具等,这又是工程中的正反馈。
 
在江湖中,有几个身负各项绝技的大侠最后成了将军和皇帝的?
 
 
 
5号知乎网友:flaneur
 
 
 

 

 

感觉是在几个互联网痛点的时间窗口没赶上,蛮可惜的。
 
之前 uber 有一篇文章:Why Uber Engineering Switched from Postgres to MySQL(link.zhihu.com/?target=https%3A//eng.uber.com/Postgres-to-MySQL-migration/
 
里面提到的几个问题现在我猜应该有解决,但是时间点晚了,比如:
 
  • 逻辑复制:之前 uber 用的物理复制,master 上一个 bug 导致数据损坏一个 bit 写错了,所有的从跟着坏。
  • Replica 事务糙:猜 Replica 的事务快照是怎么实现的?开一个事务快照 == 停止主从复制。
  • 写放大 + Replication 流量放大:与 MySQL 二级索引不同,Postgres 的索引指向的也是个物理位置,写入数据时,即使索引的值未变化,也要更新索引指向的物理地址,存在一点写放大,在物理复制的场景下,写放大 == 流量放大。

  • 连接管理:Postgres 一个连接一个进程,这时候你才想起来线程竟然是个轻量的东西。

 

MySQL 给人的感觉就是「我啥都挫,要啥特性没啥特性,事务都用起来没多少年,但是我十、二十年前就有主从逻辑复制跟 MHA」。

 

"为何MySQL在大陆成为主流,PostgreSQL屈居二线呢?"欢迎在留言区交流,留下你的观点~

 

 

整理丨dbaplus社群
来源丨知乎:zhihu.com/question/31955622
*仅为提供参考和学习交流,不代表dbaplus社群立场!dbaplus社群欢迎广大技术人员投稿,投稿邮箱:editor@dbaplus.cn
最新评论
访客 2024年04月08日

如果字段的最大可能长度超过255字节,那么长度值可能…

访客 2024年03月04日

只能说作者太用心了,优秀

访客 2024年02月23日

感谢详解

访客 2024年02月20日

一般干个7-8年(即30岁左右),能做到年入40w-50w;有…

访客 2023年08月20日

230721

活动预告