本文来自twt企业IT社区，作者/twt社区。
【摘要】随着信创战略在企业当中不断推进，有的企业认为只要实现品牌国产化就完成了企业的信创战略，有的企业认为不仅仅要实现品牌国产化，更重要的是实现IT架构的全面革新，这才是真正的信创。企业的IT部门面对数据库信创转型时，同样会遇到这样的问题，会面临很多抉择，尤其是要不要将“分布式改造”作为项目目标。
【作者】赵海某金融系统高级主管
一、引言
自2018年，以实现“自主可控，安全可靠”为目标的信创产业被正式纳入国家产业发展战略，信创几乎成为IT圈内最热的词汇。以金融行业为首，信创战略在企业当中不断推进。有的企业认为只要实现品牌国产化就完成了企业的信创战略，有的企业认为不仅仅要实现品牌国产化，更重要的是实现IT架构的全面革新，这才是真正的信创。企业的IT部门面对数据库信创转型时，同样会遇到这样的问题，会面临很多抉择，尤其是要不要将“分布式改造”作为项目目标。
二、如何理解信创
国家提出信创战略的目的很明确，就是要实现信息技术的“自主可控，安全可靠”，作为企业信息技术的从业者应该如何理解这个目的和这个战略的深层次含义呢？
1.何为“自主可控”
作为国家来讲，考虑的是整个产业链条的自主可控，包括所有上下游节点的输入和输出。
作为将信息技术作为支持自身核心业务的辅助工具的IT消费型企业，自主不意味着简单的品牌更换，也不意味着IT走自主研发的道路。自主可控应该包含两个方面：首先，选择的工具是企业可以直接或者间接控制其使用权利和使用方法的。其次，选择的工具应该是符合企业自身条件的。
2.何为“安全可靠”
作为国家来讲，是以产业链条节点为基本颗粒度来考虑整个产业的安全可靠。
作为将信息技术作为支持自身核心业务的辅助工具的IT消费型企业，并不是说工具品牌国产化就能给企业带来足够的安全可靠。在产品替代的过程当中，需要把安全因素融入到IT替换的各个环节当中，尤其是项目落地过程。
三、再谈分布式
回到数据库转型这个话题上，避免不了的就是要谈数据库的分布式架构。
1.分布式架构解决了什么问题
2000年之前，伴随着IBM E.F.Code提出的关系模型理论，以关系型数据库（Oracle、DB2、MySQL）为企业的数据管理平台。2000年后，但是随着数据量的增加，单机的数据库瓶颈已经不能满足大数据量的需求，从数据管理层面开始诞生分库分表的方案。自2006年谷歌发了三篇论文（GFS、Big Table、Map-Reduce）之后，在数据管理层面以及数据载体层面不断涌现各类分布式数据库产品，例如Hadoop、Hbase、Redis、MongoDB、RockDB等系列分布式数据管理平台。从这些典型的分布式数据库所支持的数据模型来看，几乎没有看到主要为了支持二维关系型数据模型而诞生的分布式数据库。
简单粗暴总结，因为海量的非结构化或半结构化数据的涌现，才出现了分布式数据库的土壤。
2.分布式架构在解决问题的同时带来了哪些问题
这又回到对CAP（Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容忍性））理论的讨论上。分布式产品，无论是数据库产品还是其他什么产品，都回避不了这个取舍的抉择。在这三个因素的平衡当中，分布式选择降低C的期望，提升A&P的期望。但是这个不一定是所有数据库业务场景都有的期望值。
前述所提分布式数据库支持的主流数据模型几乎都是非关系型，如果将传统关系型数据库转型为对关系型数据不支持或者支持度不是非常好的分布式数据库，势必涉及到上层数据模型的改变以及数据存取方式的应用逻辑改变，这种动作就不仅仅是基础软件的转型了，会是牵动很多面很多人的复杂工程。
伴随着互联网企业的不断创新，号称可以将关系型数据库实现分布式架构的产品也开始出现并应用。这似乎解决了前述问题，但是有两点需要考虑清楚：一方面，无论怎样改造怎么创新，最终还是要平衡好CAP当中的三个元素，采用了相对复杂的策略在关系型数据库基础上提升对C的期望，这个代价一定不会太小，其稳定性和安全性是需要考虑的。另外一方面，互联网的创新多数是基于特定业务进行改造和创新的，它有特殊的适用土壤，同样的种子放在传统企业的IT环境当中是否生根发芽以及茁壮成长？
四、数据库信创转型的正确思路
1.数据库信创转型的主要目标
作为企业来讲，无论是什么样的转型都是有触动因素的。之所以进行信创转型就是顺应国家的整体科技战略布局前提下，保障自身企业IT的可控和安全。在满足这个核心目标的前提下，如果可以顺手完成企业IT其他的目标当然是好的事情。那么按照企业信创战略的核心目标指导，大多数企业数据库信创转型的核心目标其实在于消除数据库软件源头以及持续服务保障的不稳定及不安全因素，换成源头相对稳定可控并且服务相对可持续的国产品牌软件。
2.数据库信创转型过程的安全性与稳定性
数据库信创转型过程中首先面临需要抉择的问题就是“用什么样的国产数据库软件来替换现有的IO数据库软件？是沿用关系模型数据库还是更换为其他数据模型的数据库？是采用开源的软件还是其他商用的软件？是选择分布式架构还是延用集中式架构？”
2.1关系型延用还是升级为其他？
就关系型还是其他数据类型的问题，如果现有数据库并不是因为数据量、数据结构发生变化，也不是因为现有数据平台已经无法满足新业务创新带来的数据存取需求。那么我认为还是要选择同类关系型数据库产品。因为项目落地的时候不会涉及到业务层面太多的变动，不需要重新设计数据模型及数据结构，也不需要投入太多数据转换的成本。更重要的是避免了重新设计、重新整合以及数据转换过程带来的数据和业务风险。
2.2商用模式还是自主研发？
就产品开源还是商用的问题，如果企业属于IT消费型企业，自身并不具备数据库软件开发和维护的实力。那就尽量不要去选择完全的开源软件，这样会带来太多隐患的风险及不确定性。尽量还是要选择技术成熟度较高的商用软件，当然如何去评价一个商用数据库软件的技术成熟度，需要企业的IT人员设计自己的技术评估维度。除了技术评估维度，其实更重要的维度是关于版权和生态的评估，版权有争议或者有潜在风险的，产品技术生态圈没有足够话语权的等等，有类似问题的产品尽量不要去盲目选择。
2.3集中式延用还是分布式升级？
就分布式还是集中式的问题，需要认真做一个评估。
首先，目前或将来的数据业务层面是否有集中式无法解决的问题？比如说数据量的发展、数据结构的发展、数据处理性能的发展等等。如果没有的话，分布式其实并不是非选不可的因素。
其次，分布式带来的不确定性问题，企业的数据业务层面是否有很好的容忍程度？包括数据一致性、架构复杂性、运维安全性等方面存在的潜在风险。如果没有或者容忍度很低，那么分布式就不是在信创转型过程当中应该参杂进来的元素了。
再有，数据库转型过程当中如果因为升级到分布式架构而需要做很多应用层及数据层的改动，这个工作量和时间成本是否可以接受？如果不能，何必非要徒增烦恼。
简言之，数据库信创转型对于架构的考量应该站在数据高可用和数据容灾需求角度去评估，而不是站在所谓的技术先进性和创新性去评估。
五、结语
分析了企业在响应国家信息科技战略上如何定位自己的思路，分析了分布式架构解决的问题和带来的问题，最终我们发现这两个东西其实并没有直接的逻辑联系。信创转型需要在保障业务安全的前提下，定位好未来的自主和安全。分布式改造或者升级是应该由数据业务的发展催生的产物，而不是目标。所以，如果没有数据业务发展的内在驱动，笔者认为数据库信创的转型应该走平滑更替的路线。
本文来自议题企业传统集中架构数据库信创战略，究竟应该直接平移还是实现分布式改造？
