在本博客系列的第二部分，我会讨论这其中的一些问题，以及在克服这些问题时你需要考虑的取舍。本博客系列的第三部分在这些信息的基础上，论述AWS特定的数据存储选项，以及每个存储选项的优化所针对的是哪些工作负载。在你读完本博客系列的全部三部分之后，你就会赞同AWS提供了丰富的数据存储产品，并学会针对正确的工作负载选择正确的选择。关系型数据库到底有什么问题?正如你们中的很多人可能已经知道的，关系型数据库(RDB)技术自从1970年代就已经存在，直到1990年代末一直是结构化存储的事实标准。RDB几十年来很出色地支持了高度一致性事务的工作负载，并依然保持强劲。随着时间的推移，该项古老的技术为应对客户的需求获得了新的能力，比如BLOB存储、XML/文档存储、全文检索、在数据库中执行代码、使用星形数据结构的数据仓库、以及地理空间扩展。只要一切都能挤进关系型数据结构的定义中，并且适合于单机，就可以在关系型数据库中实现。

　　InfoQ AWS专区，汇聚AWS精华内容与最新信息，精彩呈现!然后，互联网的商业化发生了，并且彻底改变了一切，使得关系型数据库不再能够满足所有的存储需求。相比于一致性，可用性、性能和扩展正在变得同样重要--有时甚至更重要。性能一直很重要，但是随着互联网商业化的出现，改变的是规模。事实证明，要达到规模化的性能，要求的技巧和技术是前互联网时代无法接受的。关系型数据库围绕着ACID(原子性Atomicity、一致性Consistency、隔离性Isolation和持久性Durability)的概念而建立，实现ACID最简单的方法就是把一切保持在单机上。因此，传统的RDB规模化的方法是垂直扩展(scale up)，用白话说，就是使用更大的机器。

　　哦-哦，我想我需要一台更大的机器使用一台更大的机器的解决方案一直很好，直到互联网带来的负载大到单机无法处理。这迫使工程师们想出巧妙的技术来克服单机的限制。有许多不同的方法，各有其优缺点：主—副、集群、表联合与分区(table federation and partitioning)、水平分区(sharding，可以认为是分区的特例)。

　　导致数据存储选项增加的另外一个因素是可用性。前互联网时代的系统，其用户通常是来自组织的内部，这就有可能在非工作时段设置有计划的停机时间，甚至计划外的宕机也只会造成有限的影响。商业化互联网也改变了这一点：现在每个能够访问互联网的人都是潜在用户，所以计划外的宕机会造成很可能更大的影响，而且互联网的全球性导致很难确定非工作时段，并安排有计划的停机。在本博客系列的第一部分，我探讨了冗余在实现高可用性中所起的作用。不过，当应用到数据存储层时，冗余带来了一系列新的有趣的挑战。在数据库层应用冗余最常用的方式是主/副配置。

　　这个看似简单的设置，在与传统的单机关系型数据库比较时，有一个巨大的差异：我们现在有网络隔离的多台机器。当数据库的写操作发生时，我们现在要决定何时认为它完成了：只要保存到主数据库，或者只要保存到副数据库(或者甚至是n个副数据库，如果我们想要获得更高的可用性--欲知增加另一台机器对整个可用性的影响，请参看本博客系列的第一部分)。如果我们决定保存到主数据库就足够了，在复制数据之前如果主数据库失效，我们要承担丢失数据的风险。如果我们决定等到数据复制完成，我们就要接受延迟的代价。在副数据库宕机的罕见情况下，我们需要决定是继续接受写操作的请求，还是拒绝它。因此，我们从一个默认一致性的世界，进入了一个一致性是一种选择的世界。在这个世界里，我们可以选择接受所谓的最终一致性，即，状态在多个节点之间复制，但是并非每个节点都有整个状态的完整视图。在我们上面的示例配置中，如果我们选择认为达到主数据库就是写操作完成(或者到达主数据库和任一副数据库，但不一定是两个副数据库)，那么我们就是选择了最终一致性。最终，因为每个写操作会被复制到每个副数据库。但是在任一时间点，如果我们查询某一个副数据库，我们无法保证它包含截止到那个时刻为止的所有写操作。让我们试试新的CAP理论总而言之，当数据存储被复制(也称为分隔(partitioned))时，系统的状态被分散。这意味着我们离开了舒适的ACID领域，进入CAP的美丽新世界。CAP理论是由加州伯克利分校的Eric Brewer博士在2000年提出的。它最简单的形式是这样的：一个分布式系统必须在一致性、可用性和分隔容忍度(Partition Tolerance)之间取舍，并且只能做到三者中的两者。