工行
选择了 DBLE + MySQL 的组合，选择 MySQL 是因为它的普及程度足够高；而选择 DBLE 则因为它是在 MyCat 的基础上研发，号称是“增强版 MyCat”，由于 MyCat 已经有较多的应用案例，所以这一点给 DBLE 带来不少加分。
相对于 OLTP 技术应用上的平淡，工行在 OLAP 方面的技术创新则令人瞩目。基本是在同期，工行联合华为成功研发了 GaussDB 200，并在生产环境中投入使用。这款数据库对标了 Teradata 和 Greenplum 等国外 OLAP 数据库。在工行案例的加持下，目前不少银行计划或者正在使用这款产品替换 Teradata 数据库。
邮储银行（单元化）
邮储的核心业务系统改造方案更接近于单元化架构，所以连分布式中间件都没使用。
将原来商业数据库拆分成若干个小的单体数据库，分别设置对应的应用实例。邮储在单体数据库上选择了 PostgreSQL，这个在银行业中是相对较少使用的。
交通银行（研发 NewSQL）
它采用联合高校研发的方式，与华东师范大学和西北工业大学共同研发了分布式数据库 CBase。
CBase 的主要工作负载放在三类节点上，其中的数据存储节点与 NewSQL 风格完全一致，而剩下的 SQL 处理节点和事务处理节点，就是计算节点的细化。而且，CBase 也基于 Raft 协议设计和实现了轻量级分布式选举协议，分布式事务同样是在 2PC 上进行改进的。
中信银行（研发 PGXC）
GoldenDB 就是中信银行与中兴通讯联合研发的产品，而目前 GoldenDB 主要用户也是中信银行。
北京银行（NewSQL）
北京银行从 2018 年开始，先后在网联支付系统和网贷系统中应用了 TiDB。
由于各种原因，继续依赖 Oracle 这样的国外商业产品，很可能让银行将面临更大的风险。而对于小型银行来说，使用开源数据库还是分布式数据库，在成本上可能差异并不大。
光大银行（NewSQL & 分库分表）
在云缴费系统中，光大使用了自研的分库分表方案。 新一代财富管理平台使用了 NewSQL 数据库，也就是 TiDB。这个架构选择更多是面向未来，因为理财业务是光大银行重点发力的业务，对未来业务量的增长还是有很大预期的。
选型建议
- 产品选型要服从于项目整体目标
- 先进的产品可能会延长项目交付时间
- 当产品选型可能导致业务流程变更时，请慎重对待
- 产品选型中的非技术因素
- 评估技术潮流对选型影响
此文章为6月Day27学习笔记，内容来源于极客时间《分布式数据库30讲》
