简介

雅虎公司运营着世界上最受欢迎的多个网站，每月的访问用户有5亿之多。这些Web站点的后台数据系统存储了种类庞杂的数据，如用户信息、照片、餐馆点评、博客博文以及大量其他数据。雅虎开发部署了多套成熟、稳定的数据库体系来支持它的站点，同时这些架构也为用户提供低延迟的数据访问方式来快速加载页面。

但是，这些系统存在着一些严重的局限性。首先，系统扩容困难。为了进行系统扩容，通常需要数月的时间来规划和重组数据，并且在扩容过程中，相关应用的服务质量会受到影响。此外，有些系统可支持的扩展性具有上限值，即使增加硬件支持也无济于事。其次，很多早期设计的系统，其设计思想就是基于单一的数据中心。雅虎已经发展为全球性的品牌，其广泛的基础用户遍及全世界。为了提供良好的用户体验，系统需要复制数据到离用户近的数据中心，这样当用户访问时，页面就可以快速加载。由于数据库系统本身并没有将全球性数据复制作为内建的功能提供，每个应用需要自己构建数据复制，这导致复杂的应用逻辑和薄弱的数据基础。部署一个大规模的、在不同地理空间上都存在数据副本的数据库架构需要很大投入，因此，在这样的架构上，很难快速地开发新的应用或在已有的应用上增加新的特性。

PNUTS系统致力于支持雅虎的Web站点和应用平台，并解决上述局限(Coper等2008）。在设计上，它通过云存储方式，可以有效地处理租户应用(tnant applications)中复杂的读写工作，并且支持本地全球数据复制。和很多其他的分布式系统类似，PNUTS通过水平数据分区的方式，将数据分布到一组存储服务器阵列上，从而实现高性能和可扩展性。该系统的核心不是复杂的分析和决策支持工作，而是从最初设计就把两个属性作为首要特征：

向外扩展(sale-out)

系统通过分区将数据分布式存储到多台服务器上，扩充系统容量犹如增加新的服务器一样容易，且系统可以平滑地将负载分配到新的服务器上。

地理空间上的数据复制(go-replication)

在PNUTS系统中，数据可以自动地复制到全世界。一旦开发者告诉系统在哪个区域^[1](clos，即数据中心）复制数据，系统本身就会自动地完成诸多细节操作，包括故障处理（如机器、链接甚至整个区域）的一些细节操作。

PNUTS系统还设置了一些其他的目标，尤其是，我们希望应用开发者能够专注于应用逻辑本身，而不是操作数据库的具体细节。因此该系统对数据库采取托管方式，并为开发者提供一个简洁易用的API来存储和访问这些数据，而不需要他们自己对一大堆参数进行调优。由于系统采取托管方式，在功能实现上，它能够尽可能达到自我维护。

尽管这些目标都很重要，而且构建一个能够向外扩展且易于全球性数据复制的数据库系统是对公司最有吸引力和直接价值的。随着开始系统设计，我们清楚地发现很多长期普及和使用的数据库系统机制需要重新考虑(Rmakrishnan和Gehrke 2002）。

实现向外扩展和地理空间上数据复制的核心思想是只进行简单廉价的同步操作，而在后台异步式地实现所有代价高的操作。举个例子，当一个加州的用户想用一个关键字来标注一张照片，她必定不愿意等待该系统把该标签提交到在新加坡的标签数据库副本（从加州到新加坡的网络延迟可能高达1秒）。然而，她还是希望她的新加坡朋友能够看见该标签，因此需要在后台对新加坡的数据库副本完成快速（几秒内）、可靠的异步更新。

另一个如何发挥异步作用的例子是诸如聚集查询和连接操作，它们通常需要在多台服务器上执行数据操作。随着系统规模扩大、负荷加重，这些服务器出现响应变慢或者崩溃的概率也随之增加，因此会增加请求延迟。为了解决该问题，我们可以维护实体化视图(mterialized views)来重组这些基础数据，这样一些预先设定的复杂查询可以通过只访问一台服务器来获得响应。和数据库副本相似，若同步更新每个视图，在执行写操作时非常缓慢，因此我们的策略是采取异步方式更新这些视图。

本章的剩余部分会深入地剖析重点研究向外扩展和地理空间上的数据复制这两大首要特征的涵义。我们将通过一个例子来阐明主要问题、说明基本方法、讨论一些问题及扩展；然后，将PNUTS和其他方法作比较。本章的讨论重点是设计理念，而不是系统架构或实现细节，并且为了在全局方案中突出某些选择，本章涵盖了一些当前系统版本不包含的特性。

[1]区域设施，或者称数据中心。雅虎在全世界运营着大量的数据中心。