Oracle数据库国产化替换趋势中，如何规划数据库技术架构及选型交流总结

近年来，在全球国际的紧张形势、国家政策的大力支持、国内企业的不懈努力和行业应用的不断探索中，国产IT产品不断发展、生态逐渐健全。IT产业生态体系庞大，从产业链角度看，主要由基础硬件、基础软件、应用软件、信息安全4部分构成，其中芯片、操作系统、数据库是最重要的产业链环节，而数据库作为基础软件皇冠上的明珠，一直是国内数据库厂商奋发攻关和行业用户重点关注的对象。通过多方不断努力，数据库国产化趋势愈发明显，金融行业在数据库领域的信息创新不断深化，但同时也面临着，国产数据库产品种类繁多、技术线路迥异、规范标准匮乏等问题。传统的以Oracle、DB2等为主的数据库管理员，在信创的推动下，必然需要像国产数据库转型，提升数据库团队的技能和管理能力。那么“察而后谋，谋而后动”。在数据库国产化趋势中，数据库架构师如何借助数据库国产化契机，掌握企业数据库线路规划、技术标准、管理规范的主动权？快速提升国产数据库管理能力？建立以企业为中心的国产数据库生态？是每个企业IT架构转型发展中，技术架构及数据库管理员们必须面对的现实问题。

6月18日，基于twt社区的华为存储用户俱乐部组织了主题为“Oracle数据库国产化替换趋势中，如何规划数据库技术架构及选型？”的MVP赋能活动，邀请来自银行的存储专家与华为专家进行分享，华为存储MVP及MVP候选人共同参与探讨。

社区根据用户专家、MVP、潜在MVP的反馈，甄选了在该主题方向下的核心议题：

议题一：企业如何规划国产数据库的容灾架构和管理机制？

议题二：如何规划数据库存算架构（存算分离OR存储一体）？

本次活动邀请 江西裕民银行高级系统架构师李先科担任本次赋能活动的主持人，民生银行数据库专家孔再华担任用户分享专家，华为数据库存储解决方案设计和拓展专家张羿担任本次活动的分享嘉宾。本次交流活动 共同探讨国产数据库的容灾架构、管理机制、存算架构等方面面临的困境，深入交流数据库国产化在金融行业运用的实践和前景，协力推动金融行业数据库国产化进一步发展。

此次活动共有51位华为存储MVP及MVP候选人参与，其中银行用户24人，占比为47.05%，其余用户来自保险、证券等行业。

在用户专家分享环节， 孔再华老师分享了《金融行业数据库国产化替代技术架构及选型思考与实践》。首先介绍了在科技有国界的大环境下，金融行业数据库自主可控建设面临信息系统范围广、难度大，对系统稳定性、数据安全性要求极高，容错空间极小的现实困境，进而披露了参与调查用户反馈企业信创数据库选型考量最为重视的几项因素是：基础功能、售后支持能力、高可用架构、可运维性、可维护性。其次，阐述了以共享存储、数据库同步、存储复制、DB日志同步为核心的HA及DR数据库高可用容灾技术。最后，就开展国产数据库“平替”迁移在入门、迁移、测试、生产各阶段中应完成的规定动作进行了详实介绍，并重点突出在迁移全过程中要及时开展各类检查，不仅要注重数据迁移的数量，更要加强对数据迁移质量的检查。

在华为专家分享环节， 张羿老师分享了名为《基于存算分离架构的数据库存储设计方法与实践》的内容 。首先，通过分析当前 采用存算一体架构的数据库在实践中在可靠性 ， 性能 ， 以及运维方面的一些挑战 。在当前存储/传输能力大幅提升的背景下，再结合计算/存储侧创新技术的引入让存算分离+共享存储架构成为了金融行业分布式数据库的最优架构选择。 其次，详细介绍了华为OceanData 解决方案，该方案具有存算分离减小故障域、全局缓存实现事务强一致性、专业存储6个9的可用性；多读多写、并发访问、端到端NVMe和存储算法优化保证低时延、算力下沉、存储参与计算；RAID替代多副本、减少设备数量、降低运维成本、支持大表，降低业务改造成本高等优势，该方案既是Oracle的替代，可以为分布式数据库提供强一致性异地容灾能力，同时通过华为自研存储引擎加持专业全闪，可实现MySQL存算分离架构创新，满足银行核心业务高可靠、高性能要求的同时，还可降低运营成本。在客户实践中， 华为存算分离多读多写方案 已在 XX运营商上线， 成功 实现降本增效 ，对下一步参会用户开展金融行业数据库国产化替代具有重要参考意义。

