金融行业正在面临前所未有之大变局。近年来，数字化转型已经逐步从头部金融机构带动效应下的“选择题”，发展成为几乎所有金融机构需要面对的“必答题”。随着全面迈入数字经济时代，数据量正在从TB级跃升至PB级，甚至ZB级。IT领域“旧瓶”（旧的数据架构）难装“新酒”（新的数据量级），数字化转型需要一套现代数据架构的有力支撑。而数据库相当于“大树”（数据架构）的“根基”，“根基”决定“果实”（数字化转型）的优良。立足当下，传统数据库已不能满足现代数据架构需求，金融机构急需彻底重构“根基”。

OceanBase诞生于金融场景，我们从2010年立项，写下第一行代码，坚持完全自主研发，到2017年完全承载整个集团的核心系统数据库，经历了7年的金融级场景考验与打磨。也正好在这一年，因为我们天然对金融场景的理解与共鸣，赢得了第一批外部金融客户的信任。伴随2020年OceanBase商业化的加速，我们已经覆盖70%资产规模千亿银行、75%头部证券、65%头部保险、45%头部基金（头部为Top20）。根据赛迪顾问《2022-2023 年中国平台软件市场研究年度报告》显示，OceanBase在金融行业的国产分布式数据库占有率位列第一。

正是因为有越来越多金融客户选择与OceanBase同行，我们对金融行业的理解不断加深、对金融场景实践的沉淀和思考也在不断深入。深耕金融14载，“根自研”是OceanBase负载关键业务系统、为金融客户需求兜底的最大底气，我们与上百家金融客户携手并肩沉淀出不少最佳实践，借此机会进行抽象、梳理与总结。一方面，以期收到更多金融机构对我们的反馈和建议，让“根自研”数据库OceanBase再进一步。另一方面，以期让更多金融机构少走弯路，在选型阶段，结合数据库技术发展趋势，选择更着眼于未来的技术路线；在迁移阶段，选择不同升级路径，用更低改造成本平滑迁移；在应用阶段，贴合创新场景发挥分布式数据库的更大效用等。

一、金融数字化转型，行至关键期

谈及数字化转型，如果说过去还只是头部金融机构带动效应下的“选择题”。那么现在，数字化转型已经成为不论大、中、小型金融机构都需要面对的“必答题”。

一方面是来自政策的推动。金融业一直是数字化转型“排头兵”。近年来，人民银行、原银保监会、证监会不断出台金融数字化转型相关政策，多方位加快推进金融数字化转型。其中，人民银行印发的《金融科技发展规划（2022—2025年）》明确金融数字化转型的总体思路、发展目标、重点任务和实施保障，到2025年力争实现整体水平与核心竞争力跨越式提升。

另一方面是整体战略逐步向“以客户为中心”转变的加速。过去，金融机构侧重销售产品和服务，是典型的“以产品为中心”，随着消费者需求的不断变化，以及内外部竞争加剧，全面转向“以客户为中心”已经逐步成为金融机构的战略共识。这也就意味着，金融机构需要具备足够强大、足够敏捷的数字化技术，为客户打造个性化、精准化、智能化的体验，这关乎未来可持续发展。

此外，还有数字经济浪潮的推进。2023年4月，国家互联网信息办公室发布的《数字中国发展报告（2022年）》报告显示，数字经济已经成为稳增长促转型的重要引擎，2022年我国数字经济规模达50.2万亿元，占GDP比重提升至41.5%，这一数字预计在2025年超过50%。当我国全面迈入数字经济时代，提前打好数字化基础的金融机构将抢占新时代的发展先机。

二、走向现代数据架构，数据库成为金融数字化转型关键环节

数字化转型的本质是利用数据重塑传统业务与组织模式，构建企业的新型竞争力。随着数字经济时代的到来，数据量正在从TB级跃升至PB级，甚至ZB级。根据IDC测算，我国数据总量预计2025年将高达48.6ZB，占全球总量的27.8%。如今数据总量的 “大”已经和过去不是一个级别，而在IT领域“旧瓶”是装不了“新酒”的，金融机构急需一套现代化的数据架构来作为数字化转型的支撑。

站在技术体系的发展角度看数字化转型，宏观上，海量数据的爆发来自于互联网的发展，业务的信息化、线上化爆点先从 SaaS 层开始，很快就触碰到了IaaS 层计算网络等基础设施的瓶颈，从而推动云计算和大数据平台的发展。当IaaS层和SaaS层发展起来后，PaaS层这种中间层的技术开始慢慢收敛、标准化，形成云原生、流/批计算平台、分布式数据库等配套的标准件。随着第二波AI、WEB3等革命的到来，SaaS 层又往下开始推动IaaS层实现新突破，比如算力、带宽、存储，进而促成新的PaaS 层迭代。IaaS、PaaS、SaaS 层的演进关系如图1所示。

图1 IaaS、PaaS、SaaS 层的演进关系

从微观上看，也是更偏技术架构的角度，其演进过程基本都是从最容易的、相对无状态的SaaS层开始。因为瓶颈出现后，SaaS层是最容易改造的，面对更多的需求、更多的数据、更快的迭代速度，SaaS层的解题思路就是从单体应用走向服务化拆分，再慢慢向云原生化演进。由于应用大部分是无状态的，整个演进的风险相对可控。

随后，来自业务和架构的压力很快从SaaS层传导到IaaS层，这一层虽然是有状态的，存储着关键数据，但离业务比较远，与应用间的关系更加弱耦合，基本都是通过标准接口进行交互。而且，云和新的存储、芯片以及网络层的发展并没有太多标准的改变。所以，在数字化转型过程中，IaaS层基本能够相对“透明无感”，在不影响业务的情况下升级为国产芯片、存储、服务器等，为上层提供更强大的弹性算力和更高资源利用率的虚拟化能力。

当SaaS层改变，IaaS层也紧跟着升级，剩下“最难啃的骨头”就在PaaS层了，这一层既与业务相关又有状态，往上需要承接SaaS层分拆后的分布式化的数据通信和运维管控，往下需要向与云底座相适配的云原生方向发展。而PaaS层中最难升级的又是数据库，无论是与应用的耦合度还是状态数据的重要性，都给数据库升级带来了巨大挑战。例如，金融机构的互联网业务经常面对脉冲业务的冲击，应用架构通过服务化架构和容器技术具备了更强大的数据处理能力和弹性伸缩能力，从而间接要求数据库具备海量数据处理能力和弹性伸缩能力，同时业务的分布式和垂直拆分要求数据库也是分布式的，但分布式有状态数据如何保证一致性，又如何应对大量数据库实例管理的复杂度……

这仅仅是数据库升级挑战中的冰山一角，我们已经无法用传统的数据架构来解决这些新问题。如果还是治标不治本，通过外挂或者各种外部软件与数据库软件拼装组合的方式来应对，只会让问题更复杂、风险变得更高。现代SaaS层应用架构和IaaS层基础架构的演进，都需要数据架构的根本改变，才能解决深层次的矛盾，才能应对现代业务场景的各种挑战。

数据库相当于“大树”（数据架构）的“根基”，“根基”决定了“果实”（数字化转型）的优良。传统数据库已然不能满足现代数据架构的需求，行稳致远，金融机构急需彻底重构“根基”。

三、金融行业面临的数据库升级挑战

1. 从边缘到核心，数据库升级全面提速

金融行业自20世纪70年代开启信息化建设以来便着手搭建核心系统，其作为金融机构的交易中枢，经过数十年的发展，在沉淀大量数据资产的同时，更是与周边系统盘根错节，可以说是“牵一发而动全身”。因此，大多数金融机构在开展信息化系统数据库新技术升级时，通常采取循序渐进、风险可控的策略，即先边缘系统再核心系统，不仅是为了逐步掌握新数据库技术，更是为了业务的风险可控。

“根自研”OceanBase自2010 年立项以来，已经累计服务了数百家金融机构，覆盖70%资产规模千亿元以上的银行，在证券、保险、基金行业的Top20资产规模企业中，覆盖率也分别为75%、65%、45%。其中大部分涉及核心系统数据库升级，尤其以头部银行、头部保险公司为代表的金融机构开始涉足“无人区”，率先进行核心系统数据库的分布式升级，并取得了不错的成绩。

以某国有大行为例，国内首个贷记卡核心系统“大机下移”分布式已经稳定运行一年有余，目前已有ECIF、对公网银等几十套系统数据库升级至OceanBase，传统核心也在基于OceanBase进行大机下移和单元化改造；以中国太平洋保险公司（以下简称“中国太保”）为例，其采取“先难后易”策略，自关联关系最为复杂、商业数据库绑定程度最深、业务影响最多的核心系统——“P17核心客户服务系统”（以下简称“P17”）投产上线以来，持续平稳运行，广泛服务于数千名柜面人员、百万业务人员和亿级外部客户，并将升级经验复制至其他系统，陆续有近80套系统数据库完成分布式升级。

从核心系统开始升级，有助于彻底抛弃原有的陈旧数据架构，更快地使用新数据库技术满足现代金融业务发展。当然，核心系统数据库在升级改造的同时，也伴随着边缘系统的数据库升级改造，并且得益于核心系统的经验积累，部分边缘系统上线更快。

这些先行者的尝试，已经验证了金融核心系统数据库新技术升级的可行性，并积累了大量的升级方法论。根据我们的经验，核心系统（含数据库）的整体升级大概需要持续2～3年。金融信息技术应用创新产业已经从边缘系统试点验证阶段向核心系统全面提速。加之时间窗口有限，核心系统数据库的新技术升级已经到了必须提上日程的时期。

2. 不同规模金融机构数据库升级需求各不相同

我们在服务客户时发现，不同规模金融机构结合自身IT水平、数字化能力以及人才组织配置等，在数据库升级时需求各异、各有侧重（如图2所示）。

