文章来源：微信公众号 ”信息化与数字化“

作者：沈旸

作为企业的科技战略决策者，如何看待数据库在企业数字化转型策略中的定位？

最近十几年，数据库领域发生了非常大的变化，尤其是有了云计算和分布式数据库以后。在2012年之前，市场上流行的大多数是商业数据库，例如Oracle，Microsoft SQL Server，IBM DB2，这三大数据库产品基本上占了商业数据库的大部分市场。比较清晰的分水岭应该是2012年谷歌发表的Spanner有关的论文，Spanner是个可扩展，多版本，全球分布式还支持同步复制的数据库。在谷歌发表论文之前，应该还没有其他的系统做到这一点。

对于非金融非互联网的企业，大部分应用系统都是跟企业管理相关的，例如CRM系统，ERP系统等企业内部的业务系统，这些软件多数都是商业套件。在2012年之前，数据库虽然重要；但是企业在决策的时候，更看重的是商业应用套件的选择，而不是数据库的选择。

这里面有几个原因。

一是数据库市场比较成熟，基本上就三大成熟的商业数据库可选，功能也都还比较完备，无论选哪一个对企业来讲风险都不是很大，运维团队也能承接的过来，更多的是考虑成本、性能和高级功能的平衡。

第二个原因，应用领域商业套件的产品种类比数据库要丰富很多，商业套件对数据库的支持适配各有不同，企业一般会根据业务应用的需求先选商业套件，然后再看这个商业套件支持什么数据库。例如如果你选的是IBM的Domino办公套件，就只能用IBM DB2的数据库了。

在非金融非互联网企业的IT组织架构里，数据库运维一直不是一个特别显眼的岗位，需要经常半夜加班维护或者迁移数据，经常背锅但是也很难出名。网络团队还能因为全网瘫痪而在公司出名，应用团队因为离业务更近从而容易体现价值。

那么最近十年发生了什么变化呢？数据库团队的地位上升了还是下降了？

数据库体系的技术和决策变复杂了

首先是互联网企业各种造轮子，发明了很多的开源数据库，也有很多数据库专攻一个方向，例如图数据库，文档数据库，缓存数据库等。随着谷歌Spanner论文出来的各类NewSql数据库和分布式数据库，选择变得丰富了起来，自然也就加大了决策的难度。

在2012年之前，数据库真的是个非常垄断的行业，新的产品很难找到灯塔客户来做小白鼠。在一个包含12节点，每个节点2T容量的内存数据库里，如果数据不一致的场景，数据基本上都没法Dump到磁盘上重现做分析。如果这种问题是偶发的话，在一个分布式的环境下很难跟踪到问题所在。大部分数据库都是私有部署，数据可能会涉及到敏感的信息，产品的支持难度非常大，一个疑难杂症可能需要几周甚至几个月的时间才能定位和解决，产品迭代周期很长。所以对于大多数客户来说，在复杂应用下的数据库很少会选用新的产品。如果新的产品没有复杂场景来做验证，又很难迭代成熟，成了一个死循环，所以这个市场新进入的门槛极高，技术人员也很少流动。如果没有云计算，SAP HANA内存数据的地位应该会比现在高很多，这个领域的突破难度实在太高，窗口期也很难找。

但是云计算时代的到来打破了传统商业数据库的垄断。在公有云上可以通过价格优惠，先引入一些小型的应用运行在公有云厂商自身的数据库产品上，如果出现任何问题在云端也很容易重现问题，产品的迭代更新速度加快了无数倍。只用了几年的时间，公有云厂商就打造了很多好的通用数据库产品，亚马逊、阿里这些云厂商也逐渐把自己之前用的商业数据库换成自己的云原生数据库。2019年3月底，亚马逊首席技术官Werner Vogels向亚马逊的物流团队发送祝贺，他们完成了该服务的最后一个 Oracle 数据库的迁移。

也有很多第三方的公司，利用云计算的优势，组合打造了很多独立的数据应用服务，例如Snowflake，Databricks等。不断变革的技术体系和各种组合方式，又形成了新的产品或者服务，整个体系越来越复杂，这种情况下，数据团队的地位也越来越高。

应用端的两级分化

云计算不仅仅对数据库的格局带来了很大的改变，各类开源组件的繁荣和SaaS应用也对传统的商业套件造成了巨大的冲击，这里可以参考之前的一篇文章：《全云时代来临之前的数字化转型之路》。

相对于商业套件，SaaS在一个细分的业务场景里提供了更多的应用的选择，但是在SaaS的产品中，企业是不需要考虑数据库的选型。如果一个企业主要用SaaS应用来做企业的架构设计，数据库就不那么重要了。SaaS系统之间的ESB（企业数据总线）和跨云的分布式数据库体系可以帮助企业数据资产进行合理的分布，避免出现数据孤岛和被“卡脖子”的窘迫。

如果一个企业主要是自研和定制化应用，那么数据库的定位比以前要提升很多。

因为开源组件的繁荣，低代码平台的普及，企业定制化也变得越来越普遍了。应用开始变得民主了，开发的速度也越来越快，越来越敏捷（不那么严肃了），可能用户1分钟就可以准好一个微信的调查问卷小程序。在这种情况下，流水的敏捷应用，铁打的数据库，即使这个应用只使用很短的时间，但是企业也希望数据永远保存下来。

还有一个有意思的变化是容器的普及，降低了应用的重要性。当一个应用很容易做到弹性伸缩的时候，企业开发应用的速度越来越快，开发的应用就会越来越多。由于容器的技术，在应用端的运维变得简单，但是日益增长的应用会给数据库带来更大的压力，而由于服务器上I/O的弹性不如计算能力，所以数据库的弹性和运维压力会增加。在这种场景下，一个能支持分布式数据库的低代码或者无代码平台对于企业的敏捷创新就变得极为重要了。

另外一个大的变化是企业的应用逐步走出内部管理的范畴，打破边界，开始触达客户，触达生态，企业应用也在开始学习互联网应用，数据量越来越大。一些零售行业甚至转型为互联网平台，在这种场景下，高并发和大数据量，使得数据库在企业架构中变得更为重要。

那么重点的总结来了：当数据库的架构变复杂了，数据库更重要了；当应用变得多了，数据库更重要了；当应用不那么严肃了，数据库相对更重要了；当应用的运维压力小了，数据库相对更重要了；当数据变海量了，数据库变得更重要了；当数据库变成分布式了，牵一发而动全身，数据库太重要了。

在你的公司或者团队里，数据库团队的地位上升了还是下降了？