企业数据库信创转型过程中，数据库产品选型是最重要的环节，直接关系到企业数据平台当前及未来的发展。如能遵循正确的指导原则，抓住以应用场景、架构、数据保护以及工具利用等方面的关键因素，将会极大提升项目的安全保障。如能趁势实现业务的创新以及传统科技的变革，将会真正实现企业的蜕变。
一、引言
信创是国家近些年来的一项基本战略。信创产业作为战略性新兴产业，国家不断出台相关政策对行业的发展进行支持。政策扶持对于信创产业发展推进的意义重大，我国信创产业竞争力不断突破，国产化进程稳步推进，政策重点提及“数字经济”、“数字政府”和国家信息化。在信息化产业当中，数据库是企业信创战略当中非常关键的一环。但是大多数企业在面对这个命题的时候可能会感到迷茫，从最初的Db2、Sybase替换为Oracle是顺应单机架构向高可用架构转变的技术趋势，今天面临的是完全不一样的环境背景，那么今天的抉择又应如何考虑呢？
二、数据库转型的基本原则
其实作为企业信息科技来讲，无论做什么样的抉择，首要解决的问题就是应该遵循什么样的原则去做选择题。只有原则清晰才能指导具体的决策选择以及完善项目落地过程。就数据库的信创替换来讲，笔者认为要从国家战略结合企业自身发展维度去定制响应原则，具体说来有以下几方面：
1.符合“自主可控”和“安全可靠”原则
从企业自身角度出发，“自主可控”并不代表数据库产品品牌符合国产要求就可以了，而是需要考虑到企业自身对该产品的使用、升级以及维护有没有控制力度，这个控制力度是不是可持续。所谓的“安全可靠”也并不是说甩掉了外资因素的产品就一定是安全的，这个安全是要考虑到产品本身的源头技术是不是安全，产品的市场地位以及未来发展是不是安全。这个“安全”二字涵盖了知识产权维度、产品生命周期维度、源头技术维度以及产品使用维度。
2.最优契合度原则
对于企业的数据管理系统来讲，根据企业的行业、业务、客户等方面的差异，会导致其数据模型、数据量级、数据分布、数据存取有自己的特点。另外，其数据管理平台从架构、数据保护、性能、使用方式等方面的需求也会不一样。Oracle产品一代又一代的功能创新以及版本更新正是这些因素催生的结果。那么今天面对信创替换选型的时候，所选的产品应该具备以下两个必要条件：
①产品类型应高度符合业务系统数据模型、量级、分布、存取之所需。
②产品功能应覆盖数据管理平台的容灾、数据保护、性能、使用方式等方面之所需。
3.可持续发展原则
回顾Db2被Oracle替换的历程，不是Db2原始版本的性能不再满足客户需求导致的，也不是因为其成本昂贵导致的。笔者认为真正导致它退出历史舞台的原因是它的迭代发展速度以及方向背离了客户环境的可持续性发展需求。当廉价的硬件服务器替换掉昂贵的IBM小型机的时候，它选择的不是顺应而是牵制；当客户需要从单机、主备等架构模式升级到双活模式的时候，它的迭代没有跟上；当人力市场上随处可找到Oracle数据库管理员的时候，它的培训还是那么高傲。对于企业来讲，信创选型的时候难道还要重蹈覆辙再来一次替换么？当然，要想评估可持续这个因素，单从技术方面评估是片面的，更重要的是需要研究历史并且综合生态、市场、定位等很多非技术因素来判断。
三、数据库转型的关键因素
1.应用场景契合度
所谓应用场景契合度，包含两方面的意思：
首先，数据模型是不是契合？例如金融行业的账务系统是以二维表模型设计的数据库表，而信创选型的时候偏偏选择了以文档为主要数据结构的数据库产品。即使业务层支持，那么数据模型以及存取逻辑需要重新设计，数据需要转化，数据平台的架构配置等方面都需要面临巨大调整以及风险。这样的选择应该说契合度不是很好。
其次，拿金融行业的业务系统举例来说，有些系统是以少量数据随机行为为主的联机业务，有些系统是以大量数据有序行为为主的分析类业务。数据库产品本身针对不同的数据行为场景也会有不同的类型及版本区分的，如果是错配了的选择一定会是糟糕的选择。
当然，实际情况当中需要考虑的细节因素会因为应用场景的多维度特点而更加复杂。
2.高可用及容灾架构契合度
数据平台的高可用及容灾架构对于金融行业来讲是非常重要的考虑因素。尤其是一些交易类的系统，通常容灾框架、节点高可用、数据读写这几个方面都是经过精心规划设计的。
容灾框架通常会是包含网络、平台、数据库、存储等几个层面的整体设计方案。那么数据库作为其中的一环，信创转型时不仅仅要考虑到产品本身的容灾架构契合度，而且要考虑到其是否能融入现有或者转型后的整体容灾体系。
节点高可用也是企业数据库平台的关键因素。这里不仅要考虑到产品是否可以实现ＡＡ的功能模式，更重要的是要考虑到故障场景下的切换机制以及性能极限时的分发机制。所以这里的契合度不在于功能层的实现，而在于实现功能的细节是否契合数据业务的需求。
数据读写伴随着数据量级的增加是需要精细化规划的，很多企业为了实现读写方面的隔离或者读和写的分离进行了大量的设计优化，并且付出了大量的成本。这要求数据库产品在读写识别方面与应用有很好的亲和度，在分发过程中有强悍的技术功底背书。如果信创转型所选的产品不能实现这方面的功能或者实现的非常弱，那么显然这应该归为契合度非常低的选型方案。
3.数据保护及恢复的契合度
数据保护是企业数据库为了保障数据的安全在存储副本、事务回溯以及数据备份方面采用的系列措施。例如Oracle的存储副本可以采用ASM方式进行多种冗余方式，提供多种的副本读写以及容错控制机制，正是这些灵活可控的优化设计参数才能契合企业数据保护的需求。对于事务回溯来讲，不同的产品对于事务记录的原理、颗粒度、持久化机制以及回溯的准确性、时效性以及可控程度会有较大区别。对于数据备份和恢复，更是要结合RTO、RPO指标，综合考虑其便利性、灵活性、安全性等方面因素。
所以，信创转型后的产品设计也应该有副本冗余、副本读写及恢复控制、事务记录及恢复控制、数据备份及恢复方面的丰富可选、可控、可优化的机制才能契合到契合的数据业务需求。当然，我们需要对这些机制的原理以及应用案例方面评估它的技术成熟度以及可持续性。
4.工具使用契合度
工具使用包含两个层面的含义：一方面是数据迁移替换过程中的工具，另外一方面是数据运维管理工程中所用的工具。
信创转型涉及到企业数据以及数据接口整体迁移到信创平台的全过程。这里面必然涉及数据转化、数据迁移以及数据测试验证等关键环节，这些环节的工作效率以及结果的正确都必须有相应的工具来保障。当然，这个工具有效性的评估不是依靠产品专家的讲解和说明，更多的是原理的分析和脱敏数据的验证。
信创转型之后涉及到企业的数据平台运维管理。不同企业对待数据业务的运维管理有不同的要求，但是通常来讲可以从数据指标监控、数据收集汇总、数据分析利用、数据平台变更、数据故障处理等几个方面来分析其契合度。当然，这里面不仅是数据库产品本身的事情，而是结合其生态上下游以及企业自身信创整体环境来综合考虑这些因素的契合度。
四、结语
基于企业传统数据库信创转型的场景，本文剖析了三个基本原则以及四个选型时应该考虑的关键因素，整体诠释了传统关系型数据库向信创转型的选型思路以及方法。实际场景中，不同的企业有不同的IT背景和不同的诉求，在把握核心基本原则和要素的前提下，谋求业务发展的创新和蜕变或许是一种更有积极意义和现实价值的转型，但是这种变革需要以业务因素为驱动力，组织业务、管理、科技等各个条线共同参与并推进的整体战略。期盼未来更有先行者可以站在具体业务场景的整体高度分享信创的业务创新和技术变革案例。