首先，大型金融机构基础设施较好，对TPS、响应时间等各方面的要求较高，所以关注点不仅包括分布式，还包括完整的单元化分布式整体解决方案以及在分布式架构下如何构建高可用的技术风险体系。

其次，大型金融机构需要整体升级的系统较多，迁移的数据量也较大，所以重点关注整套迁移方案的安全性和改造成本，数据库针对原数据库的高度兼容以及完整的迁移工具是大型金融机构最关心的能力之一。

最后，一般大型金融机构的基础设施也比较复杂和多样化，要求数据库厂商能基本兼容所有主流的国产芯片，同时可以多芯片混部，服务器上也是一样，可以在不同的云厂商中部署数据库服务器，进行跨云协同。

图2 大型、中小型金融机构数据库升级的不同需求

 而对于中小型金融机构而言，其首先需要数据库具备分布式能力，但在使用上其根本不希望对此有感知，而是希望像集中式数据库一样使用数据库。所以原生的分布式能力尤为重要，这种架构避免了分布式的复杂性侵入应用，避免了分库分表改造和后期使用及运维上的限制。

其次，中小型金融机构更关注分布式数据库与应用厂商的适配，希望有应用厂商的兜底和大量案例，避免为升级底座而承担不必要的风险。要求数据库厂商与神码、长亮、中电金信等核心系统ISV，以及宇信、天阳、赞同、易诚互动等应用ISV完成适配。

再次，中小型金融机构非常关心服务和培训，以确保有足够的服务人员可以保障后续的日常服务。

最后，中小型金融机构期望在硬件条件比较苛刻甚至受限的情况下，提供成本可控的高可用方案。

3.不同用户数据库升级关注点各异

我们调研了若干家金融机构的科技总经理/CIO/开发人员/架构师/DBA/运维人员等，对于数据库产品，大家的关注点也各有侧重。总的来说，无论是架构升级还是自身能力迭代演进，首要目标都是确保稳定可靠，数据库升级过程要平滑，且可分层解耦、风险可控。

同时，作为基础软件的数据库，对应用系统的影响要尽可能做到最小，除了自身要提供完善的功能，还要对应用系统屏蔽自身的架构复杂度，让应用简单地使用数据库。比较一致的是，数据库要具备独立演进能力，保证技术栈的可持续发展和自主掌控。

（1）科技总经理/CIO的主要关注点：数据库是否成熟稳定，且能否带来额外效益

作为数字化转型的关键环节，数据库要支撑业务系统长期稳定运行，可靠且不丢数据。对于金融业务，尤其是核心业务，稳定性和可靠性是第一位的，做不到稳定可靠的“1”，再多创新的“0”也没有意义。

因此，数据库是否做到真正意义的自主掌控，保证供应链安全和产品生态基础的可持续发展，对于关系国计民生的金融业务系统尤为重要，应确保长期无“断供”等相关风险，不会因为停止供应或者服务影响业务连续性。

此外，数据库作为数据安全防护的最后屏障，所涉及的组件会不会带来新的安全问题，这些都是金融机构的IT管理者、科技部门领军人非常关注的问题。在保证整体架构安全、稳定的同时，如果还能带来额外的效益，则更佳。比如做到性能不回退且成本不增加、支持业务未来的可持续发展、降低后续开发运维复杂度等。

（2）运维人员/DBA的主要关注点：数据库维护是否操作简单，且具备更高的业务连续性

数字经济时代的到来，金融的数据量持续快速增长，原有集中式共享架构的部署模式，一旦发生故障难以快速自愈则需要大量人工操作，业务连续性将受到影响，因此数据库需要具备更高阶的可用能力和容灾能力。

大多数金融机构系统数量多、结构复杂，但大部分系统的业务量、数据量其实并不大。加上创新金融业务的迭代及发展速度远超预期，分散的集中式集群运维成本较高，同时容易遇到并发量、扩展性等瓶颈，将导致数据库的扩展成本、运维成本和管理复杂度的大幅提升。

因此，金融机构的运维人员/DBA会更关注数据库维护是否简单易用，数据库升级后是否能有效提升资源利用率、降低整体运维成本、兼顾复杂度和维护难度、保证业务系统的连续稳定运行。

（3）开发人员/架构师的主要关注点：数据库升级是否平滑兼容，且满足未来架构长远演进要求

作为金融机构的开发人员或者架构师，数据库整体架构的可演进性是其首要关注点，而且要确保在满足业务需求的前提下，数据库做到平滑迁移。因为原数据库的兼容性稍差，就会导致业务改造整体成本非常高，而在此期间业务发展不等人，各类新增业务需求还会层出不穷，开发人员通常需要同时面对以下事项：

• 一是重写应用系统，包括新系统的设计、开发、测试等工作；
• 二是进行新数据库的迁移和替换，期间可能新老业务并跑，维护新老两套应用系统和数据库；
• 三是对接新业务需求开发；
• 四是解决上述问题叠加，可能会带来各类潜在风险和隐患。

因此，数据库需要具备较高的语法以及用法的兼容性，才能在极大程度上避免以上问题的发生，保证业务平稳上线运行。此外，数据库升级过程中一旦出现问题，需要支持回退、支持逐步替换升级或者长期并行验证。

结合金融分布式架构转型，越来越多的业务需要数据库具有在线事务处理和海量数据分析的复杂使用场景，传统做法是将数据导一份到数据仓库里做离线的计算，这对资源本身其实是一种浪费；且对实时分析要求高的场景，这种方案也不具备可落地性。这就要求数据库在提供高并发交易事务处理能力的同时，还能够提供海量数据实时分析的能力，以更高效率、更低成本地满足多元化的金融业务场景需求。

四、 金融行业需要怎样的数据库

1. 金融行业数据库技术架构演进

回溯IT技术的发展史，金融行业的IT应用基本走在行业前列。以银行业为例，其IT技术应用大致经历了三个阶段的发展：

• 第一个阶段，会计电算化时代，每个网点是一个账本，没有网络互联；
• 第二个阶段，网点互联时代，增加了网络互联，实现了省市级网点的互联；
• 第三个阶段，全国大集中时期，将数据库、应用、服务器等IT技术设施集中起来，由集中的数据中心提供数据和业务的处理，“IOE”架构成为首选。

互联网催生了电子商务的发展，诞生了网购和第三方支付业务，电子商务借鉴金融行业信息技术的先进应用经验，“IOE”架构以其稳定性、易用性成为当时的主流。随着电子商务业务飞速发展，以及“秒杀”“大促”等业务模式的出现，海量数据、高并发下，集中式数据库的性能出现瓶颈，而且“IOE”架构的成本越来越高。

为解决扩展性不足和成本问题，“中间件架构的分布式”架构诞生，基于国外开源数据库包一层分库分表等中间件，使用PC服务器替代小机和高端存储，并省去了数据库授权费用。业务模型简单的互联网交易场景获得快速发展。

然而，随着中间件架构的推广使用，其诸多缺陷开始显现。由于分库分表架构需要按照分片键查询，难以支撑无分片键的访问请求、难以增加不包含分片键的二级索引、难以支撑跨分片的分布式事务等。为解决这些问题，中间件架构大幅提升了应用层的复杂度，例如，双写业务表和索引表这两张表，而当这两张表跨越不同数据库实例时，又需要引入应用事务中间件等。

正是因为这些中间件架构分布式的缺陷，互联网的去“IOE”浪潮没能推广到更多的行业，而金融行业的业务模型复杂度以及对数据一致性的要求远高于互联网。

到了移动互联网时代，金融机构纷纷开启加速数字化转型。柜面交易量逐步被替代，由智能手机承载的金融服务方便随身携带。这些金融服务在业务类型上包括银行、保险、证券、基金、期货等金融领域，并且在业务范围上延伸金融行业服务客户的范围，开放金融、供应链金融、全场景金融等不断涌现。

传统的集中式数据库依赖单机的处理能力，因而存在架构上的单点。随着摩尔定律的失效，依靠垂直扩展的集中式走到了尽头，而金融业务的发展要求数据库具备海量数据下的高并发的事务处理能力。部分金融机构在架构转型中尝试中间件架构的分布式，在国外开源数据库上做二次开发，并取得一定效果，但随着深入应用依然出现瓶颈。为彻底解决海量数据、高并发场景的数据库的问题，原生分布式数据库架构诞生。

中国信息通信研究院在《大数据白皮书（2018年）》中给出了数据库架构的发展方向，阐述了一致性协议Paxos的诞生为分布式数据库的发展铺平了道路，是对数据库发展历程的高度概括，也为数据库的发展指明了方向。这包含两重含义，一方面，分布式替代集中式是发展的必然，而原生分布式数据库是数据库发展的方向；另一方面，中间件架构的分布式只是过渡态。数据库架构演进过程如图3所示。

图3 数据库架构演进过程（注：资料来源于中国信息通信研究院《大数据白皮书（2018年）》）

2. 中国场景驱动数据库技术创新，新一代数据库需要具备四大核心能力

自关系模型有了完善的理论支撑后，从Oracle、DB2到SQL Server，商业数据库迎来第一波高速发展。当关系数据足够流行，上下游生态软件和应用软件的适配足够完善，以及在全球有足够广泛的开发者群体时。MySQL、PostgreSQL等数据库以开源、免费版和简化版的形态推动了数据库历史上第二波更加广泛而影响深远的发展，但直到1996年后，OLTP领域再也没有新的主流数据库出现（如图4所示）。

图4 OLTP领域主流数据库诞生时间点

这是什么原因呢？因为在使用场景上并没有实现代际跃迁，也就无法对现有数据库的能力和架构产生太大的推动力。直到以中国、美国为代表的区域迎来第一波PC互联网到移动互联网的高速爆发，在这之后，数据库领域慢慢开始有了新的变化，而比较有意思的是，这波移动互联网的变革，中国比美国更快、更彻底，也更快地推动了大量技术的发展甚至是变革。

