Database 随着云计算越来越流行，关系数据库是否会死亡？

虽然计算机编程鼓吹者预测云计算的未来非常光明，但关系数据库是否有机会退出呢

---

什么样的数据库更适合于云计算？

不，RDBMS由于其功能将始终占有一席之地。不仅关系数据库本身，还可以作为其他系统（如OODBMS）的主干。

关系数据库仍然与本地化存储（如特定于应用程序的存储）和服务器存储相关。

关系数据库模型在关系代数中具有坚实的数学基础。这使得它很容易推理、扩展和正确使用（理论上）。即使数据库访问模式因这些新的API和使用而发生显著变化，也有可能因为这个原因，关系数据库将形成底层实现。

我所看到的云计算平台都提供了关系数据库。因此，我认为云计算并没有真正改变所使用的数据库类型

---

然而，一些东西最终会取代我们都习惯的数据库。问题是这将是RDB的更高版本还是其他版本。这个问题的另一个方面是，当前的RDB作物需要多长时间才能淡出？（我也没有答案。）

这些天，云层仍然在下沉，所以我认为短期内不会如此。

这里有一篇好文章，可以回答你的一些问题。它将RDBMS系统与通常用于云存储基础架构的系统进行了很好的比较：

---

我认为云计算不会杀死RDBMS。不过，可能还有别的原因

首先，给定应用程序使用哪种类型的存储引擎并不（也不应该）取决于它运行的位置（云或特定服务器），而是取决于它需要如何存储数据

第二，据我所知，人们认为RDBMS即将退出市场的唯一原因是，它们的可扩展性不如非关系型DBMS（如CouchDB之类的面向文档的DBMS），后者更容易分布到云中。然而，没有理由说RDBMS在未来不能变得更加云友好。作为早期示例，请看：

Drizzle项目正在构建一个针对云和网络应用程序优化的数据库。它是为现代多cpu/核心体系结构上的大规模并发而设计的

---

所以不，我认为云计算不会杀死RDBMS。他们只能被迫适应。然而，如果现有的替代品或新的替代品变得像RDBMS一样健壮且易于使用，那么可能会杀死它们。我的意思是一个解决方案，它既有完全可靠的软件（不允许使用beta），又便于程序员切换。他们向理解RDBMS的人颁发学位。由于所有的辅助软件（如ActiveRecord、SQLAlchemy等ORM，以及我假设的.NET用户使用的任何软件），使用RDBMS变得很容易，即使对于不知道第一个范式是什么的人来说也是如此。因此，我认为，除非有一种方法可以让人们（例如）同样轻松地使用DODBMS，否则RDBMS将继续占据主导地位。我也不是说那一定不好。同样，您使用哪种DBMS应该取决于您的数据，而不是人们所说的酷和更好。

文章引用：

“关系数据库的固有约束确保最低级别的数据具有完整性。无法将违反完整性约束的数据以物理方式输入数据库。键/值数据库中不存在这些约束，因此确保数据完整性的责任完全落在应用程序身上。但是应用程序代码经常带有bug。正确设计的关系数据库中的错误通常不会导致数据完整性问题；但是，键/值数据库中的错误很容易导致数据完整性问题。”

对我来说，这意味着RDBMS注定要失败，而热门的新技术正面临着一个伟大而辉煌的未来，用户对其数据的正确性几乎不感兴趣

---

IMHO.

对于需要查询更多结构化数据的应用程序来说，关系数据库没有什么问题（例如，“有多少人在这一天购买了XYZ产品，支付了100美元以上，但不到150美元？”）。随着这些系统的扩展和增长，可能需要解决一些重大的体系结构问题。一旦您的数据库超出了您启动的一台计算机，并且/或者流量/请求开始过载可用资源，那么（如果您仍然希望保留关系数据库）你必须开始添加层。谢天谢地，在过去的几年里还有很多可用的选项……包括缓存、映射和还原以及其他功能。但是这些附加层确实增加了复杂性和维护开销。从某种意义上说，我会考虑这些工程化的“带式帮助”。“从长远来看，哪一种方法最有可能解决关系数据库当前的可伸缩性和分布问题？谁知道呢。我今天也看到了这些流行的层——所有这些层基本上都在尝试模拟对象数据库中已有的功能，为开发人员提供了一个“虚拟对象数据库”层，他们可以将其与对象语言一起使用，以更快、更有效地完成任务，并克服增长和性能障碍。所以我想我的总体观点是，关系数据库之所以成为事实上的数据库，可能主要是因为（相对而言）查询数据库并将结果返回给使用它的一个客户机/应用程序是多么容易。然而，随着容量的增长，应用程序的复杂性在今天呈指数级增长，我认为更多的开发人员将决定咬紧牙关，学习对象数据库的语法（今天的对象数据库实际上与关系数据库一样标准化）