数据库技术作为信息技术应用创新过程中的一项重要技术，其面临的难题也是亟需解决的关键问题。兴业证券在《集团五年金融科技规划》中提出，要以信息技术应用创新架构评审为抓手，制定信息技术应用创新规划和建设方案，以高可用性、开放成熟、架构标准化、连续性和易迁移、技术先进性、行业监管合规为架构设计原则，完成信息技术应用创新基础架构规划，形成信息技术应用创新架构管理规范，打造稳定高效安全的信息技术应用创新基础软硬件技术路线，为金融数字化转型及自主可控提供有力支撑。

兴业证券在保证数据库一致性、可靠性、高可用的前提下，完成信息技术应用创新分布式数据库建设，具备快速交付、动态扩容的能力，能够高效地应对业务的需求。本文重点介绍兴业证券分布式数据库标准架构、应用资源评估模板、应用适配最佳实践等工作内容，积极为行业侧提供系统性、制度性的分布式数据库解决方案，为行业和产业生态贡献力量。

（一）分布式数据库核心技术能力

分布式数据库，通常通过复制和冗余机制来提供高可用性；通过将数据分布在多个节点上并行处理来提供高性能；根据负载情况分配和调整资源提供可扩展性；通过一致性协议和分布式事务机制来保证数据一致性；通过数据加密和访问控制等安全机制来保护数据的安全性。

（二）分布式数据库标准架构

兴业证券分布式数据库采用全栈信息技术应用创新技术部署，通过搭建 OceanBase 数据库集群，结合 OceanBase OCP 的资源管控能力，形成云化数据库集群，提供分布式数据库资源的能力。

结合集群内多副本高可用和主备库流复制两种方案，兴业证券在同城与异地部署了 1：1 同构的 OceanBase 数据库主备集群，为接入应用提供本地节点级高可用和集群地域级容灾能力。每个集群有自己单独的 Paxos Group，保证集群内多副本一致性，每一笔写事务必须到达半数以上服务器才生效。因此当少数服务器故障时，不会有数据丢失。集群间通过物理日志做数据同步，形式上类似传统数据库 "主从复制" 模式，从主库 "异步同步" 到备库，类似 Oracle Data Guard 中的 “最大性能” 模式。

图1    OceanBase 容灾架构基本部署单元

随着接入应用的增加，租户数增加的同时集群规模也会同步增加，单个集群内部署的租户建议控制在 30 个以内；对于有极高资源需求的应用，允许独立使用一套集群，如本次实践应用中的 CRM 系统，但需保持部署架构一致。

（一）应用资源评估

1.应用场景评估

应用系统考虑是否需要使用 OceanBase 数据库，应当从使用场景进行评估。例如：

• 数据规模和并发性能需求：如果应用系统需要处理大量的数据和高并发的请求，OceanBase 数据库可以在数据具备高压缩比的基础上，提供较好的性能和扩展性。

• 数据一致性和可靠性需求：如果应用系统对数据的一致性和可靠性有较高的要求，OceanBase 数据库采用分布式架构，支持数据的强一致性和高可靠性。

• 数据查询和分析需求：如果应用系统需要进行在线数据查询和分析操作，OceanBase 数据库支持复杂的数据查询和分析操作，包括分布式事务、分布式索引和分布式查询等功能。同时需要理清联表查询场景和简单查询的数量，为后续的资源评估作参考。如果是作为数仓和离线分析场景，则需要根据具体情况评估，OceanBase 数据库虽提供 HTAP 能力，但与传统离线数仓相比仍有差距。

截至目前，兴业证券完成了二十余套系统 OceanBase 数据库的信息技术应用创新改造，主要为在线事务处理、在线查询分析场景，数据量规模在 10G-1T 不等。通过对众多系统的实际使用，兴业证券总结了分布式数据库的应用效果，沉淀了信息技术应用创新改造经验。

2.资源估算

存量系统资源估算。对已有系统的资源评估，应尽量参考当前生产资源，综合考虑生产负载情况、信息技术应用创新硬件设备性能浮动情况，以及系统容量需要达到生产峰值两倍等要求。

以某投顾类系统的资源估算为例，分别拉取其晚上跑批和白天高峰查询时段的 AWR 报告、运行监控报告。根据原数据库 AWR 负载报告、运行监控报告，发现白天交易峰值期间 CPU 使用率 19.7%，夜间批量 CPU 使用率 4.2%。近 1 个月 CPU 峰值不超过 50%，内存使用约 50%-60%。因此给出如下资源预估：

• CPU 资源预估：Oracle 共 104 线程的环境，高峰期 CPU 使用率 20%，实际使用 20 线程，考虑自研 CPU 单线程处理能力，大约实际需要 40 线程，再考虑 CPU 安全水位（生产环境建议白天交易时段不超过 30%），CPU 建议分配 120C。