2000年左右，基础架构还没有反应过来，从应用层到中间件层开始解决集中式解决不了的问题，以Cobar，MyCAT为代表的中间件方案的分布式架构出现。一直到2010年左右，以Google Spanner、OceanBase等为代表的原生分布式架构出现，陪伴互联网高速发展了十余年，产品逐渐打磨成熟并开始商业化。

Forrester相关报告指出，传统数据库在数字经济时代面临技术架构复杂、使用成本高以及安全性等严峻的挑战，企业迫切需要采用新一代数据库来处理海量数据，利用架构升级来消弭高昂的软硬件成本，并需要加强数据分析能力以推动企业洞察驱动的决策模式，从而进一步加速数字化转型，进而推动全社会数字经济的发展。新一代数据库需要具备低成本的极致性能、全维度的弹性灵活、洞察驱动的融合分析，以及全方位的安全可靠性四大核心能力（如图5所示）。

图5 新一代数据库需要具备的能力（注：资料来源于Forrester《OceanBase总体经济影响TM (TEI) 研究报告》）

数据库是用出来的。OceanBase 过去十多年的发展，得益于飞速发展的移动互联网。这些年，从互联网支付核心到全场景金融核心，再到政企民生、运营商核心场景，以及新零售、新制造、互联网海量场景，OceanBase 参与并支持了一次又一次的关键业务负载，在千行百业的关键业务负载中不断深度完善、快速迭代。也正是因为这些，倒逼了分布式数据库技术的再次突破、创新和成熟。

对基础软件的发展而言，这是一条极为特殊的成长路径，也是最好的成长路径，在全球都很难复制，这是我们的幸运，身上也不由有了一种时代的使命感。

回看14年一路走来的历程，今天的我们得益于最初的决定——走“根自研”路线；得益于中国独特的场景——移动互联网爆发，带来前所未有的对海量数据、高并发的数据处理需求，以及这几年大量企业的核心系统升级，带来复杂业务场景下处理海量数据的需求。这些独特的场景使得OceanBase能够始终坚持创新探索，穿越“无人区”。借助中国场景，能够推动分布式数据库的四项新标准（如图6所示）。

图6 中国场景推动分布式数据库的新标准

• 性能新标准：OceanBase用一个引擎刷新了TPC-C、TPC-H两个榜单。高并发场景下可按需实现不停机、不改应用的弹性扩缩容；实现一份数据同时支持事务处理和实时分析。
• 容灾新标准：建立首个“三地五中心”城市级自动无损容灾新标准，保障城市级业务持续高可用。
• 高可用新标准：相比传统数据库，OceanBase的高可用是自动切换的。与此同时，继RTO小于30秒后，进一步将RTO降低到小于8秒，故障恢复进入秒级时代，这也是目前业内RTO的最高水准。
• 架构新标准：“单机分布式一体化”在业内首次突破分布式数据库的单机性能瓶颈，使得数据库可以在现代数据架构下适应企业成长的全生命周期，其研究成果论文入选国际顶级数据库学术会议VLDB2023，业界权威机构都非常认同这是分布式数据库架构的未来发展趋势。

3. 一体化数据库：支持不同规模金融机构/业务系统

我们在不断解决各种场景问题，尤其是关键业务的数据存储、处理、使用过程中，摸索出分布式架构数据库的最佳实践，逐步形成了“一体化”的解决思路。

从2010年至今，OceanBase专注于OLTP场景，开始逐步打造满足现代数据架构需求的TP&AP一体化、多模、云上云下一体化、单机分布式一体化等核心能力，推出一体化数据库，支持不同规模金融机构/系统的关键业务负载。其中，“一体化”的理念包含以下两个方面（如图7所示）。

图7 OceanBase一体化数据库

第一，“一体化”的体验。在实际的应用中，数据库是解决数据存储、处理问题的手段，应用系统真正关心的、要解决的是业务需求问题，而不应该花太多精力在关心分布式带来的成本复杂度问题、处理各种数据结构带来的存储的差异性、不同数据库操作语法带来的好处、不同的负载或者基础设施带来的差异性等。我们用“一体化”设计来打造产品，让用户回归到关注业务，让数据库使用尽可能简单。

第二，一个数据库解决80%的问题。“一体化”不是变成全功能，也不是简单的拼装组合。本质上，OceanBase还是一个具备“关键业务负载”支撑能力的OLTP数据库，核心能力还是高可用、高安全、高性能以及高性价比。我们认为，在企业的绝大部分数据处理场景中，只要成本合理，这些都是必需的能力，我们希望能在这个强劲的底座上，尽可能满足80%的需求。但在极其专业的场景，还是需要用专门的数据引擎。就像今天的智能手机，可以很好地满足普通人对电话、聊天、游戏、听音乐和看电影的需求，但是针对一些专业用户，专业的游戏机是更好的选择，电影院是更好的选择。

五、OceanBase如何应对金融行业面临的数据库升级挑战

1. 深度强化稳定可靠，保障服务不中断、数据不丢失

随着移动互联网和互联网金融的进一步普及，金融机构需要为客户提供无所不在、触手可及的全天候金融服务，双活、多活也成为金融科技的基本要求。随身化、实时化的金融服务要求IT系统提供7×24小时不间断服务，即使面临天灾、地震等自然灾害也需要保证业务的连续性。

我们在稳定可靠性方面投入最多，首创的“三地五中心”城市级故障自动无损容灾新标准（如图8所示），在高可靠性上不断升级，也一直在推动行业的发展。OceanBase 最早提出RPO=0，RTO＜30秒，目前已经是行业标配，这个还是数据库层面的自动切换时间，为了给连续性要求更高的业务系统留出更多时间，经过努力，我们将其降到了8秒内。

图8 OceanBase支持丰富、灵活的容灾模式

该架构底层采用Paxos协议实现将Redo日志在本服务器持久化，同时主副本在确认多数派副本Redo日志都持久化成功后，确认数据库事务提交成功，从副本利用Redo日志的内容实时回放，保证自己的状态与主副本一致，这种多数派同步机制也保证了少数副本发生不可用或者网络抖动时，业务系统也能够平稳运行，影响做到最小。

在金融行业比较常用的“两地三中心”部署架构中，OceanBase可以通过仲裁副本的机制实现数据一致的真正双活，在双机房主备架构下，OceanBase可以支持更细的容灾颗粒度，包括租户级主备库和备份恢复，实现更灵活的容灾部署和容灾切换，满足各个维度的业务容灾和业务切换需求。

以深圳农商银行为例，基于OceanBase采用“两地三中心”部署架构。2023年9月，深圳因台风“海葵”出现超历史极值的罕见强降水，深圳农商银行部分系统可用性受到影响，OceanBase顺利完成了异地switchover无损切换，支撑业务在异地成功运行，在真实场景中稳定应对危机，服务无中断，数据零丢失，有力保障了深圳农商银行的业务连续性与客户数据安全。

OceanBase的“黑科技”——保障数据一致性的“五道防线”

“数据一致性”是数据库的生命线，面对PC服务器稳定性比大机/小机低、数据库主备模式解决不了“脑裂”及RPO=0的问题、磁盘固件门及各类静默错误的新挑战，OceanBase具备数据一致性的五道防线(5+x)：

1. 一致性协议Paxos： 保证事务发生时数据一致性；
2. 链式交叉校验：宏块、分区等多重校验和构成校验链;全局索引和数据交叉校验;二进制和数据双重校验；
3. 集群内多副本之间一致性校验: 每日合并时自从触发校验；
4. 主备集群之间的数据一致性: 用于同构容灾、异构芯片混合部署；
5. 冷数据定时扫描: 发现数据中的错误，如: 磁盘的静默错误等。

磁盘静默错误发生的概率并不太高，但其可怕之处在于错误发生时没有任何警告，如果应用程序没有对数据的正确性做校验，那就会导致奇怪的应用异常，例如进程崩溃、丢数据等。OceanBase通过多副本校验、relog校验、SSTable校验层层设防，防止类似磁盘静默错误导致的数据一致性、正确性问题。

多副本校验

OceanBase 数据库作为分布式数据库，采用了多副本的容灾方式。由于磁盘静默错误发生的概率并不高，所以同一个数据块在多个副本同时出现静默错误的概率微乎其微。只要我们能知道某个副本出现了磁盘静默错误，就可以从剩余的正常副本中拷贝数据来修复这个错误。多副本之间的数据校验是在LSM-Tree major freeze阶段做的。目前 OceanBase 数据库支持副本粒度的修复，出现磁盘静默错误时，运维同学可以先删除错误副本，再从其他机器补齐正确副本。

relog校验

在每条 RedoLog 的头部，我们会记录这条日志的校验和。在做网络传输和日志回放时，都会强制对每条日志的校验和进行校验。这样我们保证了三副本同步到的日志是正确且一致的，如果一条日志中的数据出现了静默错误，那么这条日志一定不会被同步到其他副本。

SSTable校验

SSTable 的数据存放在一个个宏块中，宏块的长度固定为 2MB，在宏块的头部会记录这个宏块的校验和。宏块内部会拆分多个微块，微块长度不固定，通常为 16KB，在微块的头部也会记录这个微块的校验和。SSTable 的读 IO 以微块为基本单位，写 IO 以宏块为基本单位。在读取微块时，会强制校验微块头的校验和，保证用户读到的微块数据是正确的。在迁移、备份等复制宏块的场景，目的端写宏块前，也会强制校验宏块的校验和，保证写入的数据是正确的，防止磁盘静默错误的扩散。

除了在读写时检查数据块的正确性，我们还希望尽早发现磁盘静默错误。OceanBase 数据库可以在后台开启巡检任务，周期性扫描全部宏块并检查其校验和，一旦发现磁盘静默错误便会告警。

2.持续平衡性能与成本，助力性能不下降、成本不增加

