云计算浪潮下，商业数据库的护城河还能撑多久？

经过这些年的发展，云计算到今天已经不仅仅是一个概念的问题。各大公有云厂商每年的业务增长是异常的迅猛，企业上云，尤其是新的创业型企业，从诞生的第一天起就完全生活在云上，已经司空见惯。

数据库作为企业计算机应用不可或缺的基石之一，也是云厂商们提供的核心组件之一。云厂商通常提供基于开源数据库，比如PostgreSQL或者MySQL开发的增强版云数据库服务。

使用开源数据库的优点很多，除了耳熟能详的价廉物美，不用自己买硬件等，还有着数据不被强绑定的优势。比如说，某客户选择了A云厂商基于PostgreSQL开发的云数据库服务，它不用担心某天迁移到B云厂商的时候，数据无法顺利迁移，因为通常来说B云厂商也提供了基于PostgreSQL开发的云数据库服务。

基于这些肉眼可见的优势，新的创业企业往往从其业务诞生的第一天起，就全面基于云服务构建自己的整个IT能力。但是，对于那些IT系统已经有几十年积累的传统企业来说，企业上云却不是那么简单的事情。其数据库的迁移之难，超出了很多人的想象。

以全世界最知名的云厂商亚马逊云科技为例。有一段时间，Oracle的总裁Larry Elison经常性的嘲笑亚马逊云科技，说：“它们公司在自己 的云上卖数据库服务，但是它们自己却是我们Oracle数据库最大的客户之一。” 被嘲笑久了，亚马逊云科技最终下定决心在内部去Oracle的数据库，改用亚马逊云科技自己的云数据库服务。

2019年的底，亚马逊云科技终于官方宣布它们完成了这项工作。根据亚马逊云科技自己的说法，这项去除Oracle数据库，改用自身云服务的工作，前后延续了好几年。亚马逊云科技的100多个团队参与了迁移工作。亚马逊云科技最终迁移了7500个Oracle数据库内总共75PB的数据。

这项迁移的好处是显而易见的，根据亚马逊云科技官方说法，简单来说，一方面降低了成本，另外一方面改善了性能。但是我们也应该看到，这个代价是巨大的。这也是为什么很多传统企业一聊起数据库上云，就下定不了决心做这件事情。

要了解为什么需要付出如此巨大的代价，我们还是要把时间线往前面推一推。自从关系数据库诞生以来，上世纪80年代到90年代是数据库蓬勃发展的时期，但是那个时候蓬勃发展的主要是商业数据库。那段时间一度涌现出了包括Oracle，DB2，Sybase，Informix，SQL Server等一系列商业数据库。

这些商业数据库经过厮杀合并，最终剩下了Oracle，DB2和SQL Server三大数据库，其中前两家主要服务大型客户，而SQLServer有大量中小型客户。

相对应的，现在看起来非常成熟的开源数据库比如PostgreSQL和MySQL，在商业数据库迅猛发展的198X-199x年还远谈不上有多成熟。

而我们熟知的SQL作为数据库的标准查询语言，第一个比较有影响力的标准是1998年制定的。开源数据库由于起步比较晚，基本上都遵循了SQL的几个常见标准。

但是商业数据库不一样，由于标准SQL过于简单，发展滞后，各个商业数据库都发展出了一套属于自己的SQL方言，比如Oracle的PL/SQL，SQL Server的T-SQL等等。

这就给使用商业数据库的软件带来了一个很奇怪的现象：应用和数据库的绑定。使用了PL/SQL写出来的应用和Oracle绑定。使用了T-SQL写出来的应用和SQL Server绑定。

在开源数据库不怎么发达的上世纪90年代，这是没办法的。商业数据库贵，但是功能和性能都好，即使使用了某个商业数据库就意味着要和其强绑定，也好过没东西用。

这是为什么即使亚马逊云科技想要把自己的数据库从Oracle迁移到自家云服务，也需要付出很大的代价。迁移的不仅仅是数据，还意味着业务代码里面有大量的基于PL/SQL的查询，都要重写成基于亚马逊云科技的数据库云服务的SQL。

