实战案例 | 兴业证券分布式数据库云应用实践

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

1.应用资源评估

（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台的模式进行适配优化，提前暴露跨机查询可能存在的问题，并寻求解决方案。

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

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

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

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

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

 （3）资源评估模型

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

2.应用适配

（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，这能提升开发适配阶段的问题定位效率。

（4）数据迁移方案制定

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

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

（5）数据备份策略制定

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

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

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

（6）应用部署及测试

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

（7）生产上线

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

2.常见问题

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

分布式数据库应用成效