性能一直是OceanBase的强项，以前我们更多强调分布式的扩展性，并且用TPC-C 7.07亿tpmC这样极端的场景，验证了OceanBase无限的扩展能力。

分布式的强项是解决扩展性和容灾的问题，但冗余的多副本设计带来最大的副作用就是成本比较高。在这方面，OceanBase的LSM-Tree存储架构和高效的SQL优化器，极大地平衡了多副本和并发处理能力，因此可以在性能和成本上达到很好的平衡。

（1）降低成本：降低数据存储相关的软硬件成本

当一个数据库承载的业务量变大、规模变大、系统数变多后，如何高效利用好每一份资源成为非常重要的目标。数据高压缩的同时性能无损，在基于传统B+树的数据库中几乎是不可能的，但在LSM-Tree架构下经过设计使其成为现实。

凭借高压缩比的分布式存储引擎，在同一业务的数据存储量下，OceanBase能显著节约存储空间，降低存储成本。对于数据量大、数据生命周期长的业务场景来说，可以极大地满足业务需求。比如，某国有特大型保险机构保险公司核心系统上线后，数据库压缩比高达8倍，业务数据库容量瘦身78%，数据库软硬件成本缩减75%。

（2）提升性能：提升业务系统的各项性能

金融核心交易系统的特点是事务交易链路长，涉及的SQL比较多，一笔交易可能包含上百个SQL，同时核心交易场景对高并发，低延时，数据一致性是基本要求。

OceanBase的分布式SQL优化器，全面支持HTAP能力，保障业务性能。比如，金华银行新一代核心系统采用长亮V8核心系统，完成从“小型机+集中式数据库+高端存储”到“PC机+OceanBase分布式数据库+普通磁盘”的升级，仅使用18台物理机，而在浙江同规模的某商业银行使用基于MySQL二次开发的数据库需要40台，并且新一代核心系统的性能也得到显著提升，日终批处理能力提升5倍以上、业务峰值处理能力提升12倍，批量代发时效提升120倍、季度结息效率提升了8倍。

OceanBase的“黑科技”——“仲裁副本技术”显著降低跨城网络宽带

分布式数据库的网络宽带一直是金融机构关注的问题。金融行业传统“两地三中心”架构几乎均采用同城存储复制结合异地数据逻辑复制方式，为降低“两地三中心”“三地五中心”对高带宽、低延迟网络的依赖，我们投入大量资源进行攻关并提出一揽子解决方案。

1. OceanBase 4.X版本对日志流进一步优化，降低数据库本身带宽开销，配合优化后的日志流压缩算法，可有效将多个机房副本间的带宽下降40%以上；

2. 通过设计合理的数据分布结合智能 DNS 将流量收敛到同机房，同时利用 OceanBase 独创的“Table Group”技术将各类相同属性的数据收敛在相同的 Zone，从底层就避免跨机房访问数据及跨机房事务，减少应用跨机房访问数据库的网络延迟的同时降低应用对跨城带宽的依赖；

3. OceanBase 4.X版本仲裁副本技术降低多机房/跨城（省）机房的网络带宽，由于仲裁副本本身不存储任何数据和日志，因此仲裁副本能够彻底降低第三中心的带宽成本，任意机房到仲裁机房的带宽仅需要原来的千分之二，延时则可以比以往放宽接近数十倍。

通过上述技术创新，四川省农村信用社在新一代分布式核心方案论证时，使用OceanBase 4.X版本进行了业务模拟压测，带宽最高可减少60%，每年预计可节省跨城带宽费用数千万元。

3.不断降低运维复杂度，以集中式体验享受分布式性能

OceanBase在数据库内核、周边工具层面不断降低运维复杂度，期望运维人员/DBA能以集中式产品的使用体验，享受分布式的性能。

（1）数据库内核层面：原生多租户架构，私有云上也可以做到Serverless

随着金融转型，应用分布式/微服务改造等，金融业客户内部数据库数量剧增。多个微服务使用的数据库一般通过schema隔离，多个schema之间无法实现各自所需的资源的隔离，因此，资源碎片化、管理复杂、资源浪费、扩展性差等问题逐渐暴露出来。在这种情况下，数据库将会成为微服务体系框架中性能与扩展性的最大制约瓶颈。

加上基于IaaS提供大量数据库会带来巨大的运维成本和投资成本，以及难以快速供给等问题，数据库即服务（DBaaS）成为刚需。OceanBase通过数据库内核实现原生多租户模式，提供数据隔离、资源隔离、故障隔离、弹性资源。

OceanBase中的租户是一个逻辑概念，是资源分配的单位，是数据库对象管理和资源管理的基础，对于系统运维，尤其是对于金融核心分布式数据库的运维有着重要的影响，租户在一定程度上相当于传统数据库的“实例”概念。

有些客户希望通过多租户把很多单实例合并到一个大集群；有些客户希望租户的隔离性不要那么强，这样可以实现超卖；有些客户则把它用在各个省份的业务单元或者多法人机构，希望在运维上是同一套集群，但在隔离性上希望和物理机、虚拟机一样。

如图9所示，我们将业务系统不同微服务所需的数据库实例进行资源池化，提供不同规格的实例，在一套分布式数据库架构中实现多个数据库租户（实例）的资源池化能力，在保证资源隔离性的同时显著降低资源和管理成本，还依然能够保持优秀的性能和可运维性，将多个零散的数据库实例集中统一在OceanBase集群后，运维管理复杂度大大降低，负载、告警、调优全部统一至集群级别，常规故障能够自动恢复。

图 9 OceanBase多租户资源池化

多租户可以应用于金融行业的不同场景，降低运维复杂度。

• 大型金融机构，比如，国有大型商业银行、股份制商业银行以及头部保险、证券等机构，可以按照地域分组、客户分组等方式，进行多租户划分，在一套分布式数据库环境中统一纳管，同时这种架构还具备业务灰度、流量调拨等能力。
• 省级农信机构，按照多法人主体进行划分。
• 银行、证券等机构，业务种类多，数据量和并发量相对不大的场景，按照多个小业务（多租户）大集中（一套分布式数据库环境）统一部署管理。
• 保险机构，按照不同业务流程的微服务进行划分，如收单、核保、保全、理赔等。
• 金融业务中台，按照不同的中心划分，如用户中心、合约中心、产品中心、认证中心、支付中心、交易中心等。

（2）周边工具层面：“OCP+OAS”

分布式数据库同时运维多个节点，更需要集中式的管理工具统一管理。我们从OceanBase运维管理工具（OceanBase Control Platform,OCP）和OceanBase自治服务工具（OceanBase Autonomy Service,OAS）两个周边工具层为运维/DBA提供可管理的手段，助力用户真正去解决实践中遇到的问题。相比于传统的分布式数据库产品，可进一步降低运维复杂度。

OceanBase的“黑科技”——原生分布式的分区表与扩展性

与传统单机数据库相比，基于分布式架构的 OceanBase 提供灵活的在线扩展性。在集群持续可用的前提下，提供在线扩缩容。当集群的容灾需求发生变化时，可通过调整可用区数量（加/减 Zone）的方式提高或降低集群的容灾能力。当集群的外部负载发生变化时，可通过调整可用区内物理机的数量（加/减 OBServer）的方式改变集群的负载能力。

从业务视角看用户操作的数据原子单位是表，用户通过访问表来实现业务的增删改查。当单表的数量级上升到一定数量级时，性能将会急剧下降，此时就需要分而治之。分治的就是将大表拆成小，目前主要有两种方式，分区表和“中间件+分库分表”。

OceanBase可以和Oracle一样通过分区表将数据打散到各个节点。OceanBase的单个分区存储一张表的部分或者全部数据，当表是普通表的时候，存的就是全部数据，当表是分区表的时候一个分区存的就是一部分数据。

分区表相对“中间件+分库分表”的优势有以下几个方面：

1. 对应用透明，应用无需关注底层数据分布，响应快；
2. 无中间状态，不存在中间件故障可能引起的数据一致性问题；
3. 支持复杂查询，中间件无法实现物理隔离库间表的关联查询。

OceanBase分布式数据库通过分区表来进行水平拆分，不需要分布式数据库中间件产品，也不需要分库分表，更不需要考虑跨节点分布式事务一致性问题。通过分区表水平拆分，SQL和事务对业务完全透明，功能上没有任何限制，且分区表线性扩展性也很好，并且支持在线扩容和缩容，内部数据迁移异步进行，具备高可用能力，不怕扩容和缩容过程中出现故障，可以轻松解决分库分表所带来的痛点。

4. 完善平滑迁移方案，打造应用基本无感的稳妥升级

大量的数据库升级是存量替换的过程，如何保证迁移过程的平稳极为关键。OceanBase 经过多年商业化打磨，形成向上向下兼容、向上游向下游适配的整套迁移部署方案。

向上兼容方面，我们从0.4版本就开始做SQL语法，确定兼容SQL语法的原则。自2008年集团开启传统数据库升级以来，平滑迁移经验不断积累、Oracle/MySQL语法兼容能力不断增强，Oracle兼容性经过多年打磨，功能兼容覆盖率在95%以上；MySQL兼容版本也从5.x发展到8.0，兼容MySQL8.0的主流功能。应用只需要很小的改动，甚至无需改动，就可以迁移至OceanBase分布式数据库中。今年我们又增加并完善了 DBLink、JSON/XML/GIS/LOB等大颗粒的功能；在OLAP方向常用到的复杂数据类型如 Nchar、Nvarchar 等也有了更好的支持。向下兼容方面，OceanBase完成了基本全部主流芯片和服务器的适配，包括 7 款主流芯片和10多家整机厂商的适配。

向上游适配方面，具备四大类源端数据库的对接解析能力，其中包括10多款云上云下的数据库产品；向下游适配方面，则通过Canal、Flink、DTS等比较常见的数据同步工具打通上下游数据处理软件，同时支持20多款常见数据处理平台，可以无缝地跟原有的数据架构进行对接。OceanBase平滑迁移方案如图10所示。

