商用数据库之死：Oracle 面临困境

在处理器/内存/带宽资源相对匮乏的 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 和客户端/服务器应用软件集成起来的多种方法何其相似。

【编辑推荐】

1. MySQL常见的图形化工具
2. 亚马逊彻底去掉 Oracle 数据库：迁移完成
3. 解码技术社区：Github区块链代码库超5万 这个最受关注
4. “12306”是如何支撑百万QPS的_技术栈微信半月刊第51期
5. 边缘计算技术发展现状与对策

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!