所以现在很多的企业都面临这样的问题：不迁移吧，没办法享受到云服务的各种好处，没办法提高效率，也没办法省钱。迁移吧，业务软件和服务有大量的重写，一次性成本和承受的风险都非常的巨大。下定决心迁移上云，对这些企业的CIO们，都是巨大的挑战。

而商业数据库产品通过这种强绑定，捆绑了大量的用户。这些用户给商业数据库厂商们继续贡献大量的利润。这些用户要么不能上云，即便上云以后，也只能继续使用云上的商业数据库托管，并不能真正享受到数据库上云的所有好处。

但事情不会一直这样对商业数据库厂商美好下去。最近有一个非常的有意思开源项目Babelfish for PostgreSQL（https://babelfishpg.org/）。Babelfish这个名字来自科幻小说《银河系漫游指南》，指的是一种翻译脑电波的生物。

Babelfish for PostgreSQL是一个基于PostgreSQL插件模式开发的开源项目。按照官网说法，这个项目给PostgreSQL提供了理解为微软SQL Server开发的应用的查询的能力。

具体来说，Babelfish能够理解SQL Server wire-protocal TDS,和SQL Server的查询语言T-SQL。其实现方式是通过PostgreSQL的插件模式，由三个插件组成，结果是给PostgreSQL提供了另外一个接入点，这个接入点懂TDS和T-SQL。这样，SQL Sever的客户端就可以直接连过来并使用PostgreSQL。

这个项目的做法是颠覆性的。它意味着从此以后，所有基于SQL Server写的应用都可以直接后台替换成开源数据库PostgreSQL，当然也可以同时直接替换成亚马逊云科技的数据库云服务Aurora for PostgreSQL。

写到这里，你可能想到了什么。你想的没错，这个项目是亚马逊云科技主导开源的。但是你不用担心，项目本身完全兼容任何版本的PostgreSQL。而且亚马逊云科技在开源网站明确说明了，它们不会去修改代码使得Babelfish让特定的云厂商跑的更好，这个特定的云厂商也包括亚马逊云科技。

Babelfish解决了一个很重要的问题：如何可以让商业数据库的用户在不改变自身应用源代码的情况下，顺利的迁移到开源数据库和基于开源数据库的云服务？

SQL-Server服务的更多是中小型的企业，相对于大型企业来说，中小型企业一方面对性能，性价比，维护成本等更敏感，这方面是云数据库的优势，另外一方面中小型企业也更加无法承受像亚马逊云科技迁移Oracle数据库那样的代价--大量的重写自己的应用以便适配新的数据库，新的SQL语言。

如果说有一款迁移工具可以顺利解决掉后面的问题，那么基于云服务显而易见的优势，这些中小型企业显然很愿意迁移到云上来。我想这对SQL-Server的业务的冲击是巨大的。

这种冲击不仅仅体现在线下SQL Server业务，也体现在SQL Server云服务。毕竟商业软件比开源版的收费依然更高，能够降低成本，是每个企业都感兴趣的。可以想象，在未来SQL Server将很难通过T-SQL这个城墙深挖护城河来赚取高额利润了。

但是，同样可以帮助Oracle迁移的懂PL/SQL的项目尚未出现。而Oracle的护城河相对来说更深一些，因为它能处理的数据规模和性能，都不是SQL Server可以比的。

云厂商目前的解决方案，不仅仅在PL/SQL这个语言关上会被卡壳，还涉及到要对数据进行重新分库分表的问题，而这些，都需要更强大的迁移工具去方便用户，避免用户迁移的时候大规模的改写应用。

但是趋势既然形成了，就不可逆了。商业数据库的护城河终究会被磨平，未来属于云数据库，属于开源数据库。另外有一个好消息是Babelfish for PostgreSQ在中国区域已经上线了。广大中国的SQL Server客户上云的福音来了。

这里也给大家送上数据库与数据分析大礼包（海外区200美元服务抵扣券）识别下面二维码即可领取。