面试官:为什么高性能场景选用 PostgresSQL 而不是 MySQL?
一、 数据库简介 TLDR1.1 MySQLMySQL声称自己是最流行的开源数据库它属于最流行的RDBMS (Relational Database Management System关系数据库管理系统)应用软件之一。LAMP中的M指的就是MySQL。构建在LAMP上的应用都会使用MySQL。MySQL最初是由MySQL AB开发的然后在2008年以10亿美金的价格卖给了Sun公司Sun公司又在2010年被Oracle收购。Oracle收购导致MySQL的出现两个版本商业版和社区版。对于后者由于Oracle控制了MySQL的开发受到了广大使用者的批评。1.2 PostgreSQLPostgreSQL标榜自己是世界上最先进的开源数据库属于关系型数据库管理系统(ORDBMS)是以加州大学计算机系开发的POSTGRES4.2版本为基础的对象关系型数据库管理系统最初是1985年在加利福尼亚大学伯克利分校开发的作为Ingres数据库的后继。PostgreSQL是完全由社区驱动的开源项目。它提供了单个完整功能的版本而不像MySQL那样提供了多个不同的社区版、商业版与企业版。PostgreSQL基于自由的BSD/MIT许可组织可以使用、复制、修改和重新分发代码只需要提供一个版权声明即可。Note:MySQL的层级关系实例 - 数据库 - 表Postgres 的层级关系实例 - 数据库 - Schema - 表schema 可以理解为命名空间不影响使用二、性能对比测试环境MySQL硬件配置4核心 16GB内存版本MySQL 8.0Postgres SQL硬件配置4核心 16GB内存版本Postgres SQL 13此次压测数据 SELECT 均为SELECT 按照主键查询UPDATE按照主键进行UPDATEINSERT则为一次INSERT一行数据。从压测数据上来看我们可以得出以下几个结论在吞吐量上而言Postgres SQL 在SELECT性能上优于MySQL一倍 在INSERT上优于4-5倍 UPDATE 则优5-6倍从平均耗时上来看 Postgres SQL优于MySQL不止数倍尤其从热点行更新上看出MySQL性能仅为Postgres SQL的1/8左右耗时也增加了7倍三、适用场景如何选择相对于Postgres MySQL更简单 所以有着更高的流行度 在技术资料以及技术组件支持上支持的也更完善一些 但不意味着它并不是不能替代的于笔者而言 MYSQL更像用于中小企业、个人的一款数据库工具 因为会的人多文档资料比较完善所以入手难度低。但这些并不意味着MYSQL是最好的。从上图来看Postgres SQL的发展势头非常迅猛目前已经隐隐有追上MySQL的趋势 而MySQL相对而言使用情况受欢迎度一直呈现下降趋势。MySQL适用的场景MySQL适用于简单的应用场景如电子商务、博客、网站等, 大中小型系统均可以使用MySQL它最高支持千万级别到数亿级别的数据量但是在高性能要求的情况下比如较快的响应和较高的吞吐量的时候MYSQL的性能稍微捉襟见肘另外在查询条件比较复杂、业务吞吐量要求不高响应时长无要求的时候可以选择MYSQL。Postgres SQL适用的场景总的来说Postgre SQL更适合复杂的数据结构、高级应用和大规模数据集当然如果数据规模比较小也可以选择Postgres SQL无论是什么场景如果你想用Postgres SQL总可以找到对应的解决方法有且仅有在查询条件比较复杂的时候不太适用因为根据我们实际线上的业务表现是 Postgre SQL可能会选错索引。四、总结PostgreSQL相对于MySQL的优势Postgre SQL在性能上远远好于MYSQL 通过上面的压测数据即可体现无论是在耗时还是在整体吞吐量上有显著优势Postgre SQL在单行更新上有明显优势尤其是启用了HOT UPDATE后 性能比MYSQL高了一个数量级在SQL的标准实现上要比MySQL完善而且功能实现比较严谨比较学院化Postgre SQL主表采用堆表存放MySQL采用索引组织表能够支持比MySQL更大的数据量。Postgre SQL的主备复制属于物理复制相对于MySQL基于binlog的逻辑复制数据的一致性更加可靠复制性能更高对主机性能的影响也更小。MySQL 的事务隔离级别repeatable read并不能阻止常见的并发更新, 得加锁才可以, 但悲观锁会影响性能, 手动实现乐观锁又复杂. 而 Postgre SQL 的列里有隐藏的乐观锁 version 字段, 默认的repeatable read级别就能保证并发更新的正确性, 并且又有乐观锁的性能。Postgre SQL之于MySQL相对劣势Postgre SQL系统表设计相对复杂 在进行一些系统表的统计、操作等方面比较复杂Postgre SQL 的索引选择方面选错的概率稍高一些(实测) 而且不能跟mysql 一样方便的使用force_indexPostgre SQL 存在vacuum需要结合具体使用场景来调整vacuum的参数