互动交流环节中， 参会用户通过文字或语音的方式积极提出了自己在数据库国产化替换趋势中，如何规划数据库技术架构及选型中的痛难点问题，整体交流提问涉及的问题涵盖 国产数据库在服务器网络 、 CPU 、 磁盘、 数据存储设备选型 及技术架构等 方面，与会的专家老师也都相应给出了技术解答。精彩问答节选如下：

1. 某城商行用户 提问： 国产数据库在两地三中心或者两地多中心建设时，对网络专线带宽、网络延时有无硬性指标要求？在异地中心对CPU和内存配置有无具体要求？一般国产数据库在一个AZ域扩容时，是否目前有支持ARM和X86混合使用或者都是ARM情况下，是否支持鲲鹏和飞腾的混合使用？

用户专家孔再华回复：
国产化数据库在两地三中心或两地多中心建设时，暂未发现有特殊硬性需求。在架构设计方案中，有一种情况可能有变化。如现采用了分布式数据库，原来采用集中式数据库，那就需要考虑网络专线、带宽、网络延时等新需求。因此，建议在做灾备建设时，可尝试替换为使用数据库日志复制的模式，该模式对带宽占用比较小。对于硬件配置方面，需要依据各企业对容灾备份中心的定位来定，如要求能够全量的支持所有主要信息系统在异地运行，那么要求异地中心的CPU和内存配置基本上保持一比一的对应关系。但考虑到成本因素，很多企业在异地是冷备并不要求真正接受新的业务请求，此种情形可配备较低的CPU和内存等。但总体来说，随着金融行业对高可用性的需求，更多企业更愿意多投入来实现异地热备。

数据库在AZ域中进行扩容时，以高斯数据库测试为例，软件在不同的平台上是不兼容的，但它的数据库在不同的平台上又是兼容的，但即便是这种情况，我们建议尽可能避免ARM和X86混合部署。因为目前尚不清楚混合部署的模式会引发由于平台的不一致进而导致数据库内部在某些数据处理时出现不一致的情况，因此不建议混合使用。

用户专家张锞斌回复:
就网络带宽而言，需要根据业务负载需求而定；网络延迟而言，对于这种同城中心，可能要求延时在一毫秒以下比较好，超过一毫秒以上，不管是组备复制或集群复制，均会对整数据库系统的延迟产生较大影响。因此要求备份中心与主中心的光纤的距离尽量控制在五十公里之内，如超过五十公里，建议采用异步复制方式。

在硬件配置的方面，异地的CPU及内存配置，建议最好采用可支持百分百流量，以免失去灾备意义。关于混合部署，监于当前信创兼容性尚不完善，不建议采用混合部署。

2、某保险用户提问：银行哪些业务适合存算分离， 哪些 适合存储一体 ？ 在信创环境下，存算分离的最佳实践？能达到的最佳指标是什么样的？有没有推荐的对应配置 ？

用户专家孔再华回复：
存算分离 、 存储一体 基于没有高性能需求的业务而言， 区别 较小 。 但对于面向于A类、面向高TPS具有高性能要求的交易，如：手机银行、电子支付类业务更适合采用高性能配置下的存储一体模式。对于 数据量 巨大 ， 非常复杂的业务，例如大型分析类系统，则可采用 存算分离 模式，并通过主机 扩容 、 存储扩容来 满足业务需求。对于 重要的A类信息系统，建议采用传统的企业级 SAN 双活存储架构，该类产品成熟稳定且性能较好，分布式适合于大文件场景，带宽、吞吐等方面 均 有足够优势 。总体而言， 基础架构服务于业务， 具体采用哪种模式，仍应根据 业务 实际 需求 来定。 针对特定的 业务 场景选择对应的解决方案，并 不 是非此即彼，适合的才是最好的。