• 内存：对于联表查询较多项目，建议内存为 CPU 线程数的 4 倍可达到最佳实践。普通项目通常按照 2 倍 CPU 分配内存即可。

• 架构：服务器单节点 CPU 线程最高 128，但考虑随项目发展，资源需求可能越来越高，超过 128C 时，将租户扩为 2unit，此时会涉及跨机 SQL，因此在开发阶段，直接以 2unit 或 primary zone 打散到 2 台的模式进行适配优化，提前暴露跨机查询可能存在的问题，并寻求解决方案。

图2    AWR报告示例

图3    运行监控示例

新建系统资源估算。与存量系统不同，新建系统的负载较难预测，初期分配的资源未必是终态，这要求应用在上线时就要想好后续的扩展方案，但在实际中，要求每个新建系统具备该能力，与系统迭代上线的需求又有矛盾，因此，分布式数据库的扩容和缩容能力，是高效支持新建系统的关键。

对于新建系统的初始资源规划，可从如下几个方面考虑，包括数据增量、访问负载特点及性能和响应时间要求：

• 数据量和负载预测：评估数据库所需的硬件资源首先需要考虑数据量的大小和负载的预测。根据应用系统的数据量和负载情况，确定数据库需要处理的数据量和并发访问量，以此为基础进行硬件资源的评估。

• 性能和响应时间目标：评估数据库所需的硬件资源还需要考虑性能和响应时间的目标。根据应用系统对响应时间的要求，确定数据库需要提供的性能指标（如每秒查询数、并发连接数等），以此为依据评估硬件资源的需求。

以某智能平台为例，该系统面向公司内部员工，数据量会有逐步增长的趋势，以简单查询场景为主，特定时段会有一定的并发量。测试环境中，先分配 4C8G 资源先行验证，测试情况显示 CPU 高峰期使用率 29%，内存高峰期使用率 49%，初步评估后建议以 8C16G 为初始资源投产，后续根据实际使用情况动态调整租户规格。该系统资源量属于单机可以承载的情况，数据副本建议不打散，在单OBServer中，可避免跨机开销。

图4    CPU、内存三副本使用率监控

3.资源评估模型

基于上述系统评估、开发、上线的实践经验，我们编写了适用于 OceanBase 数据库的资源评估预测模型，项目组申请资源时，根据其需求（QPS、数据量、负载类型、对象数量、数据增长情况、业务架构、灾备需求等因素），量化出适合的租户资源与部署形态。

图5    分布式数据库资源评估模型

虽然预测无法做到绝对精准，但得益于数据库资源管理的便捷性，各系统在使用中如发现性能瓶颈或资源使用率较低，可在线增大或减少租户资源，在安全生产的前提下提升资源利用率，最终本次适配的二十余套应用以8C16G资源需求较多，部分仅需1.5C6G，少数需要32C64G以上。对于租户类型，具体比例如图6所示。

图6    2023分布式数据库租户类型占比

（二）应用适配

1.数据库驱动及连接池工具

对于原先使用 MySQL 的系统，可沿用原驱动；新建系统以及原本使用 Oracle 的存量系统，则使用 OceanBase 数据库官方驱动最新版。

按照兴业证券组件版本规范，连接池工具推荐使用 HikariCP 对应稳定版本。

2.库表设计及调整

数据库表设计需遵循兴业证券数据库开发设计规范，操作细节可参考 OceanBase 开发指引。其中关键注意事项如下：

• 分区字段选择：数据量快速增长的流水表必须使用分区，尽量选择业务最常用的查询字段作为分区字段；

• 表组：分区字段相同的表，可创建为同一个表组，可尽量规避分布式开销；

• 分区数控制：原本依赖按天分区的系统，迁移后需重点关注，当集群分区数过多时，可改为按月分区+local 索引，以减少集群整体分区数；

• 分区索引选择：首先按 local 索引开发和使用，若业务存在全局唯一诉求或存在无法带分区键查询的场景，则考虑使用全局索引；

• 全局索引：全局索引时，删除分区须谨慎，删除分区时，全局索引存在一个不可用窗口。

3.SQL 排查及编写建议

OceanBase 对 MySQL 和 Oracle 的语法兼容程度都较高，大部分 SQL 无需修改即可无缝迁移，但仍有少部分语法存在使用上的差异；性能方面，由于优化器能力、分布式开销等因素，部分复杂 SQL 可能有不一样的表现，此时需要逐个排查，通过人工绑定 outline 指定 hint，提升 SQL 性能。整体上 SQL 编写和优化过程中可以参考以下技巧：

• 高效处理 SQL 报错：在开发测试环境，可开启集群参数“enable_rich_error_msg”，程序端将返回报错 SQL 的 trace_id，这能提升开发适配阶段的问题定位效率。

