银行背景下分库分表技术选型
程序员jinjunzhu
资深后端开发，擅长java/golang，关注后端开发、分布式、云原生领域
Official Account
业务持续增长带来的单表数据量过大，必然影响到数据库的读写性能，那到底要不要分库分表呢？
阿里巴巴P3C规范给出一个推荐：
【推荐】单表行数超过500万行或者单表容量超过2GB，才推荐进行分库分表。
说明：如果预计三年后的数据量根本达不到这个级别，请不要在创建表时就分库分表。
对于银行业务来说，500万这个量还是很容易触达的。
分库分表的类型
水平分表：把一个大表数据在同一个库内拆分成多个表，这些表表结构一样，数据没有交集，如下图：
垂直分表：按照字段的维度，把一个大表拆分成多个表，每个表的字段都不一样，如下图：
水平分库：对库中的大表水平拆分到不同的库，最后所有库的表结构完全一样，数据没有交集，如下图：
垂直分库：对库中的大表垂直拆分到不同的库，每个库的表结构都不一样，如下图：
分库的优势:
支持更多的连接数
降低数据库故障影响范围
解决热点数据太多缓存放不下的问题
分库的代价:
跨库查询不支持join
会有分布式事务问题
聚合函数不能直接使用
自增id会有冲突
分库分表中间件
1.TDDL
淘宝的分库分表中间件，基于JDBC规范，没有server，用client-jar包依赖的方式部署。
tddl不支持下面的操作：
join语句
between/and
not语句
for update
force index语句
数据库内部函数
多表查询
下图是github上tddl现状，可以看到已经停止维护了。
2.kingshard
kingshard由go语言开发，使用时需要安装go语言环境和server，目前快手在用。从github上看，近1年有维护，但是不多：
缺点：不支持各类join和多表查询
优点：拆分表的数量可以跟拆分库的数量不一样，即分库后可以建子表
3.sharding-sphere
前身sharding-jdbc，目前比较热的一款中间件，好多公司在用。github上可以看到最近一个月内都有提交代码：
sharding-sphere使用jar包依赖的方式，不需要部署server。
社区活跃，遇到问题容易得到支持，支持分布式事务
4.Mycat
非常成熟的一款中间件，需要部署server做代理。网上吐槽mycat的商业味太浓，从github看，近期更新比较少。
5.问题
使用分库分表中间件会带来一些问题：
不能完全兼容原生sql
业务代码改动非常大
部署server的中间件需要考虑高可用
实际开发中可能会遇到各种坑
分布式数据库
分布式数据库是近几年兴起的新型数据库，主流的分布式数据库有2类，一类是PGXC风格的，另一个是NewSQL风格的。多数分库分表对mysql的语法支持更好一些，对oracle语法不太兼容。
PGXC风格的数据库，是在传统关系型数据库分片集群之上，增加了协调节点和全局事务管理器(GTM)来实现对分布式事务的支持。下面这个图是基于mysql单体数据库改进的PGXC数据库模型：
而NewSQL是由NoSQL键值数据库发展而来，构建在BigTable上的分布式数据库，不仅具有NoSQL对海量数据的存储管理能力，还保持了传统数据库支持ACID事务和SQL等特性。它主要有以下特性：
放弃了PGXC架构中单体数据库的事务
在BigTable基础上构建了事务支持
引入分片机制，主要采用Range动态分片技术，跟HASH分片相比，数据可以不用固定的在某一个分片上
可靠性方面，放弃传统数据库的主从复制，采用Paxos、Raft等共识算法来保证HA
存储引擎方面，使用LSM-Tree替换B+树模型，写入性能更高
下面这张思维导图分享了主流分布式数据库，左边的5款是主流的PGXC风格数据库，右边的6款是NewSQL数据库。
使用分布式数据库的优势：
解决了分布式事务问题
实现了强一致要求
技术新潮流
解决数据库国产化诉求
使用分布式数据库的挑战：
DBA团队运维能力
业务代码的改动量
新技术可能带来的坑
sql不兼容问题
oracle分区表
如果当下使用的是oracle数据库，解决数据量太大带来的性能问题，oracle的分区表是非常不错的选择。
oracle分区表有以下几种类型：
范围分区：根据id或者时间进行范围分表
列表分区：表中的某个字段有固定几个值，使用这个值做分表
HASH分区：使用HASH函数做分区，分区表数据比较均匀
组合分区：可以使用上面的2种做组合分区
使用oracle分区表的优势：
没有sql不兼容问题
业务代码改动较小
不需要考虑分布式事务
DBA团队运维压力小
使用oracle分区表的考虑：
技术偏保守
不能满足国产化诉求
不利于长远去o计划
系统单元化改造
除了上面提到的分库分表技术外，也可以使用系统单元化的方式来完成。这个做法有下面几个方面需要考虑：
是否支持动态分库分表
是否要考虑分布式事务中间件
多个系统的分库分表代码抽象共用
系统单元化改造，对DBA的运维压力小，但是对于开发团队来说不光当下工作量巨大，以后去o或者分布式技术的引入都会有巨大的改造量。
银行使用现状
工商银行
目前主要使用mysql和分库分表中间件(DBLE)，联合华为研发GaussDB 200并且部分系统投产使用。
邮储银行
老系统依然采用oracle，新系统逐步过渡到PostgreSQL，没有使用分库分表中间件和分布式数据库。应对大数据量带来的性能问题，邮储银行使用业务系统单元化方式进行改造。
中信银行
联合中兴通讯研发了PGXC风格的分布式数据库GoldenDB，并且部分系统已经投产使用。
交通银行
联合华东师范大学和西北工业大学，研发了NewSQL风格的数据库CBASE，目前已经应用到多个核心交易系统中。
下面的引用出自论文《分布式数据库在金融应用场景中的探索与实践》
数据库属于系统底层核心组件，且分布式数据库技术存在大量的技术难点，此前金融领域也没有相关案例，因此在应用与实践过程中，交通银行遵循“稳定第一、谨慎试点、稳步推广”的原则，先后在金融行业查询类业务、流程类业务和高并发类业务中逐步推广应用，试点均取得了良好的效果，节省了大量的成本.
北京银行
目前有几套重要的实时交易类系统已经对接TiDB，包括比较重要网联系统、银联无卡支付、金融互联服务平台等。
中国银行
在Zabbix监控系统中使用了TiDB。
光大银行
在云缴费系统中使用了分库分表，而在现金理财业务中使用了TiDB。
招商银行
下面介绍来自OceanBase官网：
基于OceanBase的"历史收益系统"已正式上线对外提供服务。通过使用OceanBase提供的分区表功能达成了业务无入侵的目标，同时满足业务并发海量数据访问的性能要求。此外，依托OceanBase优秀的存储架构和压缩能力在数据存储成本节省方面相比原传统数据库收益显著。目前业务仍在持续迭代，为招商证券相关手机端用户提供在线盈亏分析等特色增值服务。
总结
近几年银行业越来越重视技术的投入，各大行都成立了科技研发中心并且研发投入在持续加大。但银行的技术依然比较传统，数据库使用Oracle和DB2居多。这不光是技术问题，更重要的是银行业对稳定性的要求太高。
目前头部几家大银行应对大数据量带来的性能问题，手段不尽相同。大部分偏保守，有的银行在一些交易系统、管理系统上引入了分布式数据库和分库分表中间件。
从技术上看，分库分表中间件需要从开发层面解决分布式事务问题，分布式数据库才是未来的主流趋势。
账务核算这类的核心系统，对稳定性和一致性要求几近苛刻，大家在技术选型上都比较保守。至今还没有一家银行愿意在这类系统引入分布式数据库。
对于使用oracle的银行，如果不考虑将来去o，oracle分区表是最好的选择，因为支持原生sql，业务代码改动小，不用考虑分布式事务。
有的银行使用业务系统单元化的方式来解决海量数据造成的性能问题，这很好地避开分布式带来的技术挑战，但是业务系统改造工作量巨大，而且对以后技术升级或国产化支持非常不利。
未来银行业在技术上的持续投入必然带来技术的更新换代，而在国产化诉求下，去o是必然趋势，相信未来必然会有银行在账务核算类的核心系统中尝试分布式数据库。
看到这里了，如果对你有帮助，欢迎点赞，在看，转发。