在信创环境下 ，存算分离目前尚处于 摸索 阶段。对泰山、鲲鹏、麒麟V10在硬盘选择方面，目前主要以SAS+ SSD 为主，更高端的，可采用NV M e。 总体来说 ，硬盘主要与选择存储 容量相关 。

华为专家祥坤回复：
目前基于金融行业实践，存储一体会出现CPU和存储资源不协调，CPU使用率较低，存储空间浪费的问题，这种现象在存储扩容的时候会进一步加剧，但存储分离则可避免这种现象。在业务量较小时，存储一体性能较高；业务量较大时，存算分离整体性能要高于存算一体，且该结论经过了测试验证。

在存算分离实践配置方面，就华为而言，如果采用捆绑模式，鲲鹏有48核、64核，建议至少配置48核，网卡配置建议不低于25G。在硬盘的配置上，建议采用SSD或者NVMe，硬盘数量至少配置12块以上，服务器可用2G做系统，后端存储就可以配置Dorado 5600系列及以上。如果前端有多个数据库集群，后端存储可选择中高端配置，后期扩展性会更好。

3.某财险公司用户 提问： 存算分离架构必然涉及通过网络大量传输数据，如果前期没有做好网络规划，生产过程中就容易导致网络出现瓶颈。请问在网络 层 应该如何规划？是否规划业务层与数据 同步层分离 ？是否考虑多口做bond?用bond几比较合理？

用户专家孔再华回复：
存算分离后， 必然需要 通过网络大量传输数据 ， 业务层与数据同步层 也必然是 分离 的 。 对于网络带宽bond口方面，目前主要采用 负载均衡 模式 。

华为专家祥坤回复：
存算分离架构模式，前端计算，后端存储，网络成为了前端业务与后端存储的 中间管道 ，要求网络带宽必须是 高速无损的 通道，且不能成为瓶颈。现在大型 金融机构 需采购FC SAN光交 时 ，均需 提前报备 。 华为从14年 就开始致力于 做高性能 、 低延迟 、 零丢包 的 无损网络， 基于RDMA 协议 ，相关技术现已成熟。华为 一般 交换机 标准带宽是25G，如果担心出现 瓶颈，可考虑采用带宽为 100G。 在目前的实践中，暂未出现过 网络瓶颈 ，做多口bond可进一步增加网络带宽及端口高可用 。 目前华为的无损网络实践已应用于工行、 股份制 银行、证券行业，其中工行、 华夏 银行已 投产，是目前 符合信 创 要求 的较好 的 创新点。

4.某证券公司用户提问： 感觉存算分离架构和存储产品耦合太强，各位老师怎么看？

华为专家祥坤回复：
存储一体架构是将 数据 存 放在 物理 服务器上 。如果为非 重要业务 且 规模 较小 ，可以 采用该架构 。但如果 为重要业务数据，根据个人实践，建议采用存算分离架构。现阶段，存储技术 成熟 ，虽采用 集中式架构 ，但可使用打散等多种机制，可实现在 不同层面 的 分布式， 具有较高的 可靠性 ，至 少 可达 六个九，甚至可近 七个九。

存储一体存在 计算和存储资源不协调的 问题，很多用户痛苦于此的资源浪费，且短期内无法解决。对于关键业务、核心业务，采用 存 算 分离 架构，可独立、灵活扩容计算和存储资源， 多个集群 可 共用存储 ，且在存储扩容时可节约机房空间、耗能，降低 运维成本 。

因此，对于采用存算分离还是存储一体，需用户根据存算 分离后 在运营习惯、资源利用率、系统可靠性等多因素的 差异 进行评估 ， 做出 理性选择 。 你一定要做出自己的论证。

5.某银行用户提问：分布式数据库使用场景，哪些情况下需要使用分布式数据库？分布式数据库接入准则有哪些参考维度？分布式数据库是部署在物理机环境还是虚拟化加物理机共存还是虚拟机？数据分配使用sharding推不推荐？应用改造难不难？

