银行分布式数据库应用情况探讨？

根据我行业务发展的要求，我们今年拟引入分布式数据库。在引入新数据库时，需先了解当前主流的数据库技术和成熟产品，然后制定相关的标准和规范。具体如下：
1、了解当前常用的RDBMS、NoSQL、newSQL、分布式数据库访问中间件的主流技术，都有哪些主流产品？它们的实现原理是什么？各有什么特点？

解答：

关于各类产品的主流技术或实现原理的概要信息可见文章：http://www.talkwithtrend.com/Article/247261

2、从应用和所需处理的数据角度，对银行的各种应用场景进行归类，哪类场景适合用哪类数据库？选型时要注意哪些关键特性？都有哪些案例？

解答：

（1）业务类型建议：分布式事务数据库适合实时关系交易型、业务峰值较大和并发较大的业务场景，从银行考核的角度推荐B类、C类先试点，再考虑A类和核心系统。

（2）具体的业务场景：以互联网核心中的网联系统、积分系统、理财产品、网贷系统等为主

（3）选型关键特性：

A 、数据一致要求：支持高性能、透明、实时一致的分布式事务算法，保证事务实时全部提交或全部回滚，严格保障数据的一致性；支持事务隔离级别 Read Committed 、 Repeatable Read 、 Serializable ；支持悲观锁、智能实时死锁检测、智能实时死锁解除及记录相关日志信息 ；

B、 数据库功能要求：支持 CREATE 、 TRUNCATE 、 DROP 、 ALTER 、 RENAME 、 SELECT 、 INSERT 、 UPDATE 、 DELETE 等数据库基本操作；支持透明跨数据分片的 JOIN 连接；支持透明跨数据分片的分组计算、排序、分页、聚合函数、控制函数等

C、 水平扩展要求：具有完备的动态扩容缩容能力，支持可视化在线一键扩容缩容，做到：在线增加 / 缩减从存储节点读操作扩容、数据节点跨物理服务器迁移扩容、增加 / 缩减数据分片的扩展等多种扩容缩容模式，数据节点扩展分布式集群的处理能力和数据容量，且扩容 / 缩容过程中做到不影响业务访问

D、 业务健分片：支持智能算法按业务访问呢需要生成数据分片的分片键、分片类型等，这个涉及到如何确保业务系统性能最佳和数据架构设计最佳

3、这些产品的性能比较：功能测试可参考 金标委3月份底即将发布的 行业标准 和 测试方案标准，后续也会提供具体的测试用例，性能建议直接采用模拟银行转账业务场景 或即将采用的业务系统才有参考价值。

4、这些产品的功能比较： 重点体现在分布式事务支持能力、采用同Oracle/DB2/MySQL等一样处理逻辑悲观锁 还是 NoSQL产品的乐观锁、是否支持死锁检测和死锁解除、产品运维功能完善（这个就像买一架飞机涉及到如何做好上线后保养维修）

附件：

分布式事务.xlsx (10.52 KB)

分布式数据库看起来很美好，提供了横向扩展性能的能力，高可用性看起来也大大增强了。但是相对技术比较新，而且是面向特定的场景，对前端应用要求比较多。所以在使用分布式数据库之前，一定要熟悉产品，制定好相关规范和基础设施。

近期在写个分布式的文章，参考的数据库如图中所示，我学习了下这些数据库的分布式技术原理，找了这些架构图，都是产品官网的，仅供参考。

我认为分布式数据库走过了从读写分离，中间件分表，分布式数据库集群这三个阶段。现在市面上分布式数据库集群的这种解决方案已经不少了，所以从纯主打分布式数据库集群的产品开始就行。

我们行里也测试了相关分布式数据库的性能，毕竟不同的场景效果不一样，也不便直接拿出数据。建议还是按照自己行里额业务测试测试效果。

最后谈谈自己的经验。首先分布式数据库对于基于业务分片后的单点事务性能都很好，性能上限一般都是在全局事务管理器这个组件上出现瓶颈，因此这部分做的好不好决定了一个分布式数据库产品的上限。其次是分布式事务的处理能力都比较差。这个是显而易见的，分布式数据库都这个特点，吹嘘的再好也是弱项。因此对于适合分布式场景的业务，一定要好好把关，不是所有的业务场景都适合分布式数据库。

现在的分布式数据库并不是脱胎于成熟商业数据库。银行用商业数据库这么多年，早就被娇生惯养了。数据库周边的衍生工具很匮乏，资料也少。遇到问题除了求助厂商也没什么其他途径。因此生态还需要很久才能养成。现在只能陪着成长。

这是项风险很高的工作，努力吧

