PostgreSQL—适合金融的数据库

前言

最近工作中接触了PostgreSQL，之前一直有听说这个数据库。但因为被称为下一代数据库的数据库太多了，而自己又不是数据库方向，Mysql和oracle已经可以满足要求，故而一直都是坚持在Mysql或Oracle。而最近深入接触Pgsql后，自己的感悟是这个数据库更适合金融；要解释为什么我觉得更适合金融，首先要从目前主流的mysql方案说起（说起mysql必然是分布式场景，集中式场景金融公司还是会选择oracle的）

Mysql方案遇到的问题

互联网的主力数据库技术体系还是Mysql为主，因为高并发确实是互联网的常见场景，各大厂为了支持自己的业务，Mysql的分库分表技术日益精湛，高并发写场景、多维度查询场景、大数据查询各种方案都日趋成熟。既然这样金融系统建设直接用mysql不是很好吗？
如果是不考虑成本的情况下确实是可以了，而大多数的公司也确实这么做了（这里的成本指的是包括了硬件成本、软件成本、运维成本、人力成本等综合评估）

【分库分表要面临的问题】

• 分库分表方案选择
• 复杂查询问题
• 运维成本问题
• 人才支持问题

1、分库分表方案选择
虽然分库分表还是一个挺复杂的过程，给的建议都是能通过分库解决，就别分表，能垂直分表解决就别水平分表，简而言之就是能不分就不分，而金融业务特点不同于互联网，大部分情况oracle rac基本可以支持了，或者按照时间做下分表，全维度查询通过数仓或者大数据平台解决；
但虽然金融和互联网的融合越来越多，如果业务一定要进行水平分表的话，自建方案常见的就是 mycat、tddl、sharding sphere吧。不过如果不是自己想扛起数据库的故障处理，还是建议采用商业或云分布式数据库吧，开源方案只是理论方案，做了基础的拆分，但高可用、容错等问题都需要自己去搞定，金融生产非同儿戏，如果自己不是数据库专家，建议还是交给专业的人解决。

2、复杂查询支持
其实数据库我们考虑无非是OLAP和OLTP，后来又出现了“集大成”的HTAP，是不是集大成不知道，但肯定是要通过场景验证才行，是骡子是马你得拉出来溜溜，不要只相信原理。而很多大厂的交易数据库都是OLTP支持非常好，这也是互联网业务逼的大家对OLTP的技术突飞猛进，所以他们的方案用来解决金融场景绰绰有余，而金融场景除了头部公司，大多都不回面临这种高并发的问题，但往往被厂商夸大并发场景来带货。
其实mysql的分不分表就是面临的这个问题，由于分表一定会根据某种规则拆分（一般都是有个分表键，即使不用手动设置，也是根据主键hash拆分来完成），所以必然会带来查询条件不带分表键，全库扫描的问题。不管是什么全局索引也好、优化算法也好，这个问题都没办法解决，分表少都好说，百表千表的时候这个问题就不得不解决了。其实解决这个问题的方法我的粗浅认知是只能是列存储解决（之前面临这个问题就是通过搜索引擎方案解决的，但由于增加了一个数据源，必然要考虑高可用、数据延迟、一致性、风险防控等一系列问题）

3、 运维成本
除了常规数据库DBA运维工作外，分库分表中间件的维护、功能升级以及高可用方案，数据一致问题，还有灾备数据如何存储、如何恢复问题等；当然还有日常的表变更、脚本执行，如果自己没有工具，手工去做的话，一旦出问题就是要花很多时间去排查解决

4、 人才支持
这个问题就不说了

其实以上这些问题互联网大厂都解决了，但付出的成本也是巨大的，这也是为什么会有双中台的方案（服务中台 + 技术中台）。那下面就说说为什么PostgreSQL更适合金融吧，首先要从Postgre的特点说起。

PostgreSQL简介

PostgresSQL官方标榜自己是世界上最先进最高级的开源关系型数据库，有这个自信就不错😄 这个不予评价了，仁者见仁智者见智，我不是数据库专家不乱说了，PostgreSQL数据库是目前功能最强大的开源数据库这点应该是争议不大，至少我没看反驳的声音，可能是孤落寡闻了。另外Pgsql讲可靠性、数据一致性与完整性最为最高优先级，这点上更符合金融的诉求，Pgsql主要特点：

• 稳定可靠：PostgreSQL是唯一能做到数据零丢失的开源数据库。目前有报道称国内外有部分银行使用PostgreSQL数据库。

• 开源省钱： PostgreSQL数据库是开源的、免费的，而且使用的是类BSD协议，在使用和二次开发上基本没有限制。

• 支持广泛：PostgreSQL 数据库支持大量的主流开发语言，包括C、C++、Perl、Python、Java、Tcl以及PHP等。