用户专家于树文回复：
分布式数据库接入准则主要还是参考它的数据量、并发量等。从行内数据统计来看，符合使用这种分布式数据库标准的系统占比其实比较低。关于分布式数据库部署在虚拟化or物理机问题主要考虑如对性能的要求，不同分布式数据库产品，他的节点、数量可以不一样，但是从降本增效角度来考虑有一定影响。对于耗CPU高的应用来说，用虚拟机基本上还是可以满足的，但如果要对IO要求比较高的话，那可能还是考虑物理机比较合适。华为老师刚刚讲的后端使用集中式存储也是比较好的一种解决方案。

在数据库Sharding这块应用改造难度还是有的，采用Sharding主要为了规避全局扫描或者是节点间的交互，这块对于开发来说，主要的成本在于这种分布式的适配改造。

华为专家张羿回复：
分布数据库应用场景和接入准则方面，主要取决于企业的业务需求，是不是有海量数据、并发用户数是不是不可预测、业务的扩展性要求高不高等等，可以基于这些点去考虑是否采用分布数据库。

分布式数据库接入准则参考维度，可以从稳定性、可靠性、ACID（一致性）、负载能力、成熟度、周边生态等维度进行考量。

分布式数据库部署虚拟机还是物理裸机，其实在技术上讲都可以，虚拟机方式在故障追踪、后续运维、可靠性等方面存在一些风险，所以说如果是关键生产系统数据库的话，建议还是采用物理机方式更佳。

数据库是否采用sharding主要取决于你的应用，sharding是通过应用或者中间件来做拆库拆表，实质是把数据水平或垂直的分配到多个库上去依靠应用去做耦合，其实这是一个应用侵入式的一个改造。

6.某证券公司用户提问：站在降本增效、资源利用率方面来看，由于硬件性能的提升和技术栈的复杂性，使用方在使用国内外各种数据库上，不管是存算分离架构的分布式数据库、还是存储一体的集中式数据库（如oracle的租户）有一种统筹统管的趋势，大家如何看？

用户专家孔再华回复：
当前， 国外数据库、 国产数据库以及分布式数据库均采用统筹统管的方式 ，体现在数据库的 自动化部署 、 监控以及运维工具等方面 。 例如，Oracle 数据库 的DBA，如果同时 管理Mysql数据库，除去上述两个数据库 本身架构稍微有差别之外 ，对于数据库管理员而言，日常运维查看的是同一个平台、相同的指标 ，管理并无差异 。如果替换为信创数据库，运维模式基本上可复制原有模式，实现统筹管理。下一步，可能是实现云上数据库的统筹统管，进一步减少管理成本。

目前， 云上数据的标准化以及统筹统管正在建设当中。

本次活动中，针对Oracle数据库国产化替换趋势中，如何规划数据库技术架构及选型形成了诸多重要的共识，概括如下：

1、 企业如何规划国产数据库的容灾架构和管理机制？国产数据库容灾架构主要从两个技术方向进行规划：
第一、共享存储技术。通过成熟的集中式共享存储的双活、同步等技术进行数据库容灾切换。
第二、 数据库日志复制。通过数据库产品自身的数据保护（ADG/HADR）、数据库日志复制/重放等技术实现数据库的容灾。
同时，在国产数据库“平滑替换”迁移过程中，做好功能、性能、高可用测试，投产后编制好开发规范、避坑指南等工作，对日常生产运维尤为关键。

2、 国产数据库扩容时，是否混合使用？目前尚不清楚混合部署的模式会引发由于平台的不一致进而导致数据库内部在某些数据处理时出现不一致的情况， 且当前 信创兼容性尚不完善，不建议采用混合部署。

3、数据库采用存算分离还是存储一体架构？ 存算分离、存储一体 对 于都没有高性能需求的业务而言，区别较小。但对于 如下场景：
第一、 短时具有高性能 、低延迟 要求的交易 类业务 更适合采用高性能配置下的存储 分离 模式。
第二、 对于数据量巨大，非常复杂的业务 ， 则 建议 采用存算分离模式，并通过主机扩容、存储扩容来满足业务需求。
第三、数据库存储数据有容灾等需求，相比之下存算分离方式在两地三中心容灾方面有更成熟、更可靠的解决方案。

总体而言，基础架构服务于业务，具体采用哪种模式，仍应根据业务实际需求来定。针对特定的业务场景选择对应的解决方案，并不是非此即彼，适合的才是最好的。