文/兴业证券信息技术部陈林林
兴业证券金融科技部李凡
数据库技术作为信息技术应用创新过程中的一项重要技术，其面临的难题也是亟需解决的关键问题。兴业证券在《集团五年金融科技规划》中提出，要以信创架构评审为抓手，制定信创规划和建设方案，以高可用性、开放成熟、架构标准化、连续性和易迁移、技术先进性、行业监管合规为架构设计原则，完成信创基础架构规划，形成信创架构管理规范，打造稳定高效安全的信创基础软硬件技术路线，为金融数字化转型及自主可控提供有力支撑。兴业证券在保证数据库一致性、可靠性、高可用的前提下，完成信创分布式数据库建设，具备快速交付、动态扩容的能力，能够高效地应对业务的需求。本文重点介绍兴业证券分布式数据库标准架构、应用资源评估模板、应用适配最佳实践等工作内容，积极为行业侧提供系统性、制度性的分布式数据库解决方案，为行业和产业生态贡献力量。
分布式数据库标准架构建设
1.分布式数据库核心技术能力
分布式数据库，通常通过复制和冗余机制来提供高可用性；通过将数据分布在多个节点上并行处理来提供高性能；根据负载情况分配和调整资源提供可扩展性；通过一致性协议和分布式事务机制来保证数据一致性；通过数据加密和访问控制等安全机制来保护数据的安全性。
2.分布式数据库标准架构
兴业证券分布式数据库采用全栈信创技术部署，通过搭建OceanBase数据库集群，结合OceanBaseOCP的资源管控能力，形成云化数据库集群，提供分布式数据库资源的能力。
结合集群内多副本高可用和主备库流复制两种方案，兴业证券在同城与异地部署了1：1同构的OceanBase数据库主备集群，为接入应用提供本地节点级高可用和集群地域级容灾能力。每个集群有自己单独的PaxosGroup，保证集群内多副本一致性，每一笔写事务必须到达半数以上服务器才生效。因此当少数服务器故障时，不会有数据丢失。集群间通过物理日志做数据同步，形式上类似传统数据库"主从复制"模式，从主库"异步同步"到备库，类似OracleDataGuard中的“最大性能”模式。
图1OceanBase容灾架构基本部署单元
随着接入应用的增加，租户数增加的同时集群规模也会同步增加，单个集群内部署的租户建议控制在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共线程的环境，高峰期CPU使用率20%，实际使用20线程，考虑自研CPU单线程处理能力，大约实际需要40线程，再考虑CPU安全水位（生产环境建议白天交易时段不超过30%），CPU建议分配C。
内存：对于联表查询较多项目，建议内存为CPU线程数的4倍可达到最佳实践。普通项目通常按照2倍CPU分配内存即可。
架构：服务器单节点CPU线程最高，但考虑随项目发展，资源需求可能越来越高，超过C时，将租户扩为2unit，此时会涉及跨机SQL，因此在开发阶段，直接以2unit或primaryzone打散到2台的模式进行适配优化，提前暴露跨机查询可能存在的问题，并寻求解决方案。
图2AWR报告示例
图3运行监控示例
新建系统资源估算。与存量系统不同，新建系统的负载较难预测，初期分配的资源未必是终态，这要求应用在上线时就要想好后续的扩展方案，但在实际中，要求每个新建系统具备该能力，与系统迭代上线的需求又有矛盾，因此，分布式数据库的扩容和缩容能力，是高效支持新建系统的关键。
对于新建系统的初始资源规划，可从如下几个方面考虑，包括数据增量、访问负载特点及性能和响应时间要求：
数据量和负载预测：评估数据库所需的硬件资源首先需要考虑数据量的大小和负载的预测。根据应用系统的数据量和负载情况，确定数据库需要处理的数据量和并发访问量，以此为基础进行硬件资源的评估。
性能和响应时间目标：评估数据库所需的硬件资源还需要考虑性能和响应时间的目标。根据应用系统对响应时间的要求，确定数据库需要提供的性能指标（如每秒查询数、并发连接数等），以此为依据评估硬件资源的需求。
以某智能平台为例，该系统面向公司内部员工，数据量会有逐步增长的趋势，以简单查询场景为主，特定时段会有一定的并发量。测试环境中，先分配4C8G资源先行验证，测试情况显示CPU高峰期使用率29%，内存高峰期使用率49%，初步评估后建议以8C16G为初始资源投产，后续根据实际使用情况动态调整租户规格。该系统资源量属于单机可以承载的情况，数据副本建议不打散，在单OBServer中，可避免跨机开销。
图4CPU、内存三副本使用率监控
（3）资源评估模型
基于上述系统评估、开发、上线的实践经验，我们编写了适用于OceanBase数据库的资源评估预测模型，项目组申请资源时，根据其需求（QPS、数据量、负载类型、对象数量、数据增长情况、业务架构、灾备需求等因素），量化出适合的租户资源与部署形态。
图5分布式数据库资源评估模型
虽然预测无法做到绝对精准，但得益于数据库资源管理的便捷性，各系统在使用中如发现性能瓶颈或资源使用率较低，可在线增大或减少租户资源，在安全生产的前提下提升资源利用率，最终本次适配的二十余套应用以8C16G资源需求较多，部分仅需1.5C6G，少数需要32C64G以上。对于租户类型，具体比例如图6所示。
图分布式数据库租户类型占比
2.应用适配
（1）数据库驱动及连接池工具
对于原先使用MySQL的系统，可沿用原驱动；新建系统以及原本使用Oracle的存量系统，则使用OceanBase数据库官方驱动最新版。
按照兴业证券组件版本规范，连接池工具推荐使用HikariCP对应稳定版本。
（2）库表设计及调整
数据库表设计需遵循兴业证券数据库开发设计规范，操作细节可参考OceanBase开发指引。其中关键注意事项如下：
分区字段选择：数据量快速增长的流水表必须使用分区，尽量选择业务最常用的查询字段作为分区字段；
表组：分区字段相同的表，可创建为同一个表组，可尽量规避分布式开销；
分区数控制：原本依赖按天分区的系统，迁移后需重点