2024年金融数据库转型方法论报告

中国太保数智研究院首席数据库专家林春 2018~2021年金融行业数据库市场态势 n分布式数据库产品尚需金融业务场景打磨，尚无100%成熟的分布式数据库产品。主要体现在数据库产品BUG数量较多、金融业非功能性需求适配、数据库开发及运维管理平台不够友好和数据库周边工具功能不足等方面。存量Oracle数据库迁移改造存在痛点，主要体现在应用适配评估工具需提升、存储过程改造工作量较高、迁移工具性能及稳定性需提升等。 n不同的分布式数据库各有优劣，需根据具体业务场景适配。市面上主流的分布式数据库分为基于proxy的分布式数据库和原生分布式数据库。原生分布式数据库产品具有对应用侵入性少等优点，但是比起基于proxy的分布式数据库需要有更多的代码研发和改动，数据库产品可靠性方面需要更多的验证；而基于proxy的分布式数据库也面临如何将底座集中式数据库新版本的新特性整合的问题。 n分布式数据库产品处于可用向好用的演进中间状态。分布式数据库厂商的数据库产品内核掌控及bug修复能力、应用改造成本及软硬件成本综合成本需要关注。 n分布式数据库产品呈现多条技术路线同时快速发展的态势。金融企业在分布式数据库选型上和使用上需要采取高度兼容的策略，结合业务场景需求，在选择通用性兼容及生态较好的分布式数据库产品后，需要考虑在应用开发中简化、优化、标准化SQL，在适配分布式数据库特点、提升应用性能的同时，做到技术产品灵活可控。 n中国太保集团开始探索核心系统使用国产数据库。 2021~2024年金融行业数据库市场态势 n国产分布式数据库产品加速分化，头部数据库产品趋于好用，加速形成完善生态。国内数据库产品最终会分化为头部两三家、中间四五家数据库厂商的明朗格局。 n头部金融企业核心系统产、用联合攻坚是加速产品向好用演进的孵化器。数据库数字化转型不是单靠厂商或用户就能独立闭环完成的，头部金融企业需要提供核心金融场景以及业务侧、应用侧、产品侧无解时的解决方案；攻坚厂商需要有能对数据库内核代码研发掌控的能力，应用改造还是产品改造需要从稳定性和成本角度合理化权衡；数据库数字化转型替代不是数据库产品层面1：1的替代，需要合理拆解；数据库数字化转型方法论、工具创新需要从实践来到实践中去，做到“产品无解，问题有解”。 n头部金融企业核心系统攻坚催熟数据库生态。头部金融企业核心攻坚成功会起到标杆示范效应，会在催熟数据库产品、解决方案的同时，给更多项目组、企业信心去使用产品，从而形成越用越好用的良性生态循环。 n在稳定性前提下数据库数字化转型改造成本战略。oracle核心代码、技能是企业积累的宝贵资产，国产数据库产品从降本角度，需要考虑对Oracle功能、性能兼容，实现平滑迁移；金融企业需要考虑数字化转型既快又省，同时兼顾远期业务发展的底座支撑，“攻坚牵引、改造前置、架构优化、工具创新、知识沉淀”是降低数字化转型成本尤其是应用改造成本的有效手段。 我司数据库数字化转型成果数据库转型是数字化转型的核心，其成果包括：架构转型、降本、创新和能力沉淀四个方面。 架构转型 降本显著 •OceanBase具备非常好的存储压缩能力，平均压缩到原来1/3~1/4，服务器硬件扩容需求下降明显，备份、恢复性能提升5倍。•OceanBase对Oracle、MySQL有良好的兼容性，且应用侵入性弱，大幅降低应用改造、数据库迁移成本。•实现了MySQL、Oracle版本同集群部署、同OCP管控，实现多形态数据库逻辑集中、管控整合，大幅提升了资源利用率以及降低了运维成本。 •我司数字化转型，核心、重要系统多为OceanBase。实现从原来的集中式架构向分布式架构转变，具备良好的扩展性，在面对瞬时海量高并发互联网业务场景具备良好的弹性扩容能力，满足未来业务增长发展需求。•硬件故障自动切换时间在13秒内，全面提升业务连续性水平 能力沉淀 技术创新 •形成并不断迭代完善信信息应用创新数据库知识库，目前知识库沉淀问题已超过1000条；•形成完善的集群设计规范、数据库开发规范等知识体系；•以P17核心攻坚、资金系统等大量复杂系统上线，培养了国产数据库研发及运维队伍。•推广国产数据库培训，全集团获得OceanBase数据库认证人数达到1135人。通过OBCE上机实验考试并保持上机考试成绩最高记录；入选OceanBase用户专家委员会(OCEC)。 •工具创新：研发数据库数字化转型评估工具、索引优化助手并经营化，降低数据库数字化转型应用改造成本约20%；•大库改造创新：企业信息视图45TB大库首创行业分布式数据库架构，解决保险大库存储瓶颈，并应用到产险销管、费控系统，目前运行稳定；•方法创新：形成了大库改造评估方法论、重负载系统国产服务器CPU瓶颈优化方法论、重IO负载系统优化方法论等 数字化转型改造降本方法论 重负载场景下CPU性能瓶颈优化方法论 通过应用侧极致优化，形成可推广的优化范式，可以很大程度上弥补硬件CPU性能不足，可以很好承载重负载系统 太保产险车险理赔核心系统数字化转型成果 险车险理赔核心系统每日案件量约20000件，作业人员总量20000人左右，系统业务流程包含报案、查勘、车估损、车核价、车核损、单证、理算、核赔、人伤首次、人伤跟踪、人伤调解等 太保产险车险理赔核心系统技术攻坚点包括： 车理赔系统采用案卷模型作为理赔业务数据模型基础，通过案卷树与节点扩展存储理赔数据。案卷模型由横表、竖表关联查询，系统查询次数成指数级上升，存在大量高频查询SQL，主节点QPS峰值超过11万。2 全理赔流程复杂、高频交易、存储过程庞杂、且业务数据量高达近50TB。1 优化成果： 优化前，数据库服务器CPU使用率平均超过90%，峰值超过95%，经过一系列优化后，效果明显，CPU负载平均降低30%左右。 SQL优化案例1 SQL分析 select dispatchta0_.id as id1_53_,dispatchta0_.bo_actual_id as bo_actual_id2_53_, dispatchta0_.claim_variable_id asclaim_variable_id3_53_, dispatchta0_.create_time as create_time4_53_, dispatchta0_.memo as memo5_53_, dispatchta0_.message asmessage6_53_, dispatchta0_.notification_no as notification_no7_53_, dispatchta0_.proc_inst_id as proc_inst_id8_53_,dispatchta0_.status as status9_53_, dispatchta0_.task_def_key as task_def_key10_53_, dispatchta0_.task_id as task_id11_53_,dispatchta0_.task_variable_id as task_variable_id12_53_, dispatchta0_.top_actual_id as top_actual_id13_53_, dispatchta0_.update_timeas update_time14_53_ from TEST_TASK_PARA dispatchta0_ where 1=1 and dispatchta0_.status='0' and mod(dispatchta0_.top_actual_id, 13)=4and rownum<100 order by dispatchta0_.id asc SQL优化案例1 优化分析 •表调度任务参数表TEST_TASK_PARA没有太好的筛选条件，走了全表扫描，预估记录数32，而扫描包含删除记录达到52480，这个表数据量很小，只有几十条，但是存在大量的删除操作。•删除一个表上记录，该国产数据库中不会物理删除，而仅是在内存中对应记录加上删除标记，直到该国产数据库做每日合并时才会真正删除，这样就导致表调度任务参数表做全表扫描时扫描大量已标记删除的记录，查询性能下降明显。•针对小表大量删除引发扫描大量标记删除记录、导致查询变慢的场景，可以使用queuing表模式，在queuing表阈值删除记录达到阈值时，则会触发转储，就可以避免原有的大量无效扫描动作。•数据库中可能存在多个queuing表，各个表的删除频率可能是有很大差异的，更合理的设计是，应该允许在queuing表级别设置删除转储属性阈值。 SQL优化案例2 SQL分析 extended select runtimeuse0_.id as id1_68_, runtimeuse0_.dispatch_task_type as dispatch_task_type2_68_, runtimeuse0_.task_def_key astask_def_key3_68_, runtimeuse0_.task_state as task_state4_68_, runtimeuse0_.task_variable_id as task_variable_id5_68_,runtimeuse0_.task_weight as task_weight6_68_, runtimeuse0_.unit_code as unit_code7_68_, runtimeuse0_.user_code as user_code8_68_,runtimeuse0_.user_group as user_group9_68_, runtimeuse0_.count as count10_68_, runtimeuse0_.create_time as create_time11_68_,runtimeuse0_.memo as memo12_68_, runtimeuse0_.status as status13_68_, runtimeuse0_.update_time as update_time14_68_from bpm.TEST_TASKCOUNT_DETAIL runtimeuse0_where 1=1 and runtimeuse0_.status='0' and rownum<1000 order by runtimeuse0_.id asc 执行计划如下： SQL优化案例2 优化分析 •表TEST_TASKCOUNT_DETAIL预估记录数2704，而扫描包含删除记录达到100704，查询性能较差，且该表已经设置为queuing表，检查表转储情况，可以发现表TEST_TASKCOUNT_DETAIL在高峰时间段存在大量转储，高峰时间段不到1小时转储达28次。•目前queue表转储存在痛点如下：TEST_TASKCOUNT_DETAIL高峰时间段转储频繁,转储删除阈值为30000，但是提高 _ob_queuing_fast_freeze_min_count阈值设置会导致其他queuing表无法及时转储；而降低_ob_queuing_fast_freeze_min_count阈值又会导致TEST_TASKCOUNT_DETAIL表转储过频，从产品侧没有很好解决方案。 •应用侧优化方案如下ØTEST_TASKCOUNT_DETAIL设置deteled_status字段，删除时将该字段设置为1，否则为0。 Ø在delete_status字段上增加索引如下：create index status_idx on TEST_TASKCOUNT_DETAIL(case deleted_status when ‘0’ then ‘0’end);Ø在应用改写SQL如下：Where status=’0’ and (case deleted_status when ‘0’ then