作者：John Freeman、Fred McClimans和 Zach Mitchell
![]()
我们预计到2021年，年产值296亿美元的商业数据库市场会收缩20%至30%，认为Oracle无法让收入来源足够快地实现转型（从传统的商业数据库转向基于云的订购产品），以抵消这个市场下滑的颓势，这个市场是Oracle收入的一大传统核心。
![]()
这二十年来，商业数据库市场仍然是IT行业最稳定、最具黏性的领域之一，Oracle、IBM和微软三家厂商瓜分了80%的份额。然而，我们认为这个领域衰退的速度和幅度可能会让许多投资者大吃一惊。
![]()
已经影响数据库市场的通货紧缩压力刚刚开始体现，包括：
迁移到软件即服务（SaaS），大多数产品使用免费开源数据库；
社交媒体、物联网和非结构化/半结构化数据等使用场合迎来更快速的增长，这些使用场合不适合SQL标准，而数据库寡头们恰恰有赖于这项标准；
众多的免费开放源代码选项日益稳定、功能日益强大，其中大多数选项是“Not Only SQL”（NoSQL），因此极其适合上述使用场合；以及
由于摩尔定律带来了处理器、内存、固态存储和网络吞吐量等方面的改进，NoSQL数据库继续获得异常显著的好处――这些改进提升了同时快速处理NoSQL使用场合和SQL使用场合的能力，并逐渐使纯SQL数据库沦为边缘化，正如纯SQL数据库在80年代末和90年代使基于大型机的数据库沦为边缘化。）
来自数据库软件的收入占Oracle 2016财年总收入的约36%，占其营业利润的约55%。
![]()
注意：数据库软件和内部部署型应用软件包括许可证收入和维护收入。
该公司预计的数据库收入下降是明摆着的，此外其内部部署型应用软件的收入也在下降，这块收入占2016财年总收入的约25%，占营业利润的约39%。
![]()
微软和IBM将只是略微受到伤害，因为数据库软件只占每家厂商总收入的区区5%左右。
如果不采取积极的行动来大幅提高非数据库收入，我们认为Oracle无法足够快地抵消商业数据库收入即将下降的颓势，以保持其目前的市值。
具体来说，我们认为Oracle需要实行更激进、更快速的组织转型和文化转型，变成一家“云优先”的企业，激励销售队伍和客户向云积极迈进。该公司还需要整合各种自家开发和收购而来的云/ SaaS产品，整合到单个平台，以便将来获得经营杠杆效应。未来几年，这些项目会在几个方面带来痛苦，尤其是财务方面。为了部分抵消痛苦，Oracle应该剥离剩余的硬件及其他非核心业务。
对于那些对技术深究更有兴趣的人来说，下面从历史的角度更深入地解释了五个相互关联的趋势，这些趋势愈演愈烈，将共同导致商业数据库市场到2021年收缩20%至30%。除了几款建立在Oracle数据库基础上的初期SaaS产品（即Salesforce.com、NetSuite和Oracle本身）外，很难找到使用任何商业数据库的SaaS提供商。对于2005年以后创办的公司而言，这个数字几乎为零。如今绝大多数的SaaS提供商使用开源数据库，或者像SaaS人力资本管理（HCM）提供商Workday那样，开发自己的数据库。许多用户之前使用内部部署型企业应用软件，包括五个核心客户端/服务器应用软件类别中的一个：ERP（企业资源规划）、CRM（客户关系管理）、HCM（人力资本管理）、SCM（供应链管理）和BI（商业智能）应用软件，改用SaaS模式后，消除了商业数据库席位（seat），因而消除了原本带来的维护/支持收入和未来升级收入。连改用Salesforce.com的企业席位给Oracle创造的收入也将比当初部署在企业内部环境时少得多。因此，我们认为企业迁移到SaaS/云对商业数据库收入而言是非常不利的趋势。此外，我们仍处在从客户端/服务器到SaaS/云的早期阶段。据不同的研究公司声称，这种迁移只完成了10%至25%，只是刚刚开始影响更重要的关键任务应用软件（比如ERP），它们更有可能在更高端的SQL数据库（包括Oracle和IBM的那些数据库以及微软的一小部分数据库）上运行。商业SQL数据库不是很适合处理最有吸引力的新兴使用场景
SQL在1987年成为标准后，20年来它在定义如何组织、搜索和排序数据方面的地位无可撼动。然而，到2000年年中，各大科技公司在处理数据的绝对数量和不同结构方面开始遇到了SQL数据库存在的限制，它们想按照需要来保留、浏览、分析数据，并将数据提供给用户/客户。亚马逊、谷歌、LinkedIn和Facebook各自通过开发和实施自己的数据库软件――这种数据库软件打破了SQL标准的制约，解决了自己的扩展问题。此外，不久后每家公司都发布了开源版本的数据库。因此，2008年和2009年它们开发出了众多新的开源数据库，导致了《下一代数据库》的作者盖伊·哈里逊（Guy Harrison）所说的“某种寒武纪大爆炸”现象。由于纷纷远离SQL，这些数据库都属于“NoSQL”这类数据库――尽管大多数数据库彼此大不相同，就像它们跟SQL大不相同那样。鉴于数据的数量和种类迅猛增长――这归因于更丰富的社交媒体内容、更多的社交媒体用户以及自动获取的物联网数据激剧增多，另外鉴于企业日益渴望分析获取的数据，我们认为，适合NoSQL的使用场合其数量很快就会远远超过适合SQL的使用场合。这些新型使用场合的兴起将推动大企业更多地采用开源NoSQL解决方案，结果商业SQL数据库成了牺牲品。NoSQL数据库和读时模式（Schema-on-Read）方法遵循摩尔定律
SQL数据库和写时模式（Schema-on-Write）未遵循摩尔定律。
通常来说，NoSQL数据库所需的处理器、内存和存储资源比SQL数据库密集得多，即使考虑到这一事实：它们放松了SQL在数据组织方式方面的许多约束。虽然NoSQL数据库架构早在2005年就已经存在――至少从理论上来说是这样，但当时根本没有足够的处理能力、内存容量和存储空间，好让它们在学术界之外的领域投入实际应用。在处理器/内存/带宽资源相对匮乏的20世纪80年代和90年代，遵守更加严格的SQL标准实际上是必须的，那样才能确保企业将应用软件从大型机和小型计算机迁移到更加分布式、依赖网络的客户端/服务器架构所需要的那种性能和可靠性，尤其是那些更重要的关键任务应用软件。获得SQL尚可接受的性能和可靠性需要付出代价，这主要是由于：名为模式的数据结构整体上缺乏灵活性；
在部署数据库及相关应用程序之前定义该结构带来的繁重要求；
随着时间的推移，很难改变该结构，以便获取不同类型的数据，以便更好地体现数据结构和企业组织方面的变化；以及
需要写时模式方法，即在输入数据时让数据适合模式，而不是读时模式，只是将数据倒到一只大大的“容器”中，之后将它组织到模式中。
然而，随着时间的推移，摩尔定律促使处理能力、内存容量及速度、存储容量及速度以及网络吞吐量都得到了提升，这使得用户越来越不需要僵硬的SQL标准和写时模式方法，这股势头只会延续下去。因此，伴随着每个摩尔定律周期，SQL及其节省资源的写时模式方法越来越失去竞争优势，而NoSQL及其资源相对低效，但极其灵活的读时模式方法变得日益摆脱当初阻碍它得到采用的约束。内存技术（In-Memory）带来了大好前景，消除了传统硬盘的缺点
SQL成为标准化时，传统硬盘（HDD）是可以实时访问的唯一具有成本效益的存储介质。因此，写入到SQL数据库软件的许多基本代码旨在忍受HDD的缺点，比如读取请求的数据并将数据传输到内存中速度很慢，故障率比较高――至少，与系统的主要固态部件（比如CPU、内存和网络吞吐量）相比是这样。现在由于固态硬盘（SSD）正迅速成为一种具有成本效益的HDD替代品，传统SQL数据库软件的设计、当然还有大部分代码现在毫无必要了――而当初做出这样的妥协，是为了适应速度慢得多的HDD。相比之下，开发的许多NoSQL数据库是为了最大限度地利用SSD存储介质，这些数据库可能会得到更新，以便充分利用更新颖的非易失性内存技术，比如英特尔/美光联合开发的3D xPoint，这种内存正在推向市场。我们认为，鉴于继续遵守SQL标准、保持自己的向后兼容性方面有着强烈的需求，SQL数据库厂商无法像许多开源项目那样迅速针对SSD优化其代码，这让它们进一步处于竞争劣势――这是克莱顿·克里斯滕森（Clayton Christensen）所说的“创新者的困境”的一个典型例子。市面上 “SQLMethadone” 解决方案越来越多，让企业可以摆脱昂贵的商业数据库
我们看到越来越多的软件工具和服务旨在帮助企业从商业SQL数据库迁移出去。随着时间的推移，连在Oracle或IBM数据库上运行的最重要的关键任务应用软件也可能日益被包围、“被隔离”、被拆卸，这一幕正如上世纪90年代向客户端/服务器架构转型期间许多传统大型机应用软件的遭遇那样。虽然来自Oracle、IBM和微软等巨头的SQL数据库会在一些企业存活好多年――再度酷似大型机，但是它们会日益沦为边缘化，并且它们的成本会尽可能被减少。我们看到许多这样的工具已经在Hadoop生态系统里面日趋成熟，该生态系统已经有多种方法可以与SQL数据库集成起来，及/或将SQL接口和查询功能放在NoSQL数据库上。在我们看来，这一幕与上世纪90年代初出现将大型机应用软件与PC和客户端/服务器应用软件集成起来的多种方法何其相似。