本文来自微信公众号“twt企业IT社区”。
【栏目主编】Bryan某国有大型银行资深架构师：本议题由某农商银行架构师胡海光、某金融机构架构师李威、太平保险集团某省级分公司技术支持工程师张晓斌发表针对议题下关键点的主张，几位专家的主张在招商银行数据库架构师张稞斌、金电信科数据库架构师时朋泉及我本人等多位专家的复议后，形成了一定的共识，希望可以对同行有一定的参考。
李威 某金融机构架构师：
信创、开源和云计算，改写了数据库市场的未来走向。
纵观中大型企业关应用支撑，OLTP和OLAP仍是中坚力量，新生代数据库的推广和应用仍需要一定时间来积蓄。中大型企业的业务起步积累较早，此时关系型数据库正处在飞速发展时期，在业务系统的筹建、数据模型的设计、经济模式的拓展都与OLTP数据库的更新迭代如影相随，每一次数据库的重大更新都在推进着中大型企业向前迈进跃进，OLTP数据库也在企业信息化建设上占据上风。在完成初期业务积累后，数据分析及再利用的需求也加速了OLAP数据库的实践落地，随着大数据概念逐步融入信息化转型的进程中，湖仓一体化的分析型架构也现代信息基础架构上留下了一笔。
云时代的到来，数据库也能结合云原生架构和分布式架构的优势拓展与云上应用的联动能力。在云架构中，上层数据库应用可以选择应用集群部署也能够实现容器化落地。同时，数据库的底层结合云原生能力与云原生架构能大幅提高每个数据库元节点的处理能力，增强跨库跨表的联合查询性能、更加匹配中大型企业关键应用的横向能力要求。云原生能力对关键应用数据库的持续赋能必将是数据库进化的趋势之一。
2022年1月份至6月份国务院、工信部相继颁布《“十四五”国家信息化规划》、《关于开展“携手行动”促进大中小企业融通创新》、《关于加强数字化政府建设的指导意见》等政策，规划指出进一步提高自主可控水平，加强自主创新，加快推动数字产业化、关键核心技术攻关，以开源生态构建为重点，打造高水平产业生态，以软件价值提升为抓手，推动数字产业能级跃升。国内各信创厂商在MySQL及PostgreSQL等开源生态的基础上推出了企业级数据库产品。信创数据库在金融、电商、游戏、通讯等中大型企业的主要业务场景已经落地生根，其中基于MySQL生态的信创数据库QPS（每秒查询率）在实际交易场景上能够达到2万—5万次。基于PostgreSQL生态的信创产品最高每秒可以处理超过10万次查询。中国从不缺少诞生希冀的土壤，信创数据库的诞生与实践也用事实说明了“开源+信创”技术路线的可行性，借助开源技术机动起步与本土化资源有机结合，将“业务助力技术”这种业务发展推动技术更新的被动转化为“技术驱动业务”，技术根据业务的特性着力打造产品驱动业务在核心场景上落地的主动姿态。
疫情后经济形势的转变，也在潜移默化地影响着关键业务数据库的选型与更迭，数据分析类业务发展的刺激也将加速OLAP类数据库的崭露头角，高性能数据库支撑也在很长一段继续作为中大型企业核心经济业务的中流砥柱。在国家政策高基攻坚的指导以及信创生态的蓬勃生长下，信创数据库势必在未来的十年里占据一席之地。任何的专业能力沉淀到产品力，都将经历一段时间的馈赠，信创数据库的发展趋势亦是如此。这也是众多中小型企业对自主可控数据库技术最大的期许。
胡海光 某农商银行架构师：
得益于互联网业务和开源技术的快速发展，开源关系型数据库MySQL和PostgreSQL为代表的数据库相继诞生和快速发展，在现有数据库市场中崭露头角。
以大中型企业关键应用数据库未来的走向为题简要说明在开源和信创趋势的浪潮下数据库未来的发展趋势和脉络。
就数据库行业的发展和演变历程来看，大致归类为三大阶段。
1、前关系型阶段：1964年第一个数据库管理系统网状数据管理系统IDS开发成型，到1968年IMS系统作为最早的商用数据库管理系统正式发布，此阶段数据库主要用于解决数据独立存储、统一管理和统一访问等问题，与之相应的是缺乏相应的数据库理论基础支撑；
2、关系型阶段：1970年数据库关系型模型理论初步提出随后关系型数据库RDBMS诞生，SQL语言被国际标准组织定义为数据库国际标准语言并成为主流语言开始引领数据库变革，之后PostgreSQL、MySQL和Access等关系型数据库相继诞生，进一步丰富和完善数据库理论；
3、后关系型阶段：随着互联网技术的迅猛发展，数据结构发生层次改变，数据量级呈现指数级增长，为有效应对海量数据及多样数据结构，NoSQL和NewSQL等非关系型数据库产品相继推出，进一步丰富数据库使用类别和适应企业业务发展需求，也进一步促进了数据库相关技术的推进和发展。
贯穿数据库技术的发展历史，数据库经历了从理论的形成、发展到成熟，从架构的提出、优化到成型，从产品的打磨、丰富到迭代三个阶段，数据库已经奠定了一定理论和技术基础，同时在架构上也日趋成熟。在过去国内大中型企业对国外数据库产品（如Oracle、Db2、SQL Server等）的依赖程度非常高，普遍应用于企业的核心和重要系统业务上，当然由于国外数据库产品起步早，产品比较成熟，在产品稳定性和性能表现力等方面都处于领先地位，因此在国内企业数据库市场份额居高不下。
随着开源关系型数据库MySQL和PostgreSQL（简称：PG）为代表的数据库相继诞生和快速发展，得益于互联网业务和开源技术的快速发展，去IOE浪潮的持续深化，特别是国内一些大厂（如阿里、腾讯、华为等）以开源MySQL和PG为底层架构相继推出自家的数据库产品迅速打开市场，贴合和匹配企业用户的切身需求，赢得了一定的市场份额。
同时国际形势的快速变化及科技竞争的日趋激烈，我国在一些关键技术和关键标准的构建上经常处于较为被动的态势，为解决此问题我国提出“数字中国”建设宏伟战略，抢占数字经济产业链制高点。其中信息技术应用创新产业成为国内数据库行业发展的转折点。在信创改革的推进下，数据库的信创步伐早已完成布局、探索、优化及落地，对于信创的适配度和支持度也在不断提升。基于此，对于国内大中型企业来说，“开源+信创”是未来几年不得不面对的方向，也是企业数据库架构发展的趋势。
在信创的加持下，以数据库为代表的计算机软硬件产品迎来一波爆发潮。在积极支持和适配硬件信创服务器的趋势下，以信创和非信创两种技术路线并存，同时进一步改造和优化信创数据库产品，使之在性能和稳定性上能与非信创数据库并驾齐驱。
市面上使用较广的开源关系型数据库有MySQL和PostgreSQL两种技术路线，各有各的优势。PostgreSQL相比MySQL，有SQL的标准实现上要比MySQL完善、存储过程的功能支持要比MySQL友好、对表连接支持较完整等优势。MySQL相比PostgreSQL，有MySQL的优化器较简单等优势。
基于这两者的产品特性可以得出，PG更适合严格的企业应用场景（如金融、电信、ERP等）；而MySQL更适合业务逻辑相对简单、数据可靠性要求较低的互联网场景。当然两种技术路线数据库都有自身的优缺点，特别是国内几家大厂对于两种技术路线的数据库产品进行相应的改造、优化、改进和封装，在成熟度和稳定性上进一步提升，同时推出基于两种技术路线的相应数据库产品线抢占市场，也为大中型企业在数据库的选型上提供多种产品选择。
张晓斌 太平保险集团某省级分公司技术支持工程师：
如今业务系统纷繁复杂，应当结合不同的场景找寻最合适替换的数据库，这其实也是一个优化配置，实现价值最大化的过程。
以保险企业运营部门核心系统为例，核心数据库的建设与维护工作，集中体现在存储、流程、服务。存储方面，如我们的应用需求，首先要综合分析整个系统的容量规划，预计客户信息等数据量增长，数据如何汇总；流程方面，流程如何做到快速故障响应和服务响应，各个数据接口之间数据是如何串联的，如何进行统一查询与分析；服务方面，对应用系统开发部门提出的需求、日常变更能够快速响应和执行，怎么能让应用系统开发部门更了解数据库的运行状况，让其帮助自身做一些性能方面的检查，如何保证数据库的数据安全和访问安全也是重点。
大中型保险企业，核心关键应用数据库有三大核心需求：可用性、性能及安全。保险企业经营当以稳字当头，用户购买保险的目的是当客户遇到合同约定的问题时可以进行快速理赔，而保险另外一个功能是存放资金。以上都决定了保险的经营方式，而后台能够支撑得到理赔系统或是资金运作整个方面，数据库均需要有极其严格细致的要求。时间需要准确，数字更要准确。保险业务随时代发展而不断转变，同样作为金融业的银行系统，它的进步驱动保险业同样与时俱进，购买查询、保单查询、理赔查询一气呵成。再是需要应对监管要求，在整个大环境中，要求每笔理赔款项都不能出错。但实际上运维难度大，体现在磁盘和节点众多，一旦出现问题就难以管理。
保险行业的关键应用数据库正在经历国产化替代。如今国产数据库尚未成熟，很多关键应用还待以验证其可行性，在持续替换的过程中，企业或将面临数据内核、数据周边、整体迁移、运维自动化等几个方面的难题。分布式数据库是近几年的一个热词，金融企业关键应用一定需要用分布式数据库吗？并不见得。有三个事实不容忽视。第一，金融企业大多数业务复杂不至于集中式数据库处理不过来，或者做一些数据库的分库拆分就能应对。第二，分布式数据库从底层架构上有很强的的容错能力，但不同数据库这个能力参差不齐，在故障切换时，还不一定总是很平稳，而且人工无法干预。第三，保险企业要上真正的分布式数据库，业务需要做大量改造，这个改造、适配的成本往往是很大的。
原先Oracle数据库支撑了保险企业非常丰富的业务系统，现阶段几乎无法找到一款数据库产品能全方位替换，因此选择适合具体业务场景的数据库十分复杂而关键。是否一定要上分布式数据库需要深思。回归初心，我们不是为了分布式而分布式，寻求整体TCO最优、保障关键业务稳定才是我们做国产化数据库替换的核心。
结束语
数据库国产化势不可挡，“开源+信创”融合是落地数据库国产化替代的可行策略。数据库国产化≠分布式数据库。寻求整体TCO最优、保障关键业务稳定才是数据库国产化工作的核心。
