最近对云计算的关注增加了键 / 值数据库的使用,有关这种存储方式最常见的主题便是其伸缩性。对各厂商来说,即使无需构建高度伸缩的应用程序或服务,云计算的其他一些优势也对它们有着强大的吸引力——尽管良好的伸缩性是云计算的关键要素之一。
目前可以猜测的使用场景有:
- 创业公司无需在本地服务器上进行投资,只要购买它们的计算和存储即可。
- 公司想要将现有的应用程序或服务器移植到云上时,它们无需重新架构他们的数据层。
- 需要在较短的时间段内获得大量计算能力。
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。
查看英文原文: Is the Relational Database Not an Option in Cloud Computing?
评论