图10 OceanBase平滑迁移方案

正是利用这套平滑迁移方案，西安银行用了3个月时间就完成了互金核心升级至OceanBase。青海银行的柜面系统，耗时1个月即从DB2平滑升级至 OceanBase。某国有特大型保险机构全栈核心系统，仅用1年时间即完成整体升级，迁移规模和速度破金融行业纪录，全程无一例回切。

OceanBase的“黑科技”——一库多芯，灰度替换

近年来，金融行业数据库升级明显加速，私有云数据库架构中往往存在多种型号的硬件机型和操作系统版本，而对这些硬件进行批量替换和升级换代是一项高风险、高成本的工作，如何平滑的完成替换升级成为了一项新的课题。

OceanBase提供“一库多芯，灰度替换”的解决方案，得益于OceanBase 的多副本异构兼容能力，适配海光、鲲鹏、Intel等多种芯片，兼容麒麟、统信、Linux多种操作系统，且在数据库层自动适配，用户无需关注底层的芯片和操作系统形态，并且支持异构芯片副本之间的数据一致性校验，确保数据一致性和正确性，具备容灾切换能力，混部的方式包括以下两种：

一是主备集群混部。如在主集群服务器使用x86芯片+linux操作系统，备集群服务器使用arm芯片+麒麟操作系统。

在该架构下，生产环境可先保留可靠性更高的x86芯片，利用OMS同步或OceanBase主备库来验证ARM架构+麒麟OS的稳定性。待稳定运行一段时间后可在某个时间点进行主备切换，从而在风险可控的前提下完成国产改造。

二是集群内不同副本混部。如在单集群内部，Zone1副本和Zone2副本的服务器使用x86芯片+linux操作系统，Zone3副本使用ARM芯片+麒麟操作系统。

将主集群中的部分副本灰度替换为ARM架构芯片，配合OceanBase的切主能力，可实现单个分区的Leader切换来验证国产副本承载流量的能力。如下图所示，例如将P4分区的主副本从Zone2切换至Zone3。若出现异常可随时将该分区Leader切换回原有副本，最终可以将主集群灰度切换为全ARM芯片的副本且无需停机。

5. OLTP-Based HTAP，实时分析回归业务本质需求

在数据库领域，是否需要“one size fit all”、是否需要HTAP数据库是业界长期关注的话题。然而一切还要从实际需求溯源，实际情况是无论是传统金融还是互联网金融场景，绝大多数业务系统都不可能是纯粹的OLTP或OLAP。

即使是银行核心业务系统，联机是典型的OLTP，而批量中有大量OLAP形式的负载。随着24小时实时批量的流行，很难把OLTP/OLAP负载进行非常清晰的切割；随着微服务化改造，各种数据中台、业务中台成为刚需，而各类中台本身的业务特点就是典型的HTAP混合负载。

行业内的通用解决方案是使用两套数据库引擎，分别提供OLTP和OLAP处理能力，两种引擎之间通过数据复制/迁移进行数据交换，这种方案能够解决一些问题，比如两套引擎各自支持OLTP和OLAP都可以支持得很好，但仍然明显存在着自身的局限性：

• 一是在不同引擎下，数据的一致性无法保证；
• 二是无法保证不同引擎下数据的时效性；
• 三是业务侵入性较强，OLTP和OLAP两套库采用的SQL语法、数据类型不同，需要在数据同步时进行映射转换和应用修改；
• 四是将OLTP库和OLAP库完全独立会带来数据的冗余和维护数据同步，增加TCO。

以常见的金融核心交易类系统为例，基于核心交易类系统的数据源下进行复杂查询、报表分析和批处理等是非常普遍的场景，传统数据库往往在一定数据量和复杂度的情况下会遇到可扩展性、性能或者并发的瓶颈，因此不得不需要两套软件的解决方案。

我们从存储层、SQL层、事务层乃至链路层都进行了整体优化设计，提供“一体化”设计的HTAP混合引擎（如图11所示），通过一套数据、一套引擎同时支持OLTP和OLAP的负载。这样可以充分挖掘一份数据价值和一套集群的能力，数据在一致性、分析实时性和运维效率上取得平衡。交易数据原地分析，无需繁琐的ETL过程，数据最大程度保鲜，省去了很多业务场景中实时数仓的构建工作，帮助客户实现业务价值。

图11 传统方式VS HTAP方式

中国太保利用OceanBase的HTAP能力，财险核心批处理相比于传统“IOE”架构，节省了62% 的时间。同时，利用向量化引擎、优化器改写优化能力和大规模分布式并行执行技术，显著提升处理性能，财险分析型的数据加工处理能力提升10倍，监管报送批量场景性能提升3倍，构建起全面的实时数据处理和服务能力。

最新发布的OceanBase 4.3，深入探索TP & AP一体化，基于LSM-Tree架构推出列式存储引擎，实现可行存、可行列混存和可列存的多种存储方式，打造近 PB 级实时分析数据库， 可在一个数据库、一份数据的前提下，同时实现联机事务处理和秒级实时分析。

OceanBase的“黑科技”——TP&AP融合一体化，实现一份数据既能联机事务处理又能实时分析 

OceanBase的HTAP是在OLTP数据库的基础上扩展OLAP能力。经典的 OLTP 数据库，无论是开源的MySQL，还是商业数据库 Oracle/SQL Server，都采用集中式架构，底层存储引擎是面向磁盘设计的 B+ 树。这种方案是为小数据量的实时事务处理量身定制的，读写性能很好但相比 LSM Tree 等新型数据结构存储成本更高。以 OceanBase 为例，底层采用优化过的 LSM Tree 存储引擎，在支付宝所有业务完全替换 Oracle/MySQL，存储成本只有原来 B+ 树方案的 1/3 左右。

为了让 OLTP 数据库具备 OLAP 的能力，尤其是大数据量 OLAP 的能力。

首先，引入原生分布式架构和基于LSM-Tree的存储引擎，提升系统的大数据处理能力，从而使得系统不仅能够处理最新数据的实时交易，也能处理更大规模历史数据的全量分析。OceanBase 的底层采用了一个基于LSM-Tree 的行列混合式存储方案，大幅降低存储成本，并在 OLTP 和 OLAP 二者性能取得很好的平衡。

其次，支持 OLTP 与 OLAP 之间的资源隔离。这里面既有多个副本之间的物理隔离，也有一个副本内部的CPU/网络/磁盘/内存的逻辑隔离，将 cgroup 集成到数据库引擎内部做逻辑资源隔离是一个不错的方案。

再次，很好地支持复杂查询和大数据量查询，涉及到优化器、并行执行、向量执行等核心技术。对于分布式数据库，优化器不仅仅要考虑单机上的代价，还需要考虑多机上的代价，优化器的搜索空间大幅增加；另外，如何处理并行执行和服务器故障容错的问题，如何实现高效的向量引擎，如何设计内存中的数据格式，等等。

最后，更好地支持 OLAP 的数据开发和建模能力。数据仓库往往会将数据分成多个层次，包括：数据明细层，数据服务层，应用数据层。为了支持实时分析能力，HTAP 支持高效易用的物化视图，外部表，快速数据导入，并与各种数据开发工具和 BI 工具完成适配对接。

OceanBase 进化到4.x版本后，可对分析引擎全场景覆盖，可利用单机的多核心进行并行处理；全新设计的融合日志缓冲区同时支持聚合提交与共识协议，大幅度提升交易处理能力，分析处理能力再上台阶；全场景向量化能力覆盖，更丰富的算子下压，并将完全支持列存。

最新发布的OceanBase 4.3，基于 LSM-Tree 架构推出列存引擎，实现行存、列存数据存储一体化，同时推出基于 Column 数据格式描述的新版向量化引擎和基于列存的代价模型，支持高效处理大宽表，显著提升 AP 场景查询性能，并兼顾 TP 业务场景，适用于复杂分析、实时报表、实时数仓或联机交易等混合负载场景。该版本新增物化视图功能，通过预计算存储视图的查询结果提升实时查询性能，支撑快速报表生成和数据分析场景。新版本内核也扩展了 Online DDL、支持了租户克隆等功能，优化性能和资源使用，提升了系统易用性。经测试，OceanBase 4.3 在同等硬件环境下，在大宽表场景下的查询性能达到了业内主流列存大宽表数据库的水平。

综上，具备HTAP能力是一个宏大的整体工程，需要完善的顶层设计、长期的技术积累和持续迭代，并不是一个简单的通过某种“银弹”技术（如列存）可以解决的。

六、核心系统数据库升级最佳路径实践

金融核心系统更换数据库，好比飞机在运行过程中更换发动机。如何在更换发动机的过程中不影响飞机的正常飞行，甚至让乘客感受不到这个过程，对于金融机构和数据库厂商而言都是一场“大考”。

1.八个步骤

目前，金融机构的核心系统数据库主要以Oracle、DB2为主。从应用演进的角度，常见的金融核心系统数据库升级有平滑迁移和完全新建两种，平滑迁移侧重于应用不改或者仅有少量修改，保持库表结构基本不变的情况下，将数据库替换成分布式数据库；完全新建指建设一套新的核心系统，然后将老核心系统的数据与新核心系统的数据结构映射后完成数据的转换和迁移。

OceanBase在服务众多金融机构的核心系统数据库升级过程中，沉淀出一套升级替换的方法论，供金融机构在核心系统数据库升级时参考（如图12所示）。

图12 八个重点步骤

（1）需求分析与战略规划。首先金融机构需进行通盘的需求分析和战略规划。这包括评估现有系统的性能瓶颈、安全威胁、成本效益等方面，同时考虑国家关于金融信息化的政策导向及未来的业务扩展性、技术发展趋势。

