完全改造替换，还是平滑替换？从企业用户视角，数据库的变更不仅仅是数据库本身，还涉及到基础架构硬件资产、机房设置、应用开发、运维管理等等多个方面。如何分析各方面之优先及权重，厘清核心需求是本议题之宗旨所在。
本期为大家带来《迈向YB数据时代》2023年春季刊“趋势动态”栏目中的议题二：
平滑替换架构未来是否会成为企业的主流架构？
完全替换路线中的分布式方案应用场景有限、需颠覆性对应用进行重建、对于运维管理工具和管理机制的改动大，难以成为企业主流去“O”方案，但在轻量级数据库和分布式数据库应用场景下有良好的用武之地。而完全替换路线中的数据库云化方案和平替方案，尤其是PG数据库平替的方案，金融企业应用场景广泛、对应用、运维管理工具和机制的变动小，更容易和更快被企业应用系统大面积接受，成为去“O”主流方案。
一、引言
在企业信息系统中，数据库扮演着至关重要的角色，当前国内无论是大型企业还是中小型企业，其核心、基础、关键类信息系统的数据库架构仍然以传统的集中式存储+SAN交换机+集中式数据库为主。随着新技术体系的变革潮流，企业的信息系统架构正逐步从IOE变革到信创+开源+云计算的新的技术体系。当前变革实践正深入开展，这当中最困难、最复杂的变革当属数据库。这不仅仅涉及数据库自身的技术转换，还涉及数据库架构相关联的存储技术和应用数据库开发的变换。尤其当变革进入企业信息系统深水区时，这其中牵涉的因素将越来越多，例如数据安全、数据备份、数据库容灾、数据库运维、技术团队能力等等。因此在此背景下，如何将企业现有Oracle数据库架构稳妥迁移至开源+信创融合数据库架构，成为企业当前最核心最紧迫需求。
二、传统数据库架构现状及替换技术路线
企业现有的Oracle数据库架构通常有三种模式，底层均为集中式存储，数据库层为双机热备+Oracle数据库模式、Oracle RAC双活模式以及Oracle+DG读写分离模式。这三种模式既承载了高并发、短时延OLTP类数据库应用，也承载了高吞吐、大IO的OLAP类数据库应用。
目前存在两种传统数据库架构替换技术路线，一种是完全替换的方式，不考虑原有的数据库技术架构体系，采用全新的技术方向，如分布式数据库+分布式存储的方案，或者数据库迁移上云（专有云或私有云）的方案，如云上的MySQL和PostgreSQL方案，彻底抛开了传统的云下环境。另一种是采用“平替”的方式，是指在不重建应用系统，以及不大幅度改造现有Oracle数据库基础架构的前提下，以安全稳健、TCO最优的方式更替应用系统所用的Oracle数据库。原有的Oracle数据库平替成了MySQL或者PostgreSQL（商用或者开源），底层的存储架构保持不变，相比完全替换的技术路线，该方式大幅减少了应用层面的改造工作。
三、两种技术路线方案对比
针对这两种技术路线，哪种将成为自身企业的主流架构，企业又该如何抉择？这需要结合多方面因素来共同考虑。主要包括数据库的需求因素（当前数据库的负载类型、性能要求、功能要求、管理要求、高可用要求等）、应用改造或者更换因素（费用、难度、复杂度等，涉及应用本身及关联的应用系统两个层面）、技术转型因素（团队技术能力、技术管理能力等）、运维管理因素（与现有监控、备份、自动化等运维工具的契合度，以及对流程管理、应急预案管理、容灾管理的影响等）。下面针对这两种技术路线一一对比阐述：
1) 数据库的需求因素。考虑到传统数据库既有OLTP又有OLAP类型的工作负载，亦或是HTAP类型的混合负载。其不同的负载类型的性能要求也差异很大。采用平替方案时，应充分考虑数据库的应用场景，对平替的数据库和Oracle在不同负载类型上的性能进行对比测试。没有充分的测试就没有发言权，不同负载上的性能差异取决因素太多，包括SQL调优、参数调优、内核调优、硬件、网络等等，最重要的是无论是Oracle还是PG或者MySQL，其都有其独特的特质和缺点，但是了解什么功能适合应用并集成这些功能最终会提高性能。因此就目前而言，Oracle并非所有应用场景都性能优于PG或者MySQL等主流开源平替方案，或者说PG在大部分应用场景的性能可能已经接近甚至超过了Oracle数据库。对于完全替换的方案，有两种情景，一种是数据库上云，这种方式和平替方案基本类似，但需要注意测试云上块存储和专业共享存储的性能差异。另一种是替换为分布式数据库方案，首先该方案应用场景有限，并非大部分原先的集中式的应用场景都可以迁移或者必须迁移至分布式架构下，分布式数据库适用于海量的数据访问和处理造成传统的集中式数据库开始表现出性能瓶颈的场景，企业这样的场景不多，难以成为主流架构。其次该方案对于分布式事务的实时一致性难以保证，对于像金融企业数据库有强一致性要求而言，解决方案有限。
2) 应用改造或者更换因素。采用完全替换的方式可能将给应用带来颠覆性的改动，相当于应用的重新立项开发，推倒重来，之前的软硬件投入（硬件资源可能可以利旧给其他系统使用）无法保护，其相关联的应用系统也需要进行相应的接口改造和调整。通常而言，该方式只适合于企业当前应用系统功能、性能已不满足业务需求，迫切需要进行平台级、技术/业务架构级的彻底升级。当然有一种场景是例外的，例如应用上云的场景，原有云下的应用+Oracle数据库，通过应用的少量优化改造，匹配云上的PG等与Oracle兼容性好的数据库，代码基本上可以和Oracle实现一比一转换。该场景要求企业拥有私有云/信创云战略路线，数据库上云是其战略路线中的一项执行行动。而采用平替的方式的话，情况将更好，应用可以依旧运行在原有服务器上或者虚拟机上，存储依然可以采用原有集中式存储，充分保护了之前的投资，仅仅是数据库软件发生变化，应用进行微量改造，并进行数据库数据迁移。该方案非常适合于迭代较少、稳定性高的应用系统。因此，以应用改造因素来衡量的话，平替的方案可能更容易和更快被企业应用系统大面积接受。
3) 技术转型因素。该因素需结合企业内部技术体系，和团队技术能力来考量。由于之前国内大型互联网公司去IOE化的推动，其中实施方案中有一点就是将集中式的Oracle换为分布式的MySQL集群，利用MySQL可以通过水平扩展来解决性能问题，也就是所谓的完全替换的方式。久而久之更是形成了LNMP（Linux+Nginx+MySQL+PHP）的架构模式和生态，推广至其他非互联网企业，舆论上似乎形成了去“O”的事实标准。MySQL的技术专家也越来越多，不断加入至企业团队中，MySQL技术也逐渐融入了企业的技术体系。而金融企业目前去“O”尚属起步阶段，部分非重要和边缘系统也逐渐采用了MySQL系数据库，少量采用了PG系数据库，但大部分数据库主力军依然是Oracle、SQL Server以及Db2（农信主力）等数据库。在这种金融企业技术体系背景下，采用MySQL完全替换或者平替的方式似乎更符合企业现有技术能力和生态需求。但MySQL在目前金融企业的应用场景较窄，属于轻量级数据库，自身特性也不太丰富，适合业务逻辑简单的OLTP应用。因此，集中式MySQL的平替方案不太适合金融企业的去Oracle重型数据库的需求，不太可能成为金融企业去“O”的主流架构。而PG数据库由于数据库自身的特性非常丰富，与Oracle都属于重型数据库，天然适合金融应用场景，成为去“O”主力架构。但目前PG最大的问题是缺乏丰富的生态体系，仍需要一定时间成熟，逐渐融入企业技术体系直至被广泛接受。
4) 运维管理因素。采用何种替换的方式也需要重点考虑运维管理方面的因素。平替方案相对完全替换方案，对于生产的变动和变更更小，较多的复用使得原有的运维管理工具适配性改动更少，对流程管理、应急预案管理、容灾管理的影响也更轻，相应制度或者规程的调整也更少。但这并不是彻底否认完全替换的方案，仅仅表明运维管理因素也应该成为重点考量因素之一。例如结合企业的IT战略路线，使用分布式的方案来对部分迫切需要提升性能的统计分析类的数据库实现去“O”，进行相关运维管理工具的适配性改造或者重构，运维管理的相关机制、制度的变更等。
四、结语
李兆 某消费金融 数据库团队负责人：
国产化数据库浪潮起来以后，“平替”一词也开始火热。由于我们有大量的存量系统运行在Oracle、MySQL数据库上，所以我们希望不需要做任何改动，将这些系统迁移到国产数据库上。对于平替来说Oracle是最具难度的，MySQL相对容易一些，所以我的观点会着重考虑Oracle的平替。
一、引言
现在全国上下，政府、国企、银行、民企都走在信创的浪潮上，从硬件设备，到操作系统，再到数据库逐步开始选型。中美关系恶化，国际上俄罗斯的前车之鉴，国家对自主可控的需求越来越紧迫，所以近几年信创、国产化这些词每天都充斥在我们的耳边。国家的大趋势是无法阻挡的，那么我们也必须顺着洪流前进。
国产化数据库浪潮起来以后，“平替”一词也开始火热。由于我们有大量的存量系统运行在Oracle、MySQL数据库上，所以我们希望不需要做任何改动，将这些系统迁移到国产数据库上。对于平替来说Oracle是最具难度的，MySQL相对容易一些，所以我的观点会着重考虑Oracle的“平替”。
二、当前大多数企业的数据库现状是什么样的？
1.数据库类型方面
当前国内应用系统绝大多数运行在Oracle、MySQL数据库之上。在金融、企业、政府、公安中Oracle更是作为很多核心系统的基石，保障着各种关键业务系统运行。MySQL因为开源、使用成本低，在互联网企业中被大量的使用，MySQL的适用场景比较简单，很多应用系统仅把它作为存取数据的适用，业务逻辑放在应用代码中。
2.运维技能方面
由于Oracle、MySQL的使用量多，所以目前企业内绝大多数的DBA所具备的技能就是Oracle、MySQL的运维技能。Oracle官方文档成熟，MySQL开源多年，良好的学习环境、知识分享，使得这两方面人才济济。
三、当前信创环境下数据库选择面临的问题
1.信创浪潮下企业需要国产化转型
信创浪潮是国家政策，所以一定会落实且执行，目前大部分的金融企业已经在过去的2~3年间开始了国产数据库转型工作，一部分选择了数据库自研，如邮储银行、中信银行。还有一部分选择了在国产数据库中通过POC选型。金融、政府、国有企业将会是最早开始国产化转型的单位，民营企业也逐步有意识的开始向国产化倾斜。
2.国产数据库产品百花齐放选型工作难度高
国产数据库目前可谓是百花齐放、百家争鸣，经过一段时间的竞争，一定会大浪淘沙，沉淀下来一些优秀的企业。目前可以看到国产数据库基本走三条路线：自研路线、MySQL二次开发路线、PostgreSQL二次开发路线。而在众多产品中选型，仅仅是前期交流、POC测试、反复的和领导汇报这些工作就会耗费很长时间，我了解到一些企业耗费1~2年的时间来进行选型。不过在这些数据库的功能支持中，对于Oracle的“平替”必须是标配，而不是选配。所选型数据库厂商应该具备强有力的技术支持能力，同样也需要数据库厂商有成熟的官方文档对外开放，最好是有技术社区进行技术交流。数据库厂商越乐意分享自己的技术，走的就会越远。
大量企业在选型时会担心所选数据库的稳定性、性能、对Oracle的兼容能力等关键因素。目前国内的数据库，有分布式数据库、单机关系型数据库，这也让大家眼花缭乱。关于分布式数据库系统是有一定的互联网公司基因的，由于互联网公司在大量的使用了性能较弱的MySQL数据库，为了承接海量的并发，不得不使用多个数据库节点拼接成一个大集群来获得更强的吞吐能力。分布式技术近些年被一些金融企业引用，不过有的企业做的不太好，为了分布式而分布式，搞得系统经常宕机。分布式技术有天生的短板：多副本的数据，Raft、Paxos等分布式协议会增加事务的处理成本，如果1毫秒的交易，放入到分布式系统可能会放大到2毫秒或者更高。其实在DBA的同行间都有一个共识，单实例的数据库可以满足80%~90%的系统要求，分布式的系统对于真正有负载压力的系统才有作用，而且分布式系统的集群十分耗费硬件资源，成本开销巨大，可见上分布式的企业，一定是大金主，资金实力雄厚。
3.新技术储备不足人员转型压力大
新型的数据库使用一定会加大现有运维人员的运维压力，这就要求运维人员及时学习新的数据库使用工作，由于数据库运维是一个需要多年沉淀在一个类型的数据库上才会有一定专家能力的工作，所以短期的成为新型数据库专家是不现实的事情。如果国产数据库想要入局，那么就应该提供一个比较完善的运维平台，而且是集成了数据库厂商众多原厂专家智慧的平台，这样可以降低人员的学习成本，可以快速上手一个新型数据库，具体的专家技能可以在运维过程中逐渐积累。
四、平替架构未来是否会成为企业的主流架构
1.平替架构适用于哪些系统
个人认为“平替”架构适用于一些自研或者一些外包厂商能力较强的系统，因为需要在国产数据库迁移时配合改造一些适配的工作。MySQL由于使用场景单一，可以快速的迁移到国产数据库上。
而一些ERP系统，SAP、EBS等国外厂商需要相互认证的系统基本不可能平替，除非直接自研重构，不过重构这个工作，对于大型成熟稳定的企业来说是十分危险的事情。
关于“平替”，国产数据库是具备“平滑”能力，还是“平等”能力，值得我们深入考虑。“平滑”可以使得我们的系统无感迁移到国产数据库上，“平等”可能只是做了相关的兼容能力，但是实际运行起来问题非常多。
虽然现在国产数据库风头正盛，但是如果没有稳定、高性能、高度兼容Oracle等存量数据库，也不会被各位用户关注，关键还是得核心技术过硬，如果仅仅是花架子，很快会被拍在沙滩上，浪潮过后才能看到谁在真正干事，谁在裸泳。比如IBM AS400跑Db2数据库可以维持稳定运行众所周知，据说的有的银行核心三十年不宕机，仅此一点，目前市面上的数据库都无法与之匹敌，即使去IOE最盛行时，“I”也在各大银行核心位于不可替代的地位。对于数据库来说用户并不希望数据库有多少花里胡哨的功能，而是希望高效、稳定、不需要天天修BUG，Oracle时至今天也被众多的金融、银行、证券所使用，正是因为其高效、稳定。所以说仅仅是功能兼容的替换走不长远，更希望国产数据库在性能方面、稳定性方面越做越好，练好基本功。Oracle每年会投入数十、数百亿美金到研发工作中，可见数据库研发是十分烧钱的项目，如果研发投入不足的公司，也可能有产品倒闭的风险。
2.“平替”架构是否会成为主流架构
未来一部分简单且易迁移的系统会平移迁移到国产数据库中。但是仍然会有一定的存量系统运行的Oracle上，这些系统一定是深度依赖Oracle的功能，如存储过程、全文索引、特殊函数等，这些功能目前国产数据库还无法实现或者实现了的性能有待考究。
在新建类的系统，我们可以快速的向国产数据库倾斜，不过一定要选型一到两家比较适合自己企业特征的数据库系统，两条腿走路不容易被绑死。
五、结语
张锞斌 招商银行数据库架构师：
在云计算的加持下，在“集中式数据库+集中式存储”架构高度成熟下，国产数据库已经有能力对传统的数据库进行平替。信创会成为未来几年国内基础设施建设的常态，国产数据库只要解决了商业服务支持、产品本身的稳定性等问题，通过各方共同努力，培育更加完善的云计算及开源数据库生态环境，必将被大量的运用到实际的生产环境中。
一、国产数据库的优势
除了信创的要求外，国产数据库还存在以下优点：
1. 成本效益分析
相对于传统的集中式大型数据库，国产数据库对于硬件等基础设施的要求更少。传统的数据库要求高端的服务器、高端存储设备和专用的网络设备，投入巨大，同时软件本身的License费用也很高。国产数据库通常采用更加通用的部署方案，可以支持通用硬件的部署方案，在硬件成本和软件License的投入上更少。
2. 灵活性与适应性
国产数据库很多采用了新的分布式架构，在部署方式和基础设施选择上更加灵活和适应。云计算已经成为最重要的基础设施，数据库如何适应云时代，成为选择数据库的一个重要考量，传统的数据库是主机时代的产物，不能很好的适应云时代弹性、故障迁移等特性，对云原生应用不友好。国产数据库由于起步较晚，很多是云时代的产物，基于已有的开源产品进行打磨，为云而生，更加灵活和具备适应性。
大部分的国产数据库都是满足开源数据库的规范，兼容开源数据库的语法，能很好地与各种其他开源技术集成，构建信息安全的应用系统。同时架构层面也基于开放架构，可实现轻松的水平和垂直扩展。
3. 开放性
随着互联网时代的到来，数据存储的需求和要求也在不断地发展和变化。如今，大量的应用依赖于庞大的数据存储系统，以保障其高效、稳定和安全地运行。互联网时代的数据存储需求很多，以下是其中的一些方面：
1）容量：互联网上的数据量在以惊人的速度增长，这就要求数据存储系统提供足够的容量来存储这些信息。从个人用户的照片、视频、文档，到企业级的数据库、应用程序等，数据存储的需求几乎无处不在。
2）可扩展性：随着数据量的持续增长，数据存储系统必须具备良好的可扩展性。云存储技术应运而生，提供了一种高度可扩展，可根据需求自由调整规模的数据存储解决方案。
3）低成本：互联网公司在成本控制方面的压力越来越大，因此采用成本效益高的数据存储方案是必要的。开源技术和创新的存储架构在降低成本、提高性能方面发挥了关键作用。
4）数据分析：在互联网时代，数据被认为是一种宝贵的资源。通过对大量数据进行分析，可以为企业提供有价值的洞察和决策支持。因此，数据存储系统需要支持丰富的数据处理和分析功能。
由于国产数据库的后发优势，借助开源社区的能力，在种类上更加的丰富，在功能上也更能符合现代互联网应用的需求，这是国产数据库相对于传统数据库的一个巨大优势，在容量、可扩展性、成本和数据分析能力上可以取得较大的突破。
二、面临的挑战和解决方案
1. 性能和安全性问题
首先，在性能方面，Oracle等商业数据库管理系统（DBMS）通常会经过专业团队进行深度的优化，以提供更高的性能和稳定性。然而，许多国产数据库实际验证的时间和场景所限，尽管在某些场景下可以达到类似甚至更好的性能，但它们可能没有经过同等程度的优化。尽管如此，对于许多非关键业务应用程序和小型企业来说，开源数据库的性能仍然足够强大。
其次，在安全性方面，Oracle等商业数据库产品通常会配备更强大的功能，如内置安全功能、访问控制和加密等，从而可以更好地保护企业敏感数据。同时，商业数据库厂商通常会更加注重安全漏洞的修复，以便更快地发现并解决问题。然而，国产数据库虽然也具备安全能力，但往往需要用户自己配置和维护。在安全漏洞的发现和修复上，目前看来实效性也不如传统的数据库厂商。
2. 传统应用改造
国产化数据库的大规模使用，还面临着一个巨大的挑战，就是应用的改造问题，这里存在这两种技术路线。一种是数据库尽量的兼容原来的传统数据库的使用习惯和语法，尽量减少应用的改造成本；一种是对应用进行改造，使其能够更好的利用新型数据库的特性，更好的发挥不同数据库的特点。
第一种方式的挑战在于语法和已经使用场景的兼容，众所周知，由于传统数据库基本被Oracle一家垄断，Oracle使用了大量的私有语法和函数，要完全兼容，对于数据库解析引擎是一个超大的工作量。而且一些未知的行为也会导致兼容性问题。另外场景的完全兼容意味着再造一个传统数据库，由于国产数据库在架构，引擎上的区别，通常无法达到100%的替代效果。
第二种方式的挑战在于应用的改造。基于SQL和其他的数据库访问标准，提供个性化的数据访问能力，才能够发挥本身数据库的优点，降低不良效果。如分布式数据库在实现分页查询、数据一致性保证的时候就存在着与传统数据库不一样的算法，应用只有遵循分布式数据库的规则，才能保证数据库的高效运行。
3. 技术支持
数据库属于重IT资产，是信息系统的关键组件，数据库的问题会直接导致业务系统的瘫痪，甚至是业务数据的丢失。加上数据库涉及复杂的硬件、软件和算法，一旦误操作，造成的后果可能是灾难性的。所以在企业中，数据库的运维支持一直是最受重视的。相比起传统的数据库厂商，国产数据库在技术支持这块还有待加强。
4. 生态建设
国产数据库不仅面临传统数据库的压力，还面临各种开源数据库的挑战。传统数据库经过多年的储备，整个生态已经相对的成熟，不仅有各种适配工具可以选择，各种软硬件的优先兼容性测试认证、各种大型商业软件的兼容测试。国产操作系统在生态这块面临着许多挑战，首先是兼容配套工具缺少，特别是一些性能调优工具和运维工具，大大影响了用户的使用体验。国产数据库目前属于战国时代，项目之间的竞争激烈，可能导致资源分散、合作困难。很多项目都在争夺有限的人才、资金和市场份额，甚至可能造成功能重叠和技术垄断。
国产数据库同时面临开源数据库生态的挑战，开源数据库紧跟技术前沿，技术迭代迅速，新的技术出现可能会快速颠覆现有的技术。
对于数据库，不同行业对技术的需求和接受程度不尽相同，如何因地制宜地进行推广和落地，是国产数据库生态建设的一大挑战。总之，要实现国产数据库生态的持续健康发展，需要克服诸多难关，共同推动各方参与，形成良好的发展势头。
三、结论
通过本议题的讨论，完全改造替换场景有限，需要颠覆性对应用、运维管理和管理机制进行重建，难以成为省农信、城商行等金融企业主流的去“O”方案。实现对Oracle的平滑替换，对应用、运维管理、管理机制等变动小，对企业硬件投资更容易保护，是实现Oracle数据库国产化的主流需求。
阅读更多《迈向YB数据时代》精彩内容，请识别以下二维码：
《迈向YB数据时代》
更替Oracle数据库项目是多个行业2023的排名前三的应用趋势项目。用户反馈更替需求中，不管来自城商行的用户，省农信用户、证券基金用户，甚至是容器化进程最快的保险行业等用户，平替Oracle才是当前最核心最紧迫需求。希望社区聚焦服务如何平替Oracle，服务内容从架构到技术路线，具体产品选型，以及关系到数据安全稳定的存储如何选择。
《迈向YB数据时代》2023春季刊为社区展开一系列平替需求下的用户服务正式拉开帷幕，本期的主题为“平替Oracle”架构下的存储应用。期待读者可以从应用场景、到架构、到解决方案，到落地，到运维，到人才培养等多个角度，通过群体专家的力量，在多个核心议题中产生共鸣，获得一定的决策参考。
2022年冬季刊【精细运营】议题三：信创存储在信创新生态下如何运维？
2023年春季刊【趋势动态】议题一：大中型企业关键应用数据库未来会如何走向？
*本公众号所发布内容仅代表作者观点，不代表社区立场
