本文来自微信公众号“twt企业IT社区”，作者/邓毓。
完全替换路线中的分布式方案应用场景有限、需颠覆性对应用进行重建、对于运维管理工具和管理机制的改动大，但在轻量级数据库和分布式数据库应用场景下有良好的用武之地。而完全替换路线中的数据库云化方案和平替方案，尤其是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”，进行相关运维管理工具的适配性改造或者重构，运维管理的相关机制、制度的变更等。
四、结语
通过针对完全替换和平替方案技术路线的对比，完全替换路线中的分布式方案应用场景有限、需颠覆性对应用进行重建、对于运维管理工具和管理机制的改动大，难以成为企业主流去“O”方案，但在轻量级数据库和分布式数据库应用场景下有良好的用武之地。而完全替换路线中的数据库云化方案和平替方案，尤其是PG数据库的方案，金融企业应用场景广泛，对应用、运维管理工具和机制的变动小，对存储硬件的投资更容易保护，更容易和更快被企业应用系统大面积接受，成为去“O”主流方案。
