最近，大量新的非关系式数据库如雨后春笋般出现在云里云外。这其中所释放出的一个关键信息是：“如果想获得丰富而随需应变的可伸缩性，你需要一个非关系数据库。”
如果这是真的，那么这是不是一个迹象，表明曾经强大的关系式数据库终于在它的盔甲上出现了裂缝？关系数据库的日子是不是到头了？该隐退了？在本文中，我们将检视当前这种在特定情况下摆脱关系数据库的趋势，并分析这对于关系数据库的未来意味着什么。
关系数据库已过而立之年。在此期间，短暂爆发过一些所谓终结关系数据库的革命。当然，最终都失败了，丝毫没有动摇到关系数据库的主导地位。
先了解一些背景
一个关系数据库基本上就是一个表（实体）集合。表由列和行（变量集）构成。这些表存在约束，相互之间定义了关系。关系数据库使用SQL进行查询，结果集通过访问一个或多个表的查询生成。单个查询里被访问到的多个表，一般是利用在表关系列里定义的范式被“连接”到一起的。 规范化 是关系数据库使用到的一种数据结构模型，能保证数据一致性并消除数据冗余。
关系数据库在 关系数据库管理系统 (RDBMS)的帮助下得以促进。我们今天所使用的绝大部分数据库系统都是RDBMS，包括 Oracle，SQL Server， MySQL，Sybase，DB2，TeraData等等。
关系数据库占据统治地位的原因并非微不足道的。它们持续提供了简单性、健壮性、灵活性以及性能的最佳组合，并带来了通用数据管理的兼容性。
不过，为了实现这一切，关系数据库的内部不得不复杂得难以置信。举个例子说，一个相对简单的SELECT语句可能有着上百条执行路径，优化程序在运行时必须进行评估。这一切都被隐藏起来，对用户都是不可见的，RDBMS通过使用类似基于代价的算法来决定最佳响应请求的“执行计划”。
关系数据库的问题
尽管RDBMS为数据库用户提供了简单性、健壮性、灵活性、性能、可伸缩性以及兼容性的最佳组合，但它在其中每个领域里的性能，不一定就优于其他追求某一项好处的独立替代方案。迄今为止这不是太大的问题，因为RDBMS的普遍优势已经压制了开疆拓土的需求。不过，如果你的确存在着通用关系数据库无法满足的要求，替代的方案则总可以填补这些壁龛。
今天，形势略有不同。对于数量不断增长的应用程序而言，上述的其中一项好处变得越来越重要；虽仍被视为特殊，但正迅速成为主流，以至于对于不断增长的数据库用户来说，其在重要性方面已经开始侵蚀掉其它的好处了。这项好处就是可伸缩性。随着越来越多如Web服务之类承受大规模工作负荷的应用的发行，其对可伸缩性的需求，首先有可能会改变得非常迅速，其次会变得无比庞大。第一种场景下，如果你只有一个龟缩在一所房子内的服务器中的关系数据库，情况将难以管理。举个例子，如果你的负载一夜之间增加了2倍，你能用多快的速度去升级硬件？第二种情况下，一般的关系数据库是也很难管理的。
关系数据库的确能伸缩自如，但通常只能单台服务器节点上进行。一旦单节点的能力抵达上限，你就得通过多服务器节点来往外扩展来分发负载。这时候关系数据库的复杂性就开始影响其潜在的扩展规模了。试图扩展到成百上千个节点，而不是几个，将导致不堪复杂性之重负，这一特点使得RDBMS在大型分布式系统平台市场里的生存能力被大幅削减。
为了让云服务变得可行，供应商不得不突破这种限制，因为一个缺乏伸缩性的数据仓储的云平台根据就不能算一个平台。因此，为了能向客户提供的一个伸缩自如的空间去存放应用数据，供应商实际上只有一种真正的选择。他们不得不实现一种新型的关注于可扩性的数据库系统，而牺牲掉关系数据库所带来的其他好处。