1、了解当前常用的RDBMS、NoSQL、newSQL、分布式数据库访问中间件的主流技术，都有哪些主流产品？它们的实现原理是什么？各有什么特点？
RDBMS是关系型数据库，这个概念出现最早、应用最广，传统的oracle、db2就是。支持ACID特性、SQL语法，对海量数据管理能力不足。
NoSQL是大数据背景下诞生的一种非关系型数据库，分为key-value、文档型、图数据库等。 支持海量数据存储管理，不保证遵循ACID特性、SQL语法兼容性较差。Hbase、 MongoDB等属于这一类。
NewSQL是对各种可扩展、高性能数据库的简称，既支持 ACID特性和SQL，又适应海量数据场景，融合了RDBMS和NoSQL的有点，并且具备一定的HTAP能力。市面上自研分布式数据库几乎都可以适用这个概念。
分布式数据库中间件，在传统数据库之上加了一层中间件，用中间件来实现水平扩展、读写分离、分库分表等能力。应用最广泛的是mysql+mycat搭配。
2、从应用和所需处理的数据角度，对银行的各种应用场景进行归类，哪类场景适合用哪类数据库？选型时要注意哪些关键特性？都有哪些案例？
对银行的各种应用场景进行归类，考虑从两个维度归类：
（1） 交易型or分析型：可以将银行的业务非常粗略地分为交易型场景、分析型场景。网银、手机银行等属于交易类，数据平台、报表系统属于分析类。
（2）交易规模大or小：并发量大的业务系统使用分布式数据库，并发量小的系统使用传统数据库（当然也可以使用分布式数据库，看贵行意愿）。
交易类、并发量大的系统，适合NewSQL。贵行应该是想在这类系统上引入分布式数据库吧。
3、这些产品的功能、性能比较。
分布式数据库产品太多了，大致分两类：一类是自研分布式数据库，另一类是开源数据库+中间件的模式。OceanBase、TdSQL、GuassDB、TiDB属于前一类。还有一类是基于mycat这类中间件做了增强和包装。
如果贵行已经用了mysql，不妨试试中间件，在迁移成本、改造难度上会有所降低。
如果财力允许，从传统数据库转型，不妨直接使用自研分布式数据库。

分布式数据库厂商比较多，每个厂商的产品其实也很多，对分布式数据库选型要明确大的需求方向，是在线交易为主，例如核心业务系统，还是离线分析型为主，例如数据仓库。如果分析型的话，目前大数据应用都比较多了。如果是交易为主的话，像腾讯TDSQL，阿里oceanbase，中兴的goldendb，华为gaussdb T等等都是比较不错的数据库产品，成熟的数据库需要各类业务场景的打磨，很难说哪个数据库好坏，目前腾讯的TDSQL已经在银行传统核心业务系统落地案例，中兴的分布式数据库目前在中信银行的传统核心业务系统做测试，预计也会很快上线，所以如果要引入的话建议考虑几家银行案例较多的厂商做Poc测试，做完测试就知道哪些数据库适合自己的场景了。

1) 低硬件成本：完全使用 x86 架构的 PC Server，不需要昂贵的 Unix 服务器和磁盘阵列；

2) 集群架构与部署：完全并行的 MPP + Share Nothing 的分布式架构，采用多活 Coordinator 节点、对等数据节点的两级部署结构。Coordinator 节点支持最多部署 64 个，数据节点支持最多部署 300个，数据量支持 15PB。

3) 海量数据分布压缩存储：可处理 PB 级别以上的结构化数据，采用hash 或 random 分布策略进行数据分布式存储。同时采用先进的压缩算法，减少存储数据所需的空间，可以将所用空间减少 1～20 倍，并相应地提高了 I/O 性能；

4) 数据加载高效性：基于策略的数据加载模式，集群整体加载速度随节点数增加线性增长；

5) 高扩展、高可靠：支持集群节点的在线扩容和缩容，效率更高，对业务的影响更小。

6) 高可用、易维护：数据通过最多 2 个副本提供冗余保护，自动故障探测和管理，自动同步元数据和业务数据。提供图形化监控工具和企业管理器等管理工具，简化管理员对数据库的管理工作；

7) 高并发：读写没有互斥，支持简化模式的 MVCC，支持数据的边加载边查询，单个节点并发能力大于 300 用户；

8) 行列转换存储：提供行列转换存储方案，从而提高了列存数据库特殊查询场景的查询响应耗时；

9) 标准化：支持 SQL92 标准，支持 ODBC、JDBC、ADO.NET 等国际接口规范。

10) 数据节点多分片：在一个数据节点上可同时部署多个数据分片；单数据节点数据分片数量支持最多 32 个。

11) 灵活的数据分布：用户可以按照业务场景的需求，自定义数据分布策略，从而在性能、可靠性和灵活性间获得最佳匹配。

12) 异步消息：Coornator 默认采用异步消息模式与数据节点通信，支持高达 300 节点的集群规模。