关系数据库的末日是否已经来临.docVIP

　　关系数据库的末日是否已经来临教育资源库 　　最近，大量新的非关系式数据库如雨后春笋般出现在云里云外。这其中所释放出的一个关键信息是：如果想获得丰富而随需应变的可伸缩性，你需要一个非关系数据库。 　　如果这是真的，那么这是不是一个迹象，表明曾经强大的关系式数据库终于在它的盔甲上出现了裂缝？关系数据库的日子是不是到头了？该隐退了？在本文中，我们将检视当前这种在特定情况下摆脱关系数据库的趋势，并分析这对于关系数据库的未来意味着什么。 　　关系数据库已过而立之年。在此期间，短暂爆发过一些所谓终结关系数据库的革命。当然，最终都失败了，丝毫没有动摇到关系数据库的主导地位。 　　先了解一些背景 　　一个关系数据库基本上就是一个表（实体）集合。表由列和行（变量集）构成。这些表存在约束，相互之间定义了关系。关系数据库使用SQL进行查询，结果集通过访问一个或多个表的查询生成。单个查询里被访问到的多个表，一般是利用在表关系列里定义的范式被连接到一起的。 规范化 是关系数据库使用到的一种数据结构模型，能保证数据一致性并消除数据冗余。 　　关系数据库在 关系数据库管理系统 (RDBMS)的帮助下得以促进。我们今天所使用的绝大部分数据库系统都是RDBMS，包括 Oracle，SQL Server， MySQL，Sybase，DB2，TeraData等等。 　　图片看不清楚？请点击这里查看原图（大图）。 　　关系数据库占据统治地位的原因并非微不足道的。它们持续提供了简单性、健壮性、灵活性以及性能的最佳组合，并带来了通用数据管理的兼容性。 　　不过，为了实现这一切，关系数据库的内部不得不复杂得难以置信。举个例子说，一个相对简单的SELECT语句可能有着上百条执行路径，优化程序在运行时必须进行评估。这一切都被隐藏起来，对用户都是不可见的，RDBMS通过使用类似基于代价的算法来决定最佳响应请求的执行计划。 　　关系数据库的问题 　　尽管RDBMS为数据库用户提供了简单性、健壮性、灵活性、性能、可伸缩性以及兼容性的最佳组合，但它在其中每个领域里的性能，不一定就优于其他追求某一项好处的独立替代方案。迄今为止这不是太大的问题，因为RDBMS的普遍优势已经压制了开疆拓土的需求。不过，如果你的确存在着通用关系数据库无法满足的要求，替代的方案则总可以填补这些壁龛。 　　今天，形势略有不同。对于数量不断增长的应用程序而言，上述的其中一项好处变得越来越重要；虽仍被视为特殊，但正迅速成为主流，以至于对于不断增长的数据库用户来说，其在重要性方面已经开始侵蚀掉其它的好处了。这项好处就是可伸缩性。随着越来越多如S在大型分布式系统平台市场里的生存能力被大幅削减。 　　为了让云服务变得可行，供应商不得不突破这种限制，因为一个缺乏伸缩性的数据仓储的云平台根据就不能算一个平台。因此，为了能向客户提供的一个伸缩自如的空间去存放应用数据，供应商实际上只有一种真正的选择。他们不得不实现一种新型的关注于可扩性的数据库系统，而牺牲掉关系数据库所带来的其他好处。 　　这些努力，再加上那些已有的特殊供应商，已经带来了一种新型的数据库管理系统。 　　新品种 　　这种新型的数据库管理系统通常被称为键/值存储。实际上，尚无正式的名字，因此你可能会看到它被称为面向文档的、面向互联网的、面向属性的、 分布式数据库 (尽管这也可以是关系式的)、共享排序数组、 分布式哈希表以及键/值数据库。虽然每个名字都指出了这种新方案的某种特征，但都是基于一个主题的派生，这个主题就是我们将要命名的键/值数据库。 　　不关你怎么称呼它，这个新型的数据库其实已经在某些普通关系数据库不合适的特殊应用里使用了很长时间了。不过如果没有Web和云应用所带来的伸缩性的话，它很可能还得继续呆在深闺大院里。现在的挑战是我们得弄清楚，究竟是它还是关系数据库更适合于特定应用。 　　关系数据库和键/值数据库从根本上来说是完全不同的，分别被设计用于满足不同的需求。迄今为止，一项一对一的比较能有助于你理解这种差异性，不过在开始之前，先让我们来看看下面： 　　图片看不清楚？请点击这里查看原图（大图）。 　　没有实体连接 　　键/值数据库是面向项目的，这意味着所有与项目有关的数据都被存储进该项目中。一个域（你可以把它视为表）可以包含大量不同的项目。比如说，一个域里可以同时包含客户项目和定单项目。这意味着在一个域内，不同项目间的数据通常是重复的。这在实践上是可行的，因为磁盘空间相对廉价。但这个模型允许一个单一的项目包含完所有相关数据，就可以通过消除对多表的数据连接的需求来改善可扩性。而在关系数据库中，那样的数据需要被连接到一起，以便能重组为相关属性。 　　不过