从风控核心数据库到AI数据底座与AIOps智能体系OceanBase 在这一演进中扮演越来越重要的角色。作者夏平信也科技DBA负责人信也科技[FINV]作为纽交所上市的金融科技集团受最严格的监管对数据合规、隐私保护与系统安全有着极致的追求。比如绝对的数据一致性。涉及全球资金交易任何情况下的主备切换或故障恢复都必须保证数据零丢失。极致的高可用。在机房级故障时业务能实现秒级接管。应对突发流量的极致弹性。面对全球多市场的突发业务洪峰底层数据库必须具备在线平滑扩容的能力。依托于海量数据与前沿AI技术信也科技打造了行业领先的智能风控体系支撑高频、复杂的金融交易场景业务版图已从国内成功延伸至东南亚、澳洲等全球市场。与此同时也面临跨地域、多时区、高并发的复杂技术挑战。历史架构痛点传统MySQL分库分表的技术挑战信也许多业务最初使用MySQL分库分表方案支撑在该方案中以下四个痛点对DBA而言应该并不陌生。**第一研发效能黑洞跨库查询与分表治理问题。**我们内部有一套面向研发的自动化平台但当分表数量较多时排查问题需要做跨分片聚合查询往往需要DBA协助流程比较繁琐。而且大部分业务代码被迫适配中间件逻辑严重拖累敏捷迭代的交付节奏。**第二扩容如履薄冰极高运维风险。**一方面随着业务持续增长分库分表方案最终必然面临扩容需求。长期来看分片维护等工作相当枯燥且存在扩容窗口期的风险。另一方面面对突发流量洪峰分库分表后的数据Rebalance耗时极长。操作极其繁琐而且极易引发线上业务剧烈抖动扩容变高危。**第三成本指数膨胀单机容量触顶。**原有的MySQL系统容量和压缩能力有限随着海量历史冷数据堆积SSD存储账单呈指数级飙升同时闪迪SanDisk、美光Micron等存储厂商的股价上涨也反映出内存和存储硬件的涨价趋势给企业成本带来较大压力。**第四敏捷迭代绊脚石DDL变更阻塞。**成百上千个数据分片形成了“管理孤岛”导致我们对分库分表做表结构变更如加字段、改结构等不仅相当麻烦而且耗时数周很难做全局统一管理。目前主流方案是GH-OST做在线DDL但其在切换时有一个短暂的锁表动作即使放在业务低峰期仍可能导致线上事故。我们曾采用的一种改进方案是在高峰期暂停DDL操作等窗口期再恢复。但暂停期间会产生大量vlog采用MySQL原生方案时可能导致程序卡死。后来我们调整为DDL仅在低峰期执行过了窗口期后持续等待下一周期以此规避风险。分布式数据库选型历程从TiDB到OceanBase我们最初并没有主动考虑数据库选型的问题。随着数据不断膨胀MySQL分库分表的方案反复面临扩容和成本挑战。当时的解决思路之一是将冷数据迁移到成本更低的存储系统。在选型早期我们调研过TiDB因为一些原因最后放弃使用。后来了解到TiDB的TiKV方案但实际使用效果并不理想。恰逢OceanBase开源我们将其纳入调研范围使用后发现效果不错与我们内部的自动化平台融合度较高。选择 OceanBase 主要基于三点**存储成本降低。**OceanBase 采用与 MySQL 相同的 LSM-Tree 算法但在压缩层面做了深度优化显著降低了存储成本。**弹性扩容便捷。**作为分布式数据库当归档集群资源不足时可以平滑地增加几台 OBServer 节点即可解决问题操作简单。**金融级高可用方案。**作为互联网金融企业对数据一致性要求极高OceanBase 的金融级高可用架构满足这一需求。如何推动研发团队使用OceanBase选定产品后推动研发团队使用是另一大挑战。研发人员没有业务诉求或上级压力时通常不会主动更换正在稳定运行的MySQL方案。如何保证迁移后的性能表现是打消顾虑的关键。OceanBase 提供了不错的配套工具迁移评估工具OMAOceanBase Migration Assessment可以提供精准的语法兼容性评估。基于全链路压测思维制定详尽的割接 SOP。在迁移前我们可以利用 OMA 抓取源库真实业务流量并在目标库进行仿真回放预知高并发下的性能风险与锁冲突。迁移服务OMSOceanBase Migration Service****配套完善支持实时同步和反向同步。这样一来建立稳固的全量 增量实时数据同步链路在割接窗口期配合数据实时一致性校验确保新旧库数据绝对平齐。割接的最强底气在于开启从 OB 到源库的逆向同步链路并保持老库数据实时鲜活为随时可能的紧急回滚提供待命的底座。我们主要采用两种方案一是通过OMS同步后在低峰期做割接二是通过研发控制双写这是目前使用较多的方案。双写方案回滚方便可分别控制读和写通过灰度流量验证一旦灰度期间监控发现异常无需重启应用直接通过配置中心一键拉回流量实现秒级无损切回真正做到进可攻退可守。实战破局从核心业务场景落地到自动化运维技术升级实现降本增效、高可用、高可靠1极致降本LSM-Tree引擎对海量数据的存储重塑使用OceanBase后告别了传统MySQL B树的页分裂与空间碎片采用LSM-Tree存储引擎将随机写转化为顺序追加写实现极致的写入性能与双层数据压缩。**89TB的数据被压缩至29TB存储空间节约67%。业务场景一历史存量业务(冷热分离)。存量数据的日常访问频次极低且无法下线占用着大量昂贵的SSD存储资源。我们考虑将部分数据迁移到OceanBase利用其极致压缩能力将海量数据在线归档。在不影响偶尔查询的前提下大幅削减硬件成本实现“冷热数据”高效治理。业务场景二营销投放业务(高频并发)。这是一个典型的写密集型业务流水产生极快且因合规与对账要求保留周期极长极易引发容量危机。在MySQL分表方案中每台机器配置两块数据盘使用压力经常达到85%。DBA需要频繁做归档和表空间收缩运维压力很大。OceanBase采用LSM-Tree架构增量数据写入后通过定期合并完成空间回收无需手动收缩整体运维压力大幅降低。值得一提的是OceanBase“内存追加写”特性完美消除高频写入的I/O瓶颈底层高压缩比彻底瓦解长期保留的容量焦虑让业务敢于记录详尽流水。2.同城双活架构与极致高可用实践业务场景三同城双活演练。**我们每年进行两次同城双活演练两个机房之间将流量和数据库全部切换。备租户 (Standby Tenant) 容灾体系。打破传统主备架构局限基于底层 Redo Log 异步/强同步传输实现跨机房的“租户级”物理容灾。无论遭遇多极端的机房级故障坚守底层数据零丢失的绝对红线。“切浦江”常态化双活演练。告别纸上谈兵将主备角色平滑互换演练融入日常运维。结合业务流量管控与紧急回滚预案验证全链路可靠性确保极端场景下核心交易流量接管无感丝滑。在演练过程中MySQL及其他关键数据库会出现抖动对业务有一定影响。公司管理层也在关注如何将切换影响降到更低、更平滑。OceanBase的架构天然适配这一需求通过OBProxy和Service层访问切换更加丝滑。但需要注意的是早期版本如V4.2.0.5在OBProxy层面不够成熟。我们曾在大数据抽数场景中遇到问题分布式架构下只能通过OBProxy访问但抽数时某些SQL执行计划不佳影响线上业务。后来了解到当时使用的版本存在一个Bug导致主集群卡死只能重启。对于核心业务这种影响非常大。因此如果线上核心业务使用OceanBase强烈建议配置OBProxy。3.资源池化与多租户架构打破物理孤岛实现极致弹性业务场景四多租户资源隔离。很多DBA在银行类金融场景下按需开机器、部署交付即可但需要思考成本与交付的平衡。当前的痛点是研发强调业务重要要求独立资源。我们目前采用物理机部署对于业务压力并不高的“核心”业务只能给三副本5TB存储造成资源浪费。同时多条业务线部署在同一组物理机上某个业务线的慢查询接口可能影响其他业务。OceanBase的多租户能力可以解决这一问题。告别物理机孤岛打破传统架构按“峰值”预占硬件的痛点实现资源池化管理。按需动态分配 CPU/内存彻底消除物理机闲置造成的成本浪费。租户级物理硬隔离通过底层的 CPU 绑核与 IOPS 阈值控制实现租户间的物理级硬隔离。确保营销等高 I/O 业务突发打满时核心交易链路绝对不受“噪音效应”干扰。分钟级动态扩缩容以 Unit 为最小迁移单位实现业务零感知的在线扩容与缩容。轻松应对跨地域、多时区的突发业务洪峰与节假日高并发。使用OceanBase后整体资源利用率提升40%新业务节点部署周期缩短90%。此外对于如何避免资源浪费问题我们在早期采购机器时得到一个经验CPU核数买得太少存储配置较大导致CPU资源用完后仍剩余大量存储空间。建议采购时选择高CPU规格如96C与内存配比大约1:2。自动化运维与生态打通将新数据库纳入既有运维体系是一个常见问题。信也科技数据库种类较多包括MySQL、Redis、OceanBase、Elasticsearch等多种关系型和非关系型数据库。我们有一套面向研发和DBA的管理平台已将OceanBase的自动化流程纳入其中。在SQL变更方面我们采用双重验证机制通过OCP平台和内部工具进行交叉验证确认无误后直接执行如有风险则走工单审批流程。但工单执行也存在问题——大表改表操作耗时非常长业务方能否等待是一个问题同时改表过程中本身存在锁开销等风险。我们的做法是安排在每天21点执行如果到早上窗口期结束仍未完成则进行抑制操作暂停DDL避免影响业务。在开发平台方面我们参考了阿里云的建表体验将开发规范内置到平台中研发人员无需关心索引、表备注、字符集等规范细节只需填写表名、备注和字段类型提交后平台自动处理。一个重要的经验教训是早期未配置OBProxy时在大数据抽数场景中复杂查询任务直连主租户(Primary Tenant)。凌晨抽数高峰期引发大面积全表扫描导致主库CPU飙升、I/O触及瓶颈严重威胁核心交易链路安全。后来我们将所有离线抽数、报表分析流量无缝引流至备租户(Standby Tenant)彻底实现底层读写分离物理隔离OLAP与OLTP主库性能稳如磐石。一次线上故障与复盘近期发生了一次线上故障处理经验供大家参考。背景是研发同学反馈线上出现问题排查发现某条SQL虽已有索引但未按索引执行于是进行了执行计划绑定操作。执行计划绑定存在一个隐患OCP平台上展示的执行计划可能有多个如A、B、C三个操作时平台会将三个全部标记为绑定状态但底层数据库实际上只绑定了其中一个。当时操作人员看到平台显示绑定了三个认为是误操作立即取消了绑定。此时执行计划已落入全表扫描路径数据库压力瞬间飙升业务出现“雪崩”。我们的应急处理过程是第一步解绑但解绑后并未恢复因为错误的执行计划已产生全部走全表扫描。第二步做限流也未能起效。第三步切备库切到备库后旧连接上的请求仍在原库执行新连接到备库后逐步恢复。对此我们复盘后得出几个要点深入理解底层实现不要盲目相信 OCP 平台上的显示信息需要到数据库底层查看对应表确认是否真正绑定了目标执行计划。完善上线前的 review 机制在测试环节识别有问题的接口拦截问题代码发布到线上。建立快速止血能力在平台上提供快速 kill 会话的能力降低故障影响时长。同时也总结了两个DBA避坑硬核心法。一是拒绝盲信 UI 工具任何工具都有黑盒盲区。执行计划绑定后必须切回黑屏查询 GV$OB_SQL_OUTLINE 确认真实的物理执行路径二是敬畏数据硬核复核挑选历史计划时绝不可单看平均耗时最短这个单一维度谨防极端极少样本导致的性能假象。未来规划探索一体化向量底座与全自动运维我们在2024年开始使用OceanBase从特定场景到核心业务依次上线基于其在这两年的稳定表现我们计划持续扩大OceanBase的使用范围。例如将部分MongoDB支持的业务场景迁移到OceanBase以降低数据库成本。未来我们还将基于OceanBase优化AIOps、重塑归档体系、演进一体化向量底座。1.从手工救火到AIOps智能自愈体系的蜕变如何将OceanBase与自动化运维体系及AIOps深度结合实现数据库问题的自动判断甚至自愈这是我们要解决的问题目前已有巡检系统可以检测隐患与风险但治理工作仍依赖DBA人工处理。未来我们希望实现巡检发现问题后自动治理以及报警触发后自动分析并给出执行路径经DBA确认后即可执行。这对缩短故障处理时间、提升MTTR平均修复时间指标至关重要对DBA完成SLA如9999或99999的考核也有直接帮助。为此我们将通过三方面构建全链路治理体系。防线左移前置 AI 质量拦截。自动化 SQL Review 平台引入 AI 辅助代码审核在研发流水线中精准识别并提前掐断易引发“全表扫描”的劣质计划。极速响应智能 RCA 与自动止血。打破传统堆砌告警模式构建基于监控日志的智能根因分析 (RCA)。实现“诊断-止血”联动将人工排查时间从分钟级压缩至秒级。底盘稳固演练与黑屏 SOP。沉淀极端场景下的应急经验针对复杂故障强化团队黑屏排雷与实操能力知其然更知其所以然。与此同时探索基于大语言模型Agent的数据库常态化巡检结合历史负载特征实现数据库底层参数的动态自适应调优。逐步落地智能化故障自愈机制从“被动响应”向“主动防御”演进极大降低业务连续性对人工经验的依赖。2.重塑归档体系从底座演进到全链路自动化治理冷热数据分离是线上频繁使用的场景数据分离后仍需保留以满足审计或业务需求。以往我们的做法非常笨拙通过rename方式定期清理过期数据并重建新表。使用OceanBase后可以按分区进行添加和删除操作非常丝滑。还可以按时间要求定时执行归档支持不同租户或实例串行归档也提供并发数和优先级支持。考虑到我们在东南亚菲律宾、印尼、澳洲、非洲等地区都有业务OceanBase还支持归档时配置不同存储介质满足当地数据驻留的合规要求。最初我们使用InnoDB处理数据归档引发主库CPU资源争抢性能与容量难以兼得后来引入TiDB带来了高昂硬件成本与复杂运维负担现在使用OceanBase彻底统一在线交易与历史归档技术栈自动化维护分区全生命周期带来了海量历史数据存储成本骤降70%、主租户核心库查询性能跃升30%的效果。3.AI Native一体化向量底座与业务展望如今信也内部推动“All in AI”DBA团队的相关后台系统已100%使用AI编写AI平台和开发团队将向量数据库作为存储底座。在AI趋势与业务需求的双重压力下我们计划探索将OceanBase作为一体化向量底座的效果比如在海量数据场景下替代PostgreSQL以及在智能风控场景使用OceanBase的向量相似度匹配精准捕捉跨业务线的隐秘欺诈团伙提升风控模型的召回率与时效性。OceanBase向量功能迭代迅速在4.3.3 GA版本推出SQL 向量一体化检索架构无需异构同步确保数据实时强一致与金融级可靠性。如今已支持HNSW、IVFFlat等主流索引可承载16000维超高维检索满足大模型长文境需求据官方透露后续版本的向量能力将有更大提升。对于我们来说OceanBase最大的优势在于一个数据库同时处理关系型、KV及向量数据极大降低AI原生应用的开发与运维复杂度。AI 大势所趋对 DBA 提出了新的技能要求。在与阿里云团队交流时了解到他们通过海量故障数据构建知识库并存储在向量数据库中当故障发生时通过向量搜索匹配标准 SOP再分发给相应人员处理。所以我们将构建基于 RAG 的运维知识库实现故障特征的秒级检索与自动化处置。同时依托OceanBase的一体化底座简化技术栈降低 AI 落地门槛实现从“数据治理”向“AI 资产赋能”的跨越。添加社区小助手加入微信交流群~立即试用 OceanBase 企业版体验国产数据库能力立即试用 OceanBase 企业版体验国产数据库能力