• PostgreSQL社区活跃：PostgreSQL基本上每3个月推出一个补丁版本，这意味着已知的Bug很快会被修复，有应用场景的需求也会及时得到响应，但和mysql这点比确实还是有些距离的。

• 和Oracle兼容度高： 这点也是适合金融的原因之一，因为金融公司大多是依赖oracle的，而受国家政策影响都会面临一个去O的问题。

金融谈数据库就不得不去和Mysql、Oracle对比，下面看下我整理的一些信息。

Round 1 ： PgSql vs MySql — 对比

pgsql相比mysql的优势

pgsql存储过程的功能支持要比mysql好，具备本地缓存执行计划的能力；

pgsql对表连接支持更完整，优化器的功能更完整，支持的索引类型很多，复杂查询能力较强；

pgsql主备复制属于物理复制，支持异步、同步、半同步复制，mysql基于binlog的逻辑复制，是异步复制，pgsql数据的一致性更加可靠，复制性能更高，对主机性能的影响也更小；

pgsql支持json数据类型，而mysql不支持，mysql字符型有长度限制，而pgsql的text类型无限长，可以使用xml xpath，用pgsql的话，mongodb这样文档数据库就省了；

pgsql是完全免费开源的，而mysql归属oracle后，开源程度大不如以前；

pgsql在GIS领域多年来处于优势地位，有丰富的几何类型，支持极其丰富的空间函数，可以建立R树、GIST树等空间索引，instagram就是因为pgsql的空间数据库扩展postgis远远强于mysql的my spatial而采用的pgsql；

pgsql有极其强悍的sql编程能力，有非常丰富的统计函数和统计语法支持，可用多种语言写存储过程，对R支持也非常好，这一点mysql就差的很远，

mysql相比pgsql的优势：

mysql采用索引组织表，这种存储方式非常适合基于主键匹配的查询、删改操作，但是对表结构设计存在约束；

mysql的优化器较简单，系统表、运算符、数据类型的实现都很精简，非常适合简单的查询操作；

mysql分区表的实现要优于pgsql的基于继承表的分区实现，主要体现在分区个数达到上千上万后的处理性能差异较大；

mysql的存储引擎插件化机制，使得它的应用场景更加广泛，比如除了Innodb适合事务处理场景外，Myisam适合静态数据的查询场景；

mysql也支持空间索引，是用R树实现的空间索引，但空间函数等功能不如pgsql丰富，空间查询比pgsql慢；

【对比结论】

空间操作比较多，数据逻辑比较复杂，推荐使用PostgreSQL
对数据安全性和稳定性要求很高，推荐使用PostgreSQL
业务场景复杂度不高，高并发大交易量的场景，推荐使用MySQL

pgsql更适合严格的企业应用场景，比如金融、电信、ERP、CRM等，mysql更适用业务逻辑相对简单、数据可靠性要求更低的互联网场景，比如google、facebook、淘宝等。

PostgreSQL和oracle是进程模式，MySQL是线程模式。进程模式对多CPU利用率比较高。
进程模式共享数据需要用到共享内存，而线程模式数据本身就是在进程空间内都是共享的，不同线程访问只需要控制好线程之间的同步。
线程模式对资源消耗比较少。
所以MySQL能支持远比oracle多的更多的连接。
对于PostgreSQL的来说，如果不使用连接池软件，也存在这个问题，但PostgreSQL中有优秀的连接池软件软件，如pgbouncer和pgpool，所以通过连接池也可以支持很多的连接。

Round 2 ： PgSql vs Oracle— 兼容

PostgreSQL与Oracle有很多相似之处，它们都是使用共享内存的进程结构，客户端与数据库服务器建立一个连接后，数据库服务器就启动一个进程来为这个连接服务。这与MySQL的线程模型不一样。

PostgreSQL与Oracle一样，PostgreSQL的WAL日志与Oracle的Redo日志都是用于记录物理块数据的变化的，这与MySQL的binlog是不一样的。

那如果是选择Oracle还是Pgsql的问题上，我的回答当然是Oracle，Oracle可以支持为什么选开源呢，而且Oracle确实强大，抛开开源，能用Oracle满足的还是不建议分布式数据库，运维成本和应用复杂度低很多。

不过在现在这个大环境下，去O之势在所难免，所以此时去O的成本就至关重要。

信息来源：
（1）https://baijiahao.baidu.com/s?id=1654604491258542404&wfr=spider&for=pc
（2）https://blog.csdn.net/huzechen/article/details/109541854
（3）https://blog.csdn.net/saint_alamo/article/details/7547920
（4）https://blog.csdn.net/weixin_34087307/article/details/89570853
（5）https://blog.csdn.net/xiaohai928ww/article/details/103742856