（2）技术选型与方案设计。在明确需求后，选择合适的技术路径和方案至关重要。金融机构往往会考虑选择具有兜底能力的数据库，这不仅响应了国家的自主战略，也有助于降低对外国技术的依赖，增强金融信息系统的安全性。技术选型时会关注数据库的性能、稳定性、安全性、可扩展性及与现有系统的兼容性。

（3）应用适配、业务测试与评估。在实际升级之前，需要进行应用适配工作、详尽的业务测试与评估。这包括在测试环境中模拟实际业务场景，验证新数据库系统的性能、稳定性及业务兼容性。

（4）系统迁移与优化。系统迁移是升级过程中最为关键的环节。金融机构在迁移过程中，可能会采用渐进式、分阶段迁移的策略，确保每一步迁移都是稳妥可靠的。迁移后，需要对系统进行调优，确保其能满足业务需求并达到最佳性能。

（5）业务验证与持续监控。系统升级上线（跟账上线或者灰度上线）后，需要进行业务长期跟踪验证，确保所有业务流程在新型数据库上都能正常运行。此后，还需建立持续监控机制，实时跟踪系统性能和稳定性，以便快速响应可能出现的问题。

（6）安全与合规。数据安全与合规性是金融机构无法忽视的重要方面。数据库升级后，需确保满足国家相关金融信息安全的法律法规要求，加强数据加密、访问控制、安全审计等措施。

（7）培训与文档。为了确保系统升级后人员能够熟练操作新系统，金融机构会组织相应的培训。同时，完善的技术文档和操作手册也是必不可少的，以便于日常运维和未来可能的系统迭代。

（8）持续迭代与优化。金融机构的信息技术架构不是一成不变的。在完成核心系统数据库升级后，需要根据市场变化和业务发展需求，持续对系统进行优化和迭代，保持系统的先进性和竞争力。

通过以下三点，可帮助金融机构的核心系统数据库实现平滑迁移。

一是高兼容与广适配，即极高的兼容性和广泛的上下游适配能力，包括国产软硬件、中间件和大量行业软件。其中，高兼容不仅体现在原生的支持各种原数据库的数据类型、SQL功能和数据库对象，以及数据库安全、备份恢复、高可用和优化器等高级特性；而且在保持各种原数据库的开发、运维使用习惯上也在不断迭代。

二是完善的周边迁移工具，即一整套成熟的自动化迁移工具，包括兼容性评估、结构迁移、数据迁移、对象迁移等工具。如ODC开发工具尽可能保留原有的Oracle PL开发/调试习惯，通过OMA/OMS实现高度自动化的迁移评估+数据迁移/回迁功能。

三是成熟的迁移方法论，即大量内外部传统集中式数据库升级迁移项目所沉淀出来的升级迁移方法论。

2.四条路径

从最早提出“IOE”以来，我们就已经在集团内部承担了传统集中式数据库的分布式升级重任。我们从在内部电商、第三方支付、首批民营银行等内部场景苦练内功，具备了较强的Oracle兼容性，到拥有第一家商业银行客户，以及在大型保险机构、运营商等重度使用场景，不断与客户共同打磨兼容性，如今已经服务了众多大中小型金融机构。

得益于完全自研，OceanBase不会有基于PG/MySQL开源版本上与Oracle进行兼容的桎梏。经过长期内外场景打磨，OceanBase的兼容性日趋成熟稳定，主线的GA版本即可满足升级需求，无需通过定制化版本来支持。在这个过程中，我们也总结出核心系统数据库升级的四条技术路径（如图13所示）。 

图13 核心系统数据库升级的四条技术路径

路径一：Oracle平滑升级迁移

Oracle在金融行业是最常见的集中式数据库，在金融业务场景的覆盖上兼具广度和深度。当分布式转型升级到来，银行、保险、证券、基金等金融行业的客户需要最短、最快的转型升级方案，于是产生了该方案。其特点是，在应用代码少改或者不改的情况下，依靠分布式数据库的兼容性实现。OceanBase基于自身的高度兼容（95%以上，若严格对标Oracle 12C文档的功能项，兼容性在85%）及多年积累的体系化的迁移工具与迁移经验，通过“全面语法兼容”配合客户实现平滑迁移（如图14所示）。

图14 Oracle平滑迁移示意

以某国有特大型保险机构为例，从2020年9月～2021年9月，仅用时一年即完成包括传统核心在内的近百个业务系统近800套在线Oracle数据库的全量搬迁工作，迁移数据规模超400TB、数据量超千亿，单库数据规模超20TB，存储过程行数总数500万行以上，整个迁移过程无一例回切。业务改造“Pro*C+Tuxedo”的兼容能力和平滑迁移方案，避免了上千万行老核心代码的重写。

采用此路径的还有中国太保的“P17”、金华银行新一代核心系统以及广发证券的核心估值系统等。

路径二: “大型主机DB2迁移分布式数据库+单元化”方案

因业务规模大、范围广、复杂度高等，国有大型商业银行是分布式转型中的难点，同时国有大型商业银行在新一代核心建设中有单元化等架构方面的建设要求。

以某国有大行为例，某国有大行的贷记卡、借记卡、ECIF这三大核心系统均已转型为分布式，其中，贷记卡核心系统采用“阿里云+SOFA中间件+OceanBase分布式数据库”整体技术栈，实现“两地四中心多地多活+单元化”设计。基于OceanBase多租户特性，跨多集群百租户百库百表单元化设计，其中5个单元化（Rzone）集群：每个集群20个租户，每个租户对应一套分片库/表，总共百租户/百库/百表，统一按客户内部编号分片，实现资源隔离和减少爆炸。OceanBase分布式数据库+单元化方案如图15所示。

图15 OceanBase分布式数据库+单元化方案示意

OceanBase具有超高的写入性能，支持长亮、天阳分别采用联机写入和多表join写入等不同的数据迁移方式，4小时内即可完成全量数据从大机卸数、数据转换。从大型主机下移到x86服务器，贷记卡核心交易TPS提升6倍，跑批效率提升7倍以上，达成授权交易端到端耗时80毫秒以内的性能目标，并实现自动化运维、可观测与安全生产。

路径三：小型机DB2升级OceanBase

小型机DB2在中小银行核心系统的数据库中占用重要位置，而中小银行普遍采用新建的方式建设新一代核心系统。其中，一部分选择OB-Oracle模式，实现一套核心应用分别部署在OB-Oracle和DB2-Oracle两种数据库上，实现双逃生；另一部分选择OB-MySQL模式，分批切换，一步到位。

以常熟农商银行为例，新一代核心系统从方案论证到交付实施，历时18个月，基于 OceanBase构建起两地三中心五副本及主备架构，采用OB-Oracle租户，实现新一代核心系统OB-Oracle和DB2开启Oracle兼容的双容灾。OceanBase一主拖两备架构，主集群和异地备集群采用 x86 芯片，本地备集群完全国产，包括ARM芯片、麒麟操作系统，做到“一库多芯，混合部署”。相比老核心系统，新一代核心系统的每秒交易处理能力提升46倍，日终批量处理能力提升41倍，批量代发代扣处理能力提升651倍。小型机DB2升级OceanBase示意如图16所示。

图16 小型机DB2升级OceanBase示意

采用此路径的还有云南红塔银行、深圳农商银行的新一代核心系统等。

路径四：MySQL平滑升级迁移

十多年前，为应对互联网发展带来的高并发、海量数据对数据库的挑战，电商、第三方支付企业以及民营银行进行了去传统集中式数据库的探索，MySQL或中间件架构的MySQL是主要替代品，在整个金融行业覆盖度仅次于Oracle和DB2。

诚然，MySQL主要用于互联网核心或非核心系统，且大部分情况下为“完全新建”，“平滑迁移”为少数。与“Oracle平滑迁移方案”类似，得益于高兼容性，选择OB-MySQL模式即可在应用基本零改动的情况下，从源数据库完成平滑迁移。MySQL平滑迁移OceanBase示意如图17所示。

图17 MySQL 平滑迁移OceanBase示意

以西安银行为例，其快捷支付系统——西银惠付通过在OMS不停机的情况下实施MySQL向OceanBase的完整迁移。从2019年2月进行数据库评估分析，到2019年5月正式业务切流，3个月即完成迁移。迁移后，西银惠付的数据压缩为之前的1/2，各项系统性能显著提升。

3.核心系统数据库选型建议概述

赛迪顾问2023年2月发表的《核心数据库升级选型参考》报告显示，核心数据库选型因素涵盖数据、功能、效果三个层面（如图18所示），为金融机构的核心系统数据库选型提供了清晰的思路。 

图18 核心系统数据库选型因素（注：资料来源于赛迪顾问《核心系统升级选型参考》）

首先是数据层面，其主要包括数据一致性、数据安全性以及底层代码安全性。数据一致性不仅局限于事务发生时，还需要考虑数据库是否具备多副本数据校验、主备库数据校验、链式数据校验以及数据定时校验的能力；近年来国家高度重视数据安全性，数据库需要具备让数据资产避免未经授权的访问、损坏或盗窃；底层代码的安全性涉及软件产品的本质安全，金融机构核心系统应优先选择完全自主研发的数据库，而非基于开源的数据库。

数据层面的选型考量相当于“1”，数据库只有在这个层面具备足够的能力，后续拥有其他的“0”（如更高的性能、更低的成本等）才有意义。

其次是功能层面，其主要包括兼容与迁移、双写及回迁、事务处理、大数据实时分析能力。金融机构的核心系统如何有效降低数据迁移复杂度和迁移成本，主要依赖数据库的兼容与迁移能力，尤其是Oracle的兼容能力；一旦出现问题需要异构数据库切换或回滚，确保业务正常，这与数据库的双写、回迁能力紧密相关；事务处理能力和大数据实时分析能力则是OLTP和HTAP。

