孙亮
长亮科技数字金额解决方案高级技术总监
在金融行业中，分布式数据库具体应用时必然要考虑金融应用的特点来针对性优化改造。那么金融应用有哪些场景特点，对分布式数据库又提出了怎样的要求？长亮科技解决方案高级总监孙亮带来了主题为《金融应用对分布式数据库的诉求》的分享，就上述主题展开讨论。
行业背景介绍
银行业是比较传统的行业，其 IT 侧也是趋于保守的方向。银行 IT 早期追求稳定、高效、大并发，所以早期的服务器集中在大型机、小型机上，通过一体机来获得更高的处理效率。随着应用的发展，银行开始选择开放平台来搭建基于 Oracle 等数据库的应用架构。随着 x86 服务器兴起和 IOE 概念的弱化，应用数据库一侧尽管还是在 Oracle、DB2 上，但上层应用出现了基于 x86 做的应用集群。
现在由于政策导向、对技术方面的诉求与自主可控的要求，金融行业要尽可能走自主可控道路，更多选择国产的分布式数据库。这种背景下就出现了数据库整体迁移的需求，迁移过程当中也会发生一些问题。另外随着银行的部署架构变化，金融行业会依托云原生，再配合单元化架构来构成整体部署架构。有可能以前的数据库更习惯于部署在裸金属，以及划分出来的机器上，我们现在更期待是数据库以服务的方式开放给上层应用使用。这种背景下就出现了数据库迁移的一些诉求，下面来看一些同业案例。
对接案例
首先看第一个国产数据库对接的案例。该数据库的对接过程中，其语法支持度是比较不错的，能够原生支持 MySQL 5.7 语法以及 Oracle 语法。它的数据是通过分片的方式做多片存放，在多片存放的条件下我们需要聚合查询，它在语法层面给我们提供了聚合查询的能力，但是通过 Hint 来实现，对测试人员不是很友好。同时这也可能带来一些潜在的新问题，要求开发人员充分了解 Hint 机制以及 Hint 对语法的要求。所以在这一侧，我们对它的 Hint 使用做了一些限制，之后把聚合的结果、聚合的诉求上移到应用侧做处理。同时在数据库这一侧，还有一些其他的方式跟以往行为或者做法不太一样，比如说 DDL 语言。以前我们更习惯拉开一个客户端，做 SQL 执行，或者可以看到一个表的结构的方式。但是现在更多要求通过控制台来完成 DDL 的执行，需要大家有一定的适应过程。
在开发规范上，很多东西都要明确出来。以往开发人员在使用数据库过程当中可能更多关心索引是什么样，或者关心整个表的结构是什么样。现在还要关注 SQL 是不是带上了中间件，分片键是不是已被修改，这是需要在开发规范当中更加明确的，开发人员比以前要关注更多内容。
由于数据是分片，所以在整个对接过程中为了保证效率，我们是跨分片查询的方式，这就对上层的应用开发带来了一些限制，不能像以前很奔放地就可以获取完整的结果集。这样也对语法、使用习惯有一些约束。同时在整个对接过程中，我们考虑到线性扩展这一侧分为多片，但这样做的话分片数不能增加，能做的是尽量将分片分散在不同的计算资源上，以期望获得更好的计算能力。另外这种方式下，每个租户能够做垂直扩展，但所能够垂直扩展的最大能力也就是整个租户所在服务器的物理能力，在扩展上还是有一定的限制。当然如果我们配合一些数据库工具可以做租户的弹出与弹入，在底层资源上可以做一些替换。另一方面，在整个过程当中，因为分布式数据库上层有一个代理层，Proxy 层要考虑上层节点数量在增加的时候，它的线性扩展能力是否达标。如果仅仅是上层应用在扩展，而连接代理层不做扩展的话，可能会导致整体性能出现断崖式下降。
另外在生产过程当中做了一些数据的分片。对于不可分片的数据，要考虑将这些数据放在一些独立的节点上做管控与操作。另一方面，在整个生产部署环节，大家更关心的是我的应用部署完成之后，同城灾备与故障切换到底能达到什么样的水平。我们当然更期望在同城上 RPO 是 0，RTO 小于 1 分钟。金融行业关键系统、核心系统的应用，不再像以前是简单的 AS 部署模式，或者是简单做了同城双活的模式。我们可以将金融管理系统的部署模式由同城双活转变成多地多活的方式，提供更好的容灾能力、更好的多机房支撑能力，这是我们在第一个对接案例当中获得的能力。
对接过程当中我们也做了很多的工作。首先我们需要将数据库的一些信息，从原本使用的 MySQL 数据库迁移到国产数据库，迁移过程当中就会遇到一些数据库本身的设计方式差异导致的问题。比如说在整个过程中的超时时间，要求我们对超时时间的控制，上层不再要求做 30s、10s 以上的等待，这是我们在这个过程当中需要与上下游重新约定的问题。同时在性能这一侧，我们也发现其实简单的单表查询 TPS 可以达到非常好的效果；但是在多表关联情况下，由于数据需要多节点聚合，这种聚合情况下跨分区或者跨节点的关联查询，性能并不是特别好，不能达到预期。在这种情况下我们需要做一定的区分，在整个生产交易库上更多使用简单查询，在聚合查询侧需要将它剥离再聚合库、数仓做查询。这里进一步要求应用侧能够做好数据流推送与数据订阅推送服务，确保查询交易数据能够更加准确。同时我们也发现了国产数据库对存储过程的支撑情况并不是特别好。所以在必要的时候，我们需要放弃一些数据库的特性，将这些特性上移，放到应用层，以期达到同样的处理效果。当然我们也期望数据库本身在底层实现支撑，能够达到对不同的 SQL 语法以及过程的支撑。
我们也遇到过比较特殊的问题，比如说以前在数据库使用过程当中，我们习惯通过虚拟表的方式做一些运算，快速得到运行结果；或者做数据库的测算，迅速检测数据库连接的结果是否正常。由于国产数据库没有这样的虚拟表，导致检测机制需要改掉，通过其他方式来验证数据库的健康情况。另一方面，对一些 Bit(1)的数据类型，数据库有可能在解析过程中发生了数值的变化，Bit(1)可能变成 Bit(3)导致结果达不到自身的目标。另外对基于 JPA 的注解事务，由于数据库本身的配置特性导致配置冲突，进而导致 JPA 的选项时效问题。这些问题需要大家在对接过程当中，不光在代码层面上要检查，也要从配置层面上做更深入的检查。我们也希望国产数据库在自己的一些配置项上尽量与上层应用的配置项保持统一，或者做到更透明更公开，减少冲突配置的可能性。
另外整个过程当中我们也遇到特别棘手的问题，比如说通过 hikari 连接池，但是触发了原本修复过的缺陷，让我们花了大量的时间排查错误。其实错误原因很简单，就是数据库在这块会有空指令异常。其实 hikari 版本修复针对于 MySQL 驱动的特性与 URL 标记符做了分支处理，但虽然数据库内核是 MySQL，连接驱动关键字却不是 MySQL，所以缺陷会被重复触发出来。我们也希望国产数据库在版本引入过程当中，尽量把这种问题修复好。
下面看对接的另外一个客户案例。这个客户案例涉及到很多维度的改造，因为用的是数据库早期的一个版本，也是国产数据库在国内早期的实践。
客户期望不仅用国产数据库作为自己的生产主库，同时也期望基于 Oracle，或者基于以前用的很熟悉的高性能数据库做逃逸库。这样对上层应用有挑战，要求我的应用在这种情况下能够做到对不同的数据库语法完美兼容。如果数据库语法不能兼容时，期望我们能用一些 ORM 层，或者通过其他的配置层，对 SQL 语法做分支定义，得到更好的版本支撑。这是我们在数据库改造层面面临的第一个挑战。
另有在整个过程当中，因为使用了大量的 namesql，对于国产数据库无法改造的要调整业务逻辑代码，保持 ORM 与国产数据库同步调整。比较特别的是以前 Oracle 更常用到 SQL 语句，在其他数据库很难找到对应的支撑方法。这时候要求我们在数据库使用过程当中，只能更多地使用简单 SQL 完成数据库访问，减少差异化语法造成的应用迁移过程中带来的语法差异，或者是迁移的改造量。namesql 改造要能够支持不同的数据库，要求在 SQL 更好地统一协调、统一管控。
原来我们用到的一些表是公用参数，可能需要广播表。广播表的使用当中需要注意中间的延迟问题。还有以前做的物理分片，分片表的时候语句怎么自动生成，分片表上 Shardkey 怎么定义，Shardkey 怎么更加通用，更加对应用透明，都是需要考虑的问题。
在日终批量处理过程，还要考虑进一步提高日终批量处理效率的问题。一方面尽量压缩日终批量的窗口期，减少集中批量的步骤。另一方面让日终归于自己最原始的状态，它更关注于自己本地事务下的大批量数据处理，这样性能会很高。如果中间出现跨库、跨分片的事务，我们将任务归拢后，通过文件形式进行交互，这样可以进一步提高批量的效率。
以前在更新过程中，SQL 生成过程中，我们可能通过组件的方式做一些更新。这里面组件信息是不是被修改，大家都是知道的。如果发现别的问题，比如 Shardkey 不能被更新，这种情况下我们要在代码生成过程中，更多在底层做一些 SQL 调整。另外就是并发机制，数据拆分要尽量均匀化，如果数据不均匀的话有可能不一样，到时候性能要下降。
测试过程中我们也发现一个问题，并发数并非是越大越好。并发数其实是需要基于测试的结果，基于当前的业务状况与服务器部署情况，通过理论计算得到大致的范围。更准确的并发数据需要通过性能测试得出，所以在国产数据库上线之前性能测试一定是必不可少的，需要大家关注。
再总结看一下分布式数据库对接过程当中要做哪些事情。首先是分片键的配合，因为数据量很大，为了保证精准分配，Shardkey 一定要带上。在报表规范、交易接口、数据传递过程当中，这些东西要考虑到分片键怎么向下传递。另外就是原本的 SQL 优化特性在这里也是要注意的。以前索引创建的时候可能注意压索引就行了，但是现在不一定压到索引，同时要求高唯一性的数据字段向前放，这样可以更好地命中索引。
另一方面，我们也发现每个数据库自己的序列都不太一样，导致我们在做每次数据库迁移过程中都要对数据序列重新做分支方案。这种情况逼迫我们自己在技术平台里做独立的序列组件，通过序列组件做整体的序列。
日终并发过程中，数据分布不均匀也会影响数据性能，这里我们可能更多需要关注自己的分片键是否设置合理，是否可以达到数据平均化。
对接要点及关注点
金融应用的关注点主要集中在：
● 稳定性与容灾，对大并发量的支撑，在容灾切换时的 RPO 及 RTO；
● 适配迁移难度与兼容性，SQL 语法的兼容程度与改造难度；
● 数据库容量及性能，表宽度，索引数，字段长度等；
● 以往缺陷的修复率，是否对内核版本中已有的缺陷做了有效归并。
在此基础上，金融应用对分布式数据库的诉求包括：
● 问题排查能够更便捷一些，能够提供更多的 SQL 问题分析、SQL 优化机制，先验经验；
● 运维部署能够更快捷一些，有更多的配套工具，能够减轻运维人员的工作量；
● 在术语层面能够更统一些，比如对数据库的容量的概念，比如对数据库性能的概念。
数据库对比
以上是我们对比分布式数据库时主要关注的要点。国产数据库大部分的能力都做的差不多，比较通用、比较完整。但我们也发现有些地方还是需要一些提升的。比如说国家推行个人用户数据的信息安全机制，怎么能够在数据库这一侧得到保障？我们期望数据库这一侧能够提供更好的解决方案，因为从应用侧做这个事情性能并不是特别高。我们不希望像以前那样的粗糙方案，是希望基于特定的字段进行脱密加密，这是我们的诉求。
另外在主流数据库容灾能力的对比上，两个同等机房切换之间，数据库的 RPO 可以做到 0，但城市间切换 RPO 不能为 0，所以需要更好的保障机制。城市切换之间，数据应该能够得到一致性的保障。以上就是目前为止国产数据库在部署形态、部署方案上的一些问题。
