部署|3年部署3000套PG实例的架构设计与踩坑经验


部署|3年部署3000套PG实例的架构设计与踩坑经验
文章插图
作者介绍
陈华军,苏宁易购架构专家,负责数据库产品的相关设计工作,十年以上数据库相关工作经验。PostgreSQL中文社区核心组成员,主要负责PostgreSQL中文手册翻译项目的维护。
PostgreSQL作为一款许可开放,功能齐备的开源关系数据库,在当前提倡自主可控的大背景下,正受到越来越多企业的重视。苏宁从2017年开始引入PostgreSQL,到2019年双11前3年间已上线3000多PostgreSQL实例,运行在我司各个不同的业务线。我们用PostgreSQL替换掉大量的商业数据库,不仅为公司节省了很多成本,而且通过灵活运用PostgreSQL的特色功能,甚至大大提升了业务的使用体验。
本次分享主要介绍苏宁引入PostgreSQL的背景和历程,以及我们在实际使用PostgreSQL中积累的一些经验。
一、背景
早期苏宁的数据库全部采用商业数据库。2013年,我们引入了MySQL。到了2016年,MySQL已经被大量使用,但是,核心业务仍然依靠商业数据库承载。当时我们意识到继续依赖国外商业数据库,除了每年需要支付高昂的许可和维保成本,对我们提升自身的数据库运维水平更好地支撑业务发展也存在诸多的弊端。因此我们在2016年启动了去商业数据库的调研工作,并于2017年开始逐步推进。
通过摸底现有业务数据库的使用情况,我们发现当时已大量使用的MySQL在功能和性能上离成熟商业数据库都有一定的差距,在某些场景下难以替代商业数据库,特别是需要执行一些复杂SQL的场景。因此我们在现有MySQL的基础上又考察对比了另一款非常流行的开源数据库PostgreSQL。
二、数据库选型
PostgreSQL和MySQL最大的差异可以概况为两点。第一,在使用场景上,MySQL支持的SQL特性比较少,在大数据量和复杂查询下性能也容易出问题,适合比较简单的OLTP业务;第二,PostgreSQL的功能更加全面,可同时支持OLTP和OLAP类的业务,和Oracle、DB2这样的商业数据库更加接近。
特性对比
详细的一些特性对比可参考下面的表格。
部署|3年部署3000套PG实例的架构设计与踩坑经验
文章插图
部署|3年部署3000套PG实例的架构设计与踩坑经验
文章插图
注1:参考 http://www.sql-workbench.net/dbms_comparison.html
以上对比基于MySQL 5.7和PostgreSQL 10。MySQL 8.0在SQL特性上有非常明显的提升,比如DDL事务一致性保证,支持窗口函数和CTE。
性能对比
通过实际的测试对比,我们发现PostgreSQL在某些场景下比MySQL有明显的优势:

    sysbench高并发主键查询测试,PostgreSQL和MySQL性能相当;
    sysbench高并发纯写入测试,PostgreSQL的性能是MySQL的4倍。测试MySQL时发现系统过早触及IO瓶颈,可能和MySQL的SQL加存储的两层架构导致IO放大有关;
    TPCH测试,PostgreSQL性能比MySQL高一个数量级。这个测试做的比较早,使用的MySQL和PostgreSQL数据库的版本都比较低,MySQL使用的是5.6,PostgreSQL使用的是9.5。当时MySQL 5.6中有一个SQL跑了2天都没执行完,还有一个SQL执行的结果是错误的。相信新版的MySQL和PostgreSQL上的性能都会有所提升,而且新版的MySQL上不应该还存这个Bug。
OLTP测试,如下图:
部署|3年部署3000套PG实例的架构设计与踩坑经验
文章插图
OLAP测试,如下图:
部署|3年部署3000套PG实例的架构设计与踩坑经验
文章插图
可靠性对比
在可靠性方面,根据我们的测试和实际的生产运行,发现PostgreSQL也优于MySQL。
1)复制延迟
MySQL在高并发写入场景很容易产生复制延迟,相同测试条件下PostgreSQL不仅写入的TPS更高而且没有观察到复制延迟。根据我们的测试,MySQL从库应用事务的速度在1w/s左右,PostgreSQL备库应用事务的速度则在10w/s以上。
产生这么大差异的原因在于MySQL是逻辑复制,主库的每条SQL在从库上都要完整的执行一遍,MySQL的从库即使启用并行复制,也难以达到主库的并行度。PostgreSQL的物理复制,备库直接修改被变更的数据块即可,所以应用日志的速度很快。为确保MySQL的稳定运行,我们要求业务在使用MySQL时,单库的写入TPS不超过5000。
部署|3年部署3000套PG实例的架构设计与踩坑经验
文章插图
2)故障恢复
在故障模拟测试和实际的生产运行环境中,我们发现MySQL在遇到宕机,RAID卡重置等硬件故障后容易出现主备数据不一致或者数据损坏无法启动的问题;同等条件下PostgreSQL出问题的概率小得多,通常重启就可以自动恢复。
对于普通的宕机我们可以通过切备机快速恢复生产,但是如果是断电导致的大面积宕机,就需要数据库在供电恢复后能快速启动快速恢复。宕机恢复对数据库来说是一项基本能力,但是在一些极端条件下,数据库也可能无法自动恢复。