共计 1945 个字符，预计需要花费 5 分钟才能阅读完成。
据 DB-Engines 最新发布的 2019 年 8 月份数据库流行度排行榜（如下图）显示，名列前茅的 MySQL 和 PostgreSQL 数据库的流行趋势与去年同期相比依然稳增不减。
作为使用最为广泛的开源数据库，MySQL 声称自己是最流行的开源数据库，PostgreSQL 也标榜自己是世界上最先进的开源数据库，虽然二者在功能特性上确实各有所长，但在实际的业务场景中很多用户往往一时间难以抉择。
接下来将介绍 31 会议在大数据量快速查询场景下，面对 MySQL 和 PostgreSQL 数据库的双重拷问时是如何进行最终选型落地以及数据库高可靠性背后的技术实现。
用户场景
31 会议是中国领先的场景营销科技服务商，通过运用互联网、物联网、AI、大数据和云计算技术，并结合会议、展览、活动等面对面营销场景，其陆续推出了会议云、展览云、营销云。其中，31 会议云和 31 会展云作为一站式数字会务 SaaS 云平台，通过组件化、集成化、流程化实现会展全流程智慧化。
注：图片来自 31 会议
PostgreSQL or MySQL？
作为 SaaS 化的会议平台，内部模块众多且关联紧密，对数据库的需求呈现多样化和精细化的特点，所以 31 会议首调研了 UCloud 提供的主流数据库类型，UDB 子类型如下表：
截至目前，31 会议累计服务 30 多万家客户、130 多万场会展的业务量，因此对数据库的存储需求量较大。且会议营销 SaaS 业务的实时性以及事务处理复杂性对 OLTP 和 OLAP 也都有着较高的要求。经过对比选型，用户同时选用三种数据库来针对性的满足不同目标。
由于 PostgreSQL 支持多种表关联算法，有丰富的统计函数和语法，面对多维度的复杂查询和分析场景性能表现优异，因此 PostgreSQL 相比于 MySQL 在 OLAP 上的快速高效是其优势，31 会议最终选择了 PostgreSQL。例如：在实际业务中，用户利用 PostgreSQL 来处理单表 500w 条记录规模的大数据量查询，并且快速流畅的将结果流转到下一业务环节。
自建集群还是 PostgreSQL UDB?
除了要解决上述不同数据库版本的选型问题之外，用户还需要面临的选择，是利用云主机自己搭建 PostgreSQL 集群，还是直接使用 UCloud 现成的 PostgreSQL UDB 产品？
传统的自建数据库方式，需要在前期投入大量的软硬件投入成本和运维维护成本，且部署周期较长，实际的资源利用率较低。而选择 PostgreSQL UDB 产品，不仅能节省资源人力成本，而且支持弹性扩缩容以及按需计费；在安全性和可靠性上更有保障，具备备份创建、自动回档等功能。另外从数据层面来讲，高可用主备和底层数据存储，具备数据冗余特性，可以保证数据零丢失。
基于 PostgreSQL UDB 能够带来的这些特性优势，用户选择了 PostgreSQL UDB。且经过时间证明，用户在使用 PostgreSQL 的一年多时间内，其实例没有发生过一次故障，后台对可靠性设计的机制抵御住了各种意外状况，没有影响用户正常使用，帮助其免去了紧急排障的烦恼。
正如 31 会议运维经理汤雷评价说：“PostgreSQL UDB 用在大数据分析上，查询效率更高。相比自建，其可靠性更高，方便运维维护。”
如何保证高可靠？
为了充分保证 PostgreSQL UDB 产品的可靠性，UCloud 数据库团队在功能方面做了很多优化工作，例如：
1. 自动回档
这个功能是指，当用户出现人为误操作造成数据删除或者丢失时，只要之前 7 天的备份存在，就可以利用“秒级回档”功能将数据恢复到过去 7 天内的任意一秒，可以说是为用户使用 PostgreSQL 产品提供了一颗“定心丸”。
除了回档，用户也可通过“创建从库”功能来创建更多数据库的副本，进一步增加数据的安全性。
2. 高可用部署，自动容灾
PostgreSQL UDB 为确保服务的高可用性，采用主从复制架构，主数据库提供服务的同时，有另一套数据库服务不断同步数据并随时待命，UDB 后台的自动容灾模块可以在 PostgreSQL 实例服务出现问题时自动探测到，并自动容灾，保证数据库服务的稳定可靠。
实例切换时，容灾模块会把待命的备用 PostgreSQL 服务提升为主库，并且在原来主服务启动之后回退到从库。整个过程中用户不需要任何人工干预和配置修改，真正做到自动容灾。
图：PostgreSQL UDB 自动容灾示意图
3. 热升级，不停服在线扩容
PostgreSQL UDB 可依据业务的需要，动态按需扩展数据库资源。用户只需在控制台上进行几次点击，就可以动态调整实例的内存和磁盘大小，满足不同业务阶段对于数据库性能和存储空间的弹性需求。
PostgreSQL UDB 在资源扩容过程中，数据库服务可以做到基本不停服，只有秒级的闪断。这样大大减少了数据库扩容对于业务的影响时间，做到真正的“热升级”。
