logo头像

不忘初心 方得始终

PG与MySQL选型分析

引言

PostgreSQL(简称pg)是近几年增长率较快的开源数据库,很多企业由原来的MySQL转向pg,在这里对比这两大开源关系型数据库的优劣,以便使用时快速选型。



PG与MySQL的一些特性对比

特性 PG MySQL
口号性特点 最先进的开源数据库 最流行的开源数据库
SQL编程能力 强大的SQL能力,包括丰富的统计函数和统计分析,对BI有很好的支持 没有强大的统计功能支持
数据类型 丰富的数据类型支持,包括地理信息、几何图形、json、数组等,json也可以建立索引 在地理信息支持度上不如PG,不支持几何图形等数据类型
事务能力 完整的ACID事务支持 不是完整的支持ACID事务特性
join 支持nested-loop, sort-merge, hash三种类型 只支持nested-loop
Text类型 没有长度限制,可以直接访问,可以索引,可以全文索引 有长度限制
复杂查询 支持窗口函数,支持递归,支持with语句 不支持窗口函数、递归等
索引 多种索引类型,包括b-tree,hash,gin,gist等,可以对模糊查询、正则表达式、地理信息系统等建立索引 主要是b-tree索引
数据复制 支持同步复制,支持流复制 支持异步复制
查询优化器 功能更强大,对子查询的支持更高效 子查询效率不高
7*24 隔一段时间需要进行VACUUM 适用7*24
性能和适用场景 复杂查询 简单业务场景,更高的TPS
运维资源 专业DBA相对较少 众多DBA有丰富的运维经验
大小写 大小写敏感 大小写不敏感
行大小限制 无限制 65535

PG存在的问题和解决方案

序号 问题描述 问题分析 解决方案
1 主从同步WAL方式,主库挂掉,从库有时会启动失败,或者很慢 应该是主库没有保留足够远的xlog数据,导致主从时间线不一致 主库的wal_keep_segments要设置的足够大,个人推荐要保证允许从库挂48小时:wal_keep_segments=(48小时*log增量大小)/16M
2 在大数据量情况下,PG对地理位置信息(附近客户)的查询效率较慢 关系数据库在处理大数据方面天然有劣势 可以进行分库处理,尽量保证单库的数据量在PG的处理能力之内;如果效率还满足不了,采用ES来处理
3 WAL从库只能是只读的,报表比较难处理 如果是双主或者是多主,数据同步是大问题 根据业务进行调整,业务架构不需要双主,BI对从库只有读的需求
4 基于XID的MVCC实现机制,导致需要定时触发VACUUM,导致性能的抖动 基于MVCC的方式导致会产生垃圾,这些垃圾需要在合适的时间被回收 这个需要根据实际情况调整回收的策略,需要DBA配合调优;就像JVM的GC一样
5 大小写敏感,这对于习惯于原来大小写不敏感的编程方式,可能会很不习惯 PG对对象和数据都是大小写敏感的 对象的大小写敏感问题:PG在分析SQL脚本时,对不加双引号的所有对象名转化为小写字母;数据的大小写敏感问题:可以在存储的时候进行转换,或者查询的时候进行转换,可能需要配合建立表达式索引
6 MVCC机制带来的SSD写放大和索引写放大 支持并发读写的数据库都会有写放大问题,不是PG独有 PG的HOT技术,以及基于Heap的存储技术,对写入和索引可以调优写放大的问题;实测也部分验证了这一点
7 PG的复制低效,有写放大 PG的流式复制复制非常高效,支持流的加密和压缩;并且从9.4开始支持逻辑复制
8 备库的MVCC支持较差,查询会与恢复堵塞 基于物理复制或逻辑复制,只要备库拿来使用,都有可能出现查询与恢复冲突的情况。PG对于冲突的处理非常的人性化,你可以选择恢复优先 or 查询优先,设置时间窗口即可。同时PG还支持备库的QUERY反馈机制,主库可以根据备库的QUERY,控制垃圾回收的延迟窗口,避免QUERY和垃圾回收的冲突。
9 跨版本升级较难,跨版本不支持复制 现在的PG对大版本升级已经有很好的支持
10 调优比较复杂 PG的调优参数较多,各个参数还有联动 补充专业DBA,专业指导,积累经验

部分问题可在https://yq.aliyun.com/articles/58421查看。

微信打赏

赞赏是不耍流氓的鼓励