最后是效果层面，其主要包括稳定性与可靠性等。稳定性与可靠性跟数据库的高可用、高容灾等特性紧密相关，RTO、RPO等是金融机构在选型时可考虑的可量化指标；在此基础上，核心系统最好能在数据库部署成本、使用成本均有所降低的同时，各项性能还有所提升。

七、典型金融场景实践

1.银行

随着金融数字化转型的逐渐深入，银行业产品百花齐放，不同银行对于业务经营更多的是拼“软实力”。从内部来说，银行需要提升信用风险管控能力、提高优质资产率、满足监管合规要求等；从外部来说，银行需要通过设计特色化、差异化的营销手段提升用户体验和用户忠诚度，同时利用数字化手段通过全渠道为用户提供无处不在、触手可及的全天候、全场景、全生命周期的金融服务。

无论是从内部还是外部，“软实力”提升都需要借助数字化能力得以实现。而作为数字化转型的关键环节，OceanBase在国有大型商业银行、股份制商业银行、城市商业银行、农村商业银行、省级农信社等经过多年打磨积累了相当丰富的经验，助力银行业务系统尤其是核心系统更好地承担数字化转型重任。

银行业务系统按照用途可以分为存款系统、贷款系统、客户管理系统、渠道系统、会计系统、风险管理系统、内部支持系统等，典型的银行系统业务全景架构如图19所示。

图19 典型的银行系统业务全景架构

银行核心系统是指银行提供财务服务、进行日常操作的基础软件系统，通常包含客户和机构管理、存款管理、贷款管理、产品管理、交易处理、支付和结算等，是银行最重要的业务系统。

从银行业务服务的角度，银行核心系统主要包含ECIF、贷记核心、借记核心系统三部分，其中ECIF系统提供客户信息的管理，贷记核心系统如信用卡系统、贷款系统等，借记核心系统即银行卡核心系统，三大核心系统按业务实现方式可以分为跑批类场景和交易类场景。

（1）跑批类场景

跑批类场景天生就是高并发的联机交易，最重要的是时效。若跑批时间过长，轻则造成客诉，重则导致资损，甚至出现舆情事件。

这类场景对数据库处理能力的有效检验方式之一就是如何快速完成批量交易，因为需要频繁地对数据库进行增删改查，进行大量的I/O物理读和逻辑读计算操作，应用访问数据库的吞吐量也尤为关键。集中式数据库上性能的容量有限，跑批业务需要的时间缺乏弹性，一旦出现突发情况，可能留给跑批的应急处理时间有限。

• 贷记核心：贷款的批量扣款还款是面向个人提供的车贷、房贷等贷款的定期扣款还款的业务，扣款还款是银行回收借款本金和利息的途径，若因银行扣款不及时产生逾期利息，可能导致客户投诉；信用卡营销需要在更短时间内将优惠信息推送到客户的移动端，以保障活动效果。
• 借记核心：日终批量用来标记银行逻辑日的结束，跑批及时性决定着银行这一天的业务真正结束；季度计息是个人在银行中每个季度结算一次的活期存款利息，结息日一般放在每个季度最后一个月的20日；银行面向企业提供工资代发服务，一般要求在2小时内完成工资发放；面向个人提供水电煤等费用的代扣代缴服务即时到账，从而保障用户体验。           

原生分布式数据库利用多台机器的并发能力，并通过弹性扩缩实现动态的资源调整，因而在跑批场景具备优势。如避免分布式事务和远程访问，让所有服务器全部参与批量结息过程，提高处理速度；分散负载到多个节点，减少单一节点的压力；迅速扩容以应对流量高峰，同时在低峰期自动缩减资源以节约成本；允许读操作分散到多个副本，而写操作则在主节点上进行，减少读写竞争等，大幅提升批量场景效率。

银行在核心系统分布式转型中一般通过新老系统对比、银行同业对比两种方式来衡量。老核心（全栈国产分布式升级前）新核心（全栈国产分布式升级后）系统的跑批指标对比见表1，同等规模商业银行日终批量、批量代发实际值对比见表2。

表1 老核心（全栈国产分布式升级前）新核心（全栈国产分布式升级后）系统的跑批指标对比

表2 同等规模商业银行日终批量、批量代发实际值对比

综上，在跑批场景中原生分布式数据库相较传统集中式数据库的优势非常明显，在银行同业对比中相较传统集中式数据库或者基于MySQL二次开发的数据库也具备明显优势。

（2）交易类场景

在交易类场景中，最重要的是单笔交易耗时和交易吞吐量。若单笔交易耗时过长，则影响用户体验；若性能容量的TPS不足，则会造成高并发场景下部分客户的业务连续性无法保障。

• ECIF系统：作为全行业务的基础系统，提供客户信息的查询服务，整体以高并发的读操作为主，影响全行几乎所有业务系统的可用性；写操作主要是开户链路。
• 贷记核心：信用卡营销活动中产生大量交易，这些交易峰值常集中在信用卡营销日，其中用餐时间前后最为明显，信用卡交易的交易耗时和性能容量关系到每一个消费者的信用卡交易体验。
• 借记核心：存款与贷款是银行的传统业务，而存贷比是评价银行风险水平的重要监管指标；银行卡具有转账、存取现金和消费功能，同时可以支持一卡多账户、多币种。随着移动互联网的发展，移动支付成了重要的支付渠道，银行卡交易的单笔耗时和性能容量不仅是银行信用的体现，同时也是许多创新业务营收的基石，如银行卡买基金、买外汇、买保险等。

伴随新一代核心系统的分布式转型，分布式数据库在交易性能容量方面具有天然优势。在单笔耗时方面，应用和数据库同时转型分布式时耗时增加有限，业务上完全可接受。例如，某大型商业银行信用卡核心转型分布式虽然从60毫秒增至了80毫秒，在耗时有限增长的情况下，提供了机房级容灾能力，为业务连续性提供更好的保障。

某商业银行在核心系统交易类场景比对上更加精细化，其以一借一贷和混合压测这两种场景的压测结果进行度量，并进行了同规模银行的同业数据对比。如表3所示，该银行的新一代核心系统在同规模银行中处于领先地位，这也进一步印证了原生分布式数据库对新一代银行核心系统的支撑能力。

表3 同等规模商业银行一借一贷、混合压测场景数据对比

在金融数字化转型的浪潮中，银行新一代核心系统中无论是跑批场景还是交易场景，原生分布式数据库都能够为业务提供更好的支撑力。某国有大行、常熟农商银行、云南红塔银行、深圳农商银行等新一代核心系统，以及某国有大行ECIF系统等均选择升级至原生分布式数据库。

2. 保险

近年来，保险行业出现了非常明显的行业变革特征，传统保险的经营方式，无论寿险还是财险都难以实现大规模增长。数字经济时代的到来让这一趋势更加明显，倒逼各大保险机构从跑马圈地式发展升级为高质量发展。

粗放式地不计成本获取客户和保单已经成为过去，从线下地推到线上获客、从人海战术到精英化代理人团队、从单一化产品到综合型/定制化产品、从单一保单销售到客户长期陪伴乃至发展多维高频业务。

要做到这些，保险机构必须进行数字化转型，通过IT战略和商业战略的有机结合，灵活响应业务需求、开发优质保险产品、提升服务质量和客户满意度、降低服务成本。保险机构的IT系统大致分为三类，保险系统业务全景架构如图20所示。

图20 保险系统业务全景架构

• 核心业务系统：满足产品定义（包括产品定价模型定义）、报价、批改、理赔、续保、再保等全流程保险业务需求，不同险种拥有单独的核心系统，是险企的刚需系统。系统提供精算、产品设计、核保等业务功能以及支持日常事务处理的技术组件，同时能够对接其他渠道、管理系统。
• 渠道系统：包括营销管理、银保系统、呼叫中心、电子商务等子系统，主要辅助核心业务系统进行营销展业。
• 管理系统：包括风险管理、客户关系管理、商业管理、财务管理等子系统，主要负责进行日常事务管理，功能模块可由数据中台提供支持。

在“互联网+”的大背景下，保险机构应扬长避短，结合自身特点，借鉴互联网金融的成功经验，从传统的烟囱式的IT架构转变为以“云平台底座+分布式数据库”为基础的一体化IT架构，从而完成业务模式的转型，最终实现弯道超车。

遵循国家自主可控的战略要求，各大保险机构也开始了新数据库的升级，近两年取得了不错的成绩，在不少系统积累了大量数据库升级迁移的成功案例。但寿险、财险核心业务系统仍然是数据库最后和最大的“拦路虎”，其难度超出其他系统不止一个数量级，是非常难啃的“硬骨头”，所谓“行百里者，半于九十”。

（1）寿险核心场景

保险机构的寿险核心业务系统重构频率比银行低，很多都有超过10年，甚至20年的历史，完全推翻、重构这些业务代码难度和风险极高，可以说既是宝贵财富也是沉重负担。寿险业务主要具有以下特点。

• 业务场景复杂：相比银行业务，寿险业务模式更复杂、业务流程更长、复杂查询更多。例如，寿险业务通常会有数分钟的长流程事务，相对而言，银行业务基本都是短事务；各类多层次嵌套子查询、关联子查询、多表关联比比皆是。
• 业务数据量大：寿险业务从客户开户、参保以来所有的历史数据都是“热数据库”，要参与计算，存量数据生命周期长，数据量的增长对业务性能有明显影响。而大部分银行业务超过一定时间的数据都不会参与计算，比如，超过1年的数据可以归档到历史库作为“冷数据”处理，不参与日常业务处理，数据量的增长对业务性能影响较小。
• 业务突发流量高：银行业务每天的时段业务量和业务种类都比较平均、非常有规律。因其行业特性，寿险业务经常有“开门红”“周周红”这样的促销活动，虽然日常资源使用率不高，但某些特定日期业务量突增，可能达到平常的10倍以上甚至更高。