图7    程序返回报错带数据库trace_id

• 严格遵守其 SQL 规范：如，OceanBase 对 order by 子句的使用更严格，相同子查询语句中是否使用 order by 在 OceanBase 和 MySQL 中运行结果不一定相同。

• 充分借助现有工具：业务开发测试阶段，重点关注工具给出的优化建议，并检查确认。如：是否正确使用索引。

图8    慢SQL排查

4.数据迁移方案制定

对于已有系统将数据库更换为 OceanBase分布式数据库的情况，需要制定数据迁移方案。推荐使用 OMS 工具进行数据迁移。

对于迁移操作，有以下几点问题需要注意：一是迁移对象及数据的完整性需验证。如 OMS 在迁移表及数据时，无法迁移带中文字符名的对象，无法迁移临时表，不支持 MySQL 中的事件；二是迁移完成后，需记得执行“正向切换”，这一步包含迁移收尾动作，如删除 OMS 自行创建的隐藏列（用于数据校验）。

图9    OMS数据迁移

5.数据备份策略制定

OceanBase 分布式数据库提供逻辑备份和物理备份两种备份方式。

对于业务侧，部分业务要求逻辑导出或导入，通常使用配套的 OBloader/OBdumper，需要注意使用该工具要求客户端有较充足的资源，并且数据量较大时，导出的文件将占用较大的存储空间（原因是 OceanBase 的存储默认带有压缩）。

对于运维侧，通常采用统一的物理备份，对于生产环境，备份恢复策略有 3 个关键点。一是空间规划，由于数据本身已经压缩，对于大数据量场景，物理备份对存储容量的需求比逻辑导出更低，但物理备份包括了日志归档，是一个持续写入的动作，备份目录的空间规划需要考虑备份数据的保存时间；二是集群规划，当前兴业证券使用 3.x 版本的集群，备份按集群为单位，因此规划租户时，将小容量的租户与大容量的租户分开，避免小容量租户的备份时间受大容量租户影响；三是恢复演练，集群上线前进行恢复演练，包括在备集群以及其他集群恢复租户，有空闲的集群资源时，可以使用 OCP 的备份恢复抽检功能，定期自动做数据恢复，以保证备份文件可恢复。

6.应用部署及测试

各项适配完成后，应用完成部署，即可连接数据库进行功能测试及性能测试工作，测试过程中需留意资源监控和性能监控情况，目前数据库的告警已经通过 OCP 的开放 API 对接至公司统一的告警平台，相关人员能够及时发现告警信息。

图10    租户性能监控

7.生产上线

前期完成了《OceanBase 数据库麒麟部署基线》并提供 ITSM 资源交付模板，项目组按照评估后的资源提交生产资源申请，上线时更换生产访问地址即可。

图11    生产上线申请模板

（三）常见问题

在这二十余套应用系统适配的过程中，我们将遇到的问题进行了整理，形成了问题集，这里摘录几条较为常见的场景，详见表1。

表1    应用适配常见问题

（一）构建分布式数据库标准架构，提升数据库服务化能力

在运维方面，我们将数据库提供的多租户内核能力与相应的运维管理能力，与我司自动化运维体系良好结合，形成互补，大幅提升了数据库服务化能力，构建兴业证券分布式数据库标准架构，推动应用适配效率大幅提升。相较于 Oracle 或 MySQL，OceanBase 适配准备时间从小时级缩减为分钟级。在此基础上，我们初步得出了资源评估模型，目标是在项目建设前期就确定好租户形态，让数据库更好支撑业务未来发展。

（二）建设分布式数据库高可用架构，提升应用可靠性

业务支撑方面，分布式数据库架构使机房内不再存在单点故障，能够很好地满足业务系统的高可用要求，在少数副本故障情况下，能够做到 RPO＝0，RTO<30 秒；凭借租户的弹性能力，遇到性能瓶颈类的故障能够快速通过资源升配完成扩容，最后 OCP 精细的 SQL 级别运维与告警体系，能够有效降低故障的持续时间。综合来看，系统可靠性能够得到提升，并以此为基础推进应用层高可用、可扩展的架构体系建设，以满足未来业务扩张、需求增长的系统需要。

图12    分布式路线及高可用设计

兴业证券在前期选型的过程中，验证了不同数据分布情况下的数据库表现，而在实际应用中面对的场景会更加复杂，另外自研数据库相对传统数据库，在优化器性能及稳定性、配套工具能力支持上还存在一定差距。因此，通过收集整理各应用实际适配过程中遇到的问题，完成分布式数据库的知识库建设，并不断排错调优，积累经验，最终形成分布式数据库应用改造最佳实践，在保障安全生产的同时，提升业务适配改造效率，为信息技术应用创新工作的全面开展铺平道路。