从证券行业的数据库实践，看OceanBase的优势是什么？

过去，因为国内数据库技术起步晚，以 Oracle、DB2 为代表的数据库产品几乎占据了整个券商行业的各类核心业务系统。而当时国产数据库多处于“萌芽”状态、起步发展阶段。

但或许所有人都没想到，随着中国国产数据库开始崛起，国产分布式数据库找到了最适合自己的突破口，并以证券金融行业为起点开始“绝地反攻”。

在金融级数据库领域中，100%自主研发的分布式国产数据库OceanBase，正得到越来越多企业的认可。但OceanBase是如何一步步在证券行业落地实践的？今天我们就来聊一聊。

面对不同基金资管的业务架构，OceanBase如何实现？

第一种：对客查询系统，终端用户通过券商/基金的直销渠道或互联网分销渠道执行买入、卖出、查询等请求。

针对资管系统的对客查询模块，虽然 SQL 基本都带有“用户ID ”这类信息作为等值条件，但其 SQL 往往不是简单的点查，而是带有去重排序等各类计算以及多表 join 的中等复杂 SQL。

在此情况下，OceanBase 的分区表+TableGroup+复制表可尽量将 join 中的相同数据放在同一个节点，减少分布式系统下带来的跨机 RPC 请求，同时 OceanBase 的一体化设计能尽量避免计算过程中的数据 merge。综合多方面特性，OceanBase 在此类场景下能够提供高并发低延迟的查询能力。

第二种：TA 登记过户系统。登记用户交易请求，在每笔交易链路中，根据资产估值计算用户的实际买入份额与卖出金额；在用户与交易两个维度进行批处理。

该系统涉及用户记录与交易记录两个维度，同时部分清算必须以串行方式完成，因此架构上较好方案是单元化，从而提升整体批处理效率并且保证硬件资源利用率。而OceanBase数据库具备良好的 AP/TP 负载隔离能力，刚好能满足其需求。

第三种：估值系统，在计算资产的净值、利息收入，资产维度批处理等事务中，此时OceanBase 采用了比生产多一倍的数据进行跑批压测，在国产芯片的 2-2-2 集群环境中，可在 6 分钟内完成。

第四种，针对大量大事务，复杂查询的投资分析系统，线上常见的问题是偶发的执行计划走错，导致复杂查询 SQL 时间变长，该问题在 Oracle 数据库也是常见的影响性能的因素之一。

而OceanBase 支持通过 HINT 来描述具体如何固定计划，并具备绑定执行计划的能力，更进一步，当前 OCP 3.2.1 版本已支持白屏绑定历史执行计划，可以大大降低线上环境复杂 SQL 计划调优的操作风险与复杂度。

面对证券行业的意外容灾，OceanBase如何进行部署架构？

除了不同基金资管的业务架构，证券行业还存在着一些意外容灾，比如在线类交易业务对业务连续性有较高的要求，因此证券行业需要定期做各类高可用切换演练。

在此背景下，OceanBase 提供了集群级别的主备能力，针对双机房场景提供机房级别高可用能力。对于机房切换演练，带生产数据进行切换演练时，可通过 switchover 将主备集群的角色互换，演练结束后业务负载回到主机房，数据库侧则再次执行 switchover。不带生产数据做演练时，则将第二备集群与主集群解耦，让其独立为一个单独的集群，测试数据运行完后，重建该备集群。

此外，证券行业T+1 类交易业务则对数据一致性有较高要求，因此需要数据跑批稳定、不出错。这时候，OceanBase 集群内的高可用能力就发挥出来了。OceanBase集群在同机房内部署，其提供的高可用能力与效果可认为是一组节点扩展能力上限更高、没有存储单点风险的 Oracle RAC：无需人工或外部工具参与的自动故障转移、多节点多活提供服务、添加节点即可完成资源自动扩展。

OceanBase诞生于严苛的金融核心场景，已连续9年平稳支撑“双11”活动，能力得到了充分“历练”。并且在过去一年多的时间中，OceanBase得到了诸多行业头部客户的认可，TOP 200金融机构中四分之一是OceanBase的客户。

从今天的文章也能发现，顺应证券行业数字化转型提速的趋势，OceanBase一直在加大技术研发力度，持续提升产品性能，助推其数智化转型。