过去，寿险核心业务系统基本90%以上使用传统集中式数据库，面对以上业务特点，随着数据经济的加速前行，其在容量、性能、云化、多模等方面都已经愈发力不从心。

一是复杂SQL、大数据量的性能挑战。在大多数场景，OceanBase均能获得和Oracle相似的性能；在某些特定场景，OceanBase可以通过并发获得比Oracle更佳的性能。值得一提的是，我们在进行优化时可以直接参考Oracle的执行计划，将之以hint的方式直接应用于OceanBase中，用于固化执行计划不准的SQL语句，大大降低性能问题带来的生产运行风险。

二是突发流量的挑战。如果按流量最高峰来配置集群资源，显然是一种极大的资源浪费。我们在支持历年“双十一”的过程中，锻炼出透明扩缩容的能力。在促销活动前，可以提前将准备好的物理服务器或云上ECS动态扩容到集群中；活动结束后，再缩容将机器归还，从容应对业务流量高峰。

某国有特大型保险机构的寿险核心系统数据库升级至OceanBase后，最大化利用资源，通过动态弹性调整租户计算资源，敏捷应对业务负载要求的变化，经受住“开门红TPS 5万+”、“QPS 21万+”的严苛考验，稳妥保障业务连续性和数据准确性。

某国有特大型保险机构核心业务群的60多套系统，300多套Oracle历时一年完成向OceanBase的迁移，数据库存储容量瘦身78%，数据库软硬件成本大幅缩减75%，实现RPO=0的最高级别容灾能力，满足国家级金融基础设施要求。

（2）客服系统场景

客户服务系统通常是保险机构关联关系最为复杂、商业数据库绑定程度最深、业务影响最多的核心业务系统之一。秉承“以客户为中心”的理念，该系统除了提供7×24小时服务外，还具有以下特点。

一是数据量庞大：随着互联网保险业务的开展，客户服务系统需要支持越来越多互联网类型的业务，这些业务不仅数据量大，还有瞬时高并发的特点。

二是割接要求高：客户服务系统上下游对接系统众多，客户服务系统停机窗口时间要求极短，对迁移及数据校验都是挑战。

以中国太保的“P17”为例，其是产、寿、健康、长江等所有子公司客户服务系统的整合，为公司6地8个客服中心超过2000座席提供系统服务。与一般热线系统相比，“P17”涵盖了中国太保几乎所有子公司业务的服务入口功能，包括车险报案、车险增值服务、非车人意报案、道路救援、寿险保单查询、寿险保全受理、投保预约等，对接周边系统超过200个。

“P17”对Oracle兼容性要求高。与其他保险核心系统一样，挑战最大的还是“P17”与原数据库的深度绑定。“P17”对原数据库特性使用非常深入，包括自定义锁、自治事务、嵌套表、索引组织表、PLSQL包、物化视图、DBlink、触发器、系统视图。其存储过程数量庞大，总代码量近百万行。

“P17”周边对接产品多。“P17”集成了大量周边工具软件和应用，与很多周边软件协同工作，如IBM Datastage、IBM Cognos等，这些软件都利用了原数据库很多特有的功能，更换数据库后需要对这些软件重新适配。

凭借OceanBase的高度Oracle兼容性、完善的迁移工具链，经过近一年的技术攻坚，“P17”完全迁移到OceanBase，百万行PL/SQL代码平迁复用。

在全面升级后，原生分布式数据库的优异性能展现出来。中国太保在保持高运行性能、高可用能力的同时，数据库软件的运维费用大幅降低，每年可节省设备投入数亿元。特别是OceanBase的高级压缩技术，结合“数据库瘦身”，将存储容量节省80%以上。可以说，升级后的应⽤系统弹性扩缩容、处理速度、数据加⼯能⼒均实现⼤幅提升。

3.证券和基金

自券商的主要经营方式由网点营业部模式转变为总部集中模式，在集中交易系统的建设背景下，关系型数据库的重要性愈加突出，以Oracle、DB2为代表的数据库产品几乎占据证券和基金的各类核心业务系统。

伴随金融数字化的全面开启，新形势下行业规则不断变化，证券和基金业务的创新争分夺秒，精细化服务客户成为重中之重。传统烟囱式、系统紧耦、信息分裂的系统架构已经无法适应当前的业务发展。

证券和基金行业的关键业务系统包括集中交易系统、理财系统、法人结算系统、第三方存管系统、开放式基金代销系统、风险监控以及反洗钱系统、网上交易系统等7小类系统，此外，还包括反欺诈引擎、数据平台、进件系统、催收/贷后系统、呼叫中心等。证券业务全景架构如图21所示，基金业务全景架构如图22所示。

图21 证券业务全景架构

图22 基金业务全景架构

核心系统整体上可分为两类，一类是以股票交易为中心的在线类业务，另一类是以基金/资管为中心的“T+1”业务。对于数据库而言，前者强调极致的低延迟与高可用；后者则通常涉及批处理、大事务、复杂查询、备份恢复，对数据库的综合能力有较高要求。

（1）UF3.0核心交易系统

证券机构的集中交易系统，对外与沪深两个交易所的系统对接，对内则与其他各种系统对接，具有投资者开户、证券交易委托和成交、各种维度的查询等功能。其中“委托”和“成交”是最主要的功能，也称为“路由”功能，同时还有资金买空或证券卖空的“监控”功能，以及“查询”功能。

传统集中交易系统通常直接引入一体机解决性能问题，但是众多系统仍以“竖井”的方式建设，配套硬件成本、部署成本等整体成本投入大。由于单体架构的先天限制，在容量和性能遇到瓶颈时无法横向动态扩容，制约系统的整体处理能力。

恒生电子的UF3.0采用分布式微服务架构实现交易、清算、管理的三大模块，整体架构设计与OceanBase相契合，提升业务处理能力，加快交易结算速度，提高证券客户满意度。UF3.0业务架构如图23所示。

图23 UF3.0业务架构

招商证券、东方证券等券商公司新一代核心交易系统选用基于OceanBase 的UF3.0支持整体IT业务平台，提供综合金融服务。

以招商证券为例，其OceanBase承载了包括 UF3.0、数据中台服务、Level2 行情数据等共计百套业务系统。用“国产原生分布式数据库+国产服务器”替换“中高配x86服务器+传统集中式数据库”，节约整体拥有成本约70%。其中，UF3.0将原先分布在不同数据库的全量历史数据集中到OceanBase，数据由原先的50TB压缩到5TB，自此招商证券的用户能够直接查询自开户以来的全量历史交易流水、进行远期历史查询，不再需要临柜办理，使用体验显著提升。

（2）ETF_TA系统

TA系统全称为开放式基金登记过户系统，用于记录投资者买入和卖出的基金份额，是基金公司的核心业务系统之一。TA系统和典型的OLTP业务（如在线联机交易）不同，清算跑批必须在规定的窗口时间内完成。

同时，TA系统属于比较复杂的“跑批”业务，涉及的数据量较大，计算逻辑也比较复杂，存在多表关联和复杂查询，并且步骤多。比如，清算过程中有串行的、复杂的对账查询，也有需要高并发的小事务清算，还涉及大量的文件导入导出。

因此，TA系统对数据库的综合要求较高，不仅要高稳定、高可靠，同时也要高性能。

OceanBase通过稳定的SQL引擎保障复杂查询的执行效率，完全满足系统的高并发、数据高并行的业务特性，通过多租户架构（如图24所示），支撑TA系统的分布式微服务架构，提升资源利用率。分布式数据库的扩展性，让TA系统跑批效率随数据库节点增加而提升，未来基金用户数、交易数上升时，能在不调整业务架构的前提下，通过数据库层的横向扩展支撑业务发展。

图24 OceanBase多租户的TA数据分布

易方达基金通过OceanBase的多租户与TA分片对应，分别设立了账户、清算、汇聚三类租户。将来如果业务量增长，扩容增加服务器后，可以把其中几个租户在线迁移到新的服务器上，这样每个租户的可用资源增加，对业务而言则无感。不仅如此，和从一开始就将设备部署到位相比，这种按需扩容还可以节省前期投资。

2022年底，经过一年的双轨并行之后正式切换到OceanBase独立运行，易方达基金的ETF_TA系统成为基金行业首个基于国产数据库单轨运行的TA项目，同时也标志着国产数据库在基金行业迈出的关键一步。

安信证券的新一代TA系统上线OceanBase后，登记过户的跑批清算时间由2小时降低为1小时，TA系统的清算时间缩短为原先的50%，对上下游业务系统而言，登记过户相关的整体运营效率得到显著提升。

华安基金也选用OceanBase作为ETF_TA系统的数据库，其采用主备集群架构，实现多地多活主备架构。华安基金利用OceanBase的Oracle兼容性实现应用微改造，大大降低了应用改造成本，并实现数据双轨并行方案，降低了“数据库+应用”双重叠加风险。

八、写在最后

感谢选择与OceanBase同行的每一位金融客户，感谢您的信任，金融行业对数据库有着最为严苛的要求，数据库影响面广、重要性高，在如此重要场景能选择OceanBase作为一个新的数据库，这份高度信任难能可贵，也来之不易；感谢您的建议，OceanBase从1.X、2.X、3.X到如今实现多项业内首创的4.X版本，产品能力持续提升，技术发展持续向前，正是因为有金融客户给我们提出大量宝贵的、出色的建议，很多关键输入都来自金融场景、源自金融客户。

“九层之台，起于累土。” 作为一款“根自研”的分布式数据库，OceanBase致力于打造负载关键业务系统的一体化数据库，让更多金融机构在数字化转型升级的过程中用一个数据库就能解决80%的问题，数据架构更加适应现代应用开发、AI延展等，并能享受一体化架构带来的技术红利。后续，我们将继续携手服务、技术、ISV等生态伙伴攻坚关键业务系统，为金融数字化转型贡献更大的力量。