云计算中无法使用关系型数据库

　　最近云计算键/值数据库的使用受到很大关注，而云计算存储方式的一大优点便是其伸缩性。由此，业界已经开始就关系数据库的末日是否已经来临开始探讨。

　　最近对云计算的关注增加了键/值数据库的使用，有关这种存储方式最常见的主题便是其伸缩性。对各厂商来说，即使无需构建高度伸缩的应用程序或服务，云计算的其他一些优势也对它们有着强大的吸引力——尽管良好的伸缩性是云计算的关键要素之一。

　　目前可以猜测的使用场景有：

　　◆创业公司无需在本地服务器上进行投资，只要购买它们的计算和存储即可。

　　◆公司想要将现有的应用程序或服务器移植到云上时，它们无需重新架构他们的数据层。

　　◆需要在较短的时间段内获得大量计算能力。

　　Tony Bain最近发布了一篇文章，探讨关系数据库的末日是否已经来临。他将目光对准关系型数据库和键/值数据库的区别，以及从两者选择其一的原因上。根据Tony的说法，关系型数据库在伸缩性上会遇到一些挑战：

　　当越来越多的应用程序发布于高负荷(例如Web Services)环境中时，它们对伸缩性的需求将会十分明显。首先，它们会迅速增长。其次，它们最终的规模也会非常可观。对于前者来说，我们难以管理单个内部服务器上部署的关系型数据库，例如你的负载一夜之间增加两倍，你升级硬件的速度又能有多快？而后者一直便是关系型数据库在管理上的难点。

　　他列举了四种选择键/值数据库，而不是关系型数据库原因：

　　◆你的数据是高度面向文件的。

　　◆你的开发环境是高度面向对象的。

　　◆你的数据存储很便宜，并且很容易和合作伙伴的Web Service平台集成。

　　◆你的最先关注的是按需增长，规模庞大的伸缩能力。

　　David Chappell在他关于Azure服务器平台的文件中简单讨论了这个问题。David提出了在云中使用键/值数据库的多种原因，不过他也谈到：

　　……微软宣布了一个计划：将SQL Data Service更进一步关系化。与Windows Azure存储不同，SQL Data Service构建于SQL Server之上，使得这种发展更加自然。无论这种模型是什么样的，这个技术的目标是不变的：提供一种伸缩性更强，更可靠，成本更低的云数据库，并适合各种类型的应用程序。

　　依赖于不同的关系型特性，有以上需求的公司可以更容易地采纳这种技术，并以此降低成本。

　　类似由Brian Aker发起的Drizzle数据库，它的目标是可伸缩的关系型能力。Drizzle基于MySQL 6.0的原代码，并针对云和网络应用程序进行了优化。现在他们已经从原来的代码中去除了许多功能，并增加了许多新特性：

　　◆微内核架构，使Drizzle比MySQL更为模块化

　　◆更多接口，如认证和日志记录

　　◆多核优化(与MySQL相比)

　　◆更少的数据类型

　　◆更少的引擎

　　◆更少的代码，相对更小并且更易于维护的代码库

　　Drizzle仍处于Alpha阶段，它为类Unix操作系统开发，目前不支持Windows。