共计 2948 个字符，预计需要花费 8 分钟才能阅读完成。
作者：安信证券信息技术委员会运维部零碎平台室 刘盛彩、肖昭、张杰
起源:《金融电子化》
近日，《国务院对于数字经济倒退状况的报告》（以下简称报告）提请十三届全国人大常委会第三十七次会议审议， 报告提出：“深刻施行翻新驱动倒退策略，推动要害核心技术攻关，放慢锻造长板、补齐短板，构建自主可控产业生态”。
安信证券作为证券行业信息技术利用翻新第二批试点单位，鼎力推动信息技术利用翻新工作，并在要害基础设施——数据库的利用翻新中，率先将原生分布式数据库 OceanBase 利用于重要的资管清理场景。随着我的项目从适配到投产，给安信证券带来了若干技术红利，包含多租户、高并发、高压缩等，同时促成厂商打磨了数据库在重度 ETL 数据处理、简单剖析场景的若干能力，并推动数据库厂商与利用开发商之间的对接落地，共建产业生态。凭此，“安信证券资管清理重要业务零碎基于 OceanBase 的翻新利用实际”我的项目荣获“2022 第十三届金融科技利用创新奖”。
分布式数据库选型剖析
最后进行数据库选型时，安信证券重点关注分布式数据库产品将来是否可能撑持更多业务场景，达到增效降本的目标。同时，咱们也对分布式数据库有两点忧愁：首先，如何找到适宜“分布式”的业务场景？其次，是否会因为引入分布式数据库导致硬件投入大幅增长？对于 OceanBase，咱们认可其多租户体系、兼容性、高可用以及其在多个头部大型券商的落地案例。
支流的商业数据库 Oracle 在 12C 版本提供了多租户（PDB）个性，OceanBase 同样基于租户对外提供服务，并在内核上人造反对 DBaaS。如果说分布式数据库因为多正本的个性，天生须要更多硬件资源投入，那么多租户则是无效晋升整体资源利用率的要害。 经调研，安信证券理解到，OceanBase 的多租户体系可能把投入的硬件资源池化，再按需分配为不同的资源对象（租户）供各个业务应用，租户之间数据不互通，并且具备资源隔离的能力。
同样是为了晋升资源利用率，原生分布式数据库与单机多实例状态相比，原生的多租户升高了保护对象实体——“过程”的数量。“过程”数量的升高，能够无效升高引入分布式数据库带来的节点数量增长，将大幅晋升数据库版本升级、备份复原、主机变更等日常运维的操作效率。
此外，OceanBase 的租户可能同时提供 Oracle 和 MySQL 两种兼容模式，即同一个集群中能够同时创立 Oracle 和 MySQL 类型租户，并且都具备较高的兼容性，根本能够做到仅需少许批改即可“平迁”到对应的租户中。这将让安信证券在数据库国产化选型时无需引入过多数据库类型。
资管清理，重要业务零碎翻新实际
安信证券是首批将资管外围业务 TA 下移到国产数据库的券商。除此之外，咱们也逐渐实现了投资者动静、估值清理、融资征信等多个重要清理类业务的并轨投产。其中，OceanBase 的多租户架构、语法兼容能力、SQL 优化器能力是可能撑持上述场景的要害。
尽管 OceanBase 属于分布式数据库，但却可能走不同的技术路线。一类是“平迁”路线，即依附数据库本身的数据分布、高压缩比以及 SQL 引擎，将 Oracle 的数据平移到一个大规格租户，达到只换数据库不重构业务的目标；另一类则是“拆分”或“重构”，将不同的小规格租户作为承载不同分片的对象，并将其 primary_zone 散布在不同物理节点，高效利用集群各节点算力。
对于投资者动静、融资征信等零碎，安信证券抉择了“平迁”路线，这类零碎的数据处理逻辑往往交融在数据库的过程语言中（如存储过程、匿名块、程序包等），并且不可避免地存在大事务、简单查问。此类零碎通常不具备齐全重构的条件，因而其迁徙须要重点关注对象（包含表、分区语法、存储过程等）兼容性，以及简单 SQL 的性能，这两点是决定新数据库是否可用的关键因素。
在此类场景中，DBA 团队须要全程参加，相熟数据库厂商提供的迁徙工具，把控整体迁徙流程，并且在灰度阶段追踪慢 SQL 状况。对于执行打算不稳固的 SQL，依据数据变动状况，应该人工染指绑定执行打算，或提前收集统计信息，为优化器提供更精确的根据。
当单个租户呈现容量或性能瓶颈后，通过减少租户 unit，该租户的局部数据将转移到新的硬件节点，实现数据库平滑扩容。同时，数据从“集中”变为“散布”，局部 SQL 将从单节点拜访变为跨节点拜访，提早天然会增大。因而，对于要害高频清理 SQL，可采纳分区联合表组的技术，将不同表中有雷同数据的分区，搁置于同一个节点，尽可能达到“数据跨机存，SQL 本地跑”的成果。
对于 TA 等简单清理零碎，以后支流开发商的新一代 TA 抉择“分而治之”的解决形式，这也是大数据量批处理的典型优化形式。在此类场景中，依据跑批个性梳理拆分的用户，可将若干个不在同一时间点跑批的用户放在同一个租户中，晋升整体跑批效率。当 TA 整体数据量较大时，能够适当地进行分片；当单个租户呈现瓶颈后，通过集群内扩容可将租户迁徙到新硬件，而后进行租户规格扩容，满足业务增长需要。
同时，拆分后不免须要解决“汇聚”的问题， 对于数据量大的零碎，汇聚库中的大表能够抉择适合字段进行分区，防止租户中呈现超大表拖慢集群合并工夫的状况。
翻新成效显著，将来更可期
安信证券此次以 TA 为代表的清理跑批业务顺利完成试点验证，同时也实现了行业内首次大事务 OLAP 场景的落地验证，为证券行业造成了一套可参考的规范计划。新一代 TA 业务上线 OceanBase 后，跑批清理工夫由 2 小时升高为 1 小时，TA 零碎的清理工夫缩短为原先的 50%，对上下游业务零碎而言，注销过户相干的整体经营效率失去显著晋升。
OceanBase 原生分布式数据库内核人造反对多租户，对于有多个租户的集群，能够让不同租户的主正本位于不同主机，从而充分利用集群中不同主机的资源，这对安信证券初期须要事后创立多套数据库资源的业务而言，得以大幅节约运维老本。此外，OceanBase 良好的兼容性最终让业务在不重构的前提下，疾速实现国产化替换，安信证券也将迁徙革新老本管制在了肯定的范畴内。
以后，原生分布式数据库通过充沛验证，曾经可能在适宜的场景承载要害外围业务零碎，但其局部行为与传统集中式数据库仍有区别，在某些场景中须要留神其应用形式。以 OceanBase 3.X 版本为例，其少数治理动作仍集中在集群层面，如异地的主备切换、DDL 的解决等。好消息是，此类治理动作在 OceanBase 4.X 版本也将下沉到租户， 届时，集群内的不同租户将能够依照业务的工夫安顿，各自进行机房切换演练，在布局集群时有了更大的灵便度；对于 DDL 在分布式架构下的一些问题，也将从根本上失去优化。
随着各业务线对数据库资源需要的继续减少，DBaaS 将来应该与流程工单零碎相结合，业务方走工单申请数据库资源，将必要的信息带入工单（如数据量、架构、规格等），由 DBA 团队审批后，DBaaS 平台可能疾速实现数据库资源的创立并返回连贯串等必要信息。以后，OCP（OceanBase Control Platform，运维管理工具）曾经凋谢了丰盛的 API 接口，在安信证券曾经被下层运维治理 DBaaS 平台纳管，并实现了监控告警的对立。
将来，安信证券也将把租户的创立、回收、扩容等能力融入到 IT 服务工单零碎，进一步晋升数据库管理效率。