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官方标榜自己是世界上最先进最高级的开源关系型数据库，有这个自信就不错