Yahoo!的PNUTS是一个分布式的数据存储平台，它是Yahoo!云计算平台重要的一部分。它的上层产品通常也称为Sherpa。按照官方的描述，”PNUTS, a massively parallel and geographically distributed database system for Yahoo!’s web applications.” PNUTS显然就深谙CAP之道，考虑到大部分web应用对一致性并不要求非常严格，在设计上放弃了对强一致性的追求。代替的是追求更高的availability，容错，更快速的响应调用请求等。
1. PNUTS简介及特点
- 地理分布式，分布在全球多个数据中心。由于大部分Web应用都对响应时间要求高，因此最好服务器部署在离用户最近的本地机房。
- 可扩展，记录数可支持从几万条到几亿条。数据容量增加不会影响性能。
- schema-free，即非固定表结构。实际使用key/value存储的，一条记录的多个字段实际是用json方式合并存在value中。因此delete和update必须指定primary key。但也支持批量查询。
- 高可用性及容错。从单个存储节点到整个数据中心不可用都不会影响前端Web访问。
- 适合存相对小型的记录，不适合存储大文件，流媒体等。
- 弱一致性保证。
传统的数据库提供强一致性保证, 通常称为“serialization transaction”，保证调用时序的一致性。但在web应用中不是必须，比如用户A修改了自己的资料或上传了图片，他的好友B短时间不能立即看到并不是大的问题，通常的Web应用都可以接受。PNUTS像大部分分布式key/value系统类似，提供的是弱一致性的支持，也就是支持“最终一致性(eventually consistent)”。用户B最终会看到用户A的修改信息。
未够！但最终一致性并非可以适应所有场合，比如用户A修改了相册的访问权限，设置用户C不能访问，然后用户A又上传了新的图片，如果用户C处于另外一个IDC访问，如果图片数据先同步成功，而权限记录后同步的话，C实际上违反了A设置的权限而看到图片了。因此对于部分场合最终一致性是不够的。
2. PNUTS实现
2.1 Record-level mastering 记录级别主节点
每一条记录都有一个主记录。比如一个印度的用户保存的记录master在印度机房，通常修改都会调用印度。其他地方如美国用户看这个用户的资料调用的是美国数据中心的资料，有可能取到的是旧版的数据。非master机房也可对记录进行修改，但需要master来统一管理。每行数据都有自己的版本控制，如下图所示。
2.2 PNUTS的结构
每个数据中心的PNUTS结构由四部分构成
Storage Units (SU) 存储单元
物理的存储服务器，每个存储服务器上面含有多个tablets，tablets是PNUTS上的基本存储单元。一个tablets是一个yahoo内部格式的hash table的文件(hash table)或是一个MySQL innodb表(ordered table)。一个Tablet通常为几百M。一个SU上通常会存在几百个tablets。
Routers
每个tablets在哪个SU上是通过查询router获得。一个数据中心内router通常可由两台双机备份的单元提供。
Tablet Controller
router的位置只是个内存快照，实际的位置由Tablet Controller单元决定。
Message Broker
与远程数据的同步是由YMB提供，它是一个pub/sub的异步消息订阅系统。
2.3 Tablets寻址与切分
存储分hash和ordered data store。
以hash为例介绍，先对所有的tablets按hash值分片，比如1-10,000属于tablets 1, 10,000到20,000属于tablets 2，依此类推分配完所有的hash范围。一个大型的IDC通常会存在100万以下的tablets, 1,000台左右的SU。tablets属于哪个SU由routers全部加载到内存里面，因此router访问速度极快，通常不会成为瓶颈。按照官方的说法，系统的瓶颈只存在磁盘文件hash file访问上。
当某个SU访问量过大，则可将SU中部分tablets移到相对空闲的SU，并修改tablet controller的偏移记录。router定位tablet失效之后会自动通过tablet controller重新加载到内存。所以切分也相对容易实现。
Tim也曾经用MySQL实现过类似大规模存储的系统，当时的做法是把每条记录的key属于哪个SU的信息保存到一个字典里面，好处是切分可以获得更大的灵活性，可以动态增加新的tablets,而不需要切分旧的tablets。但缺点就是字典没法像router这样，可以高效的全部加载到内存中。所以比较而言，在实际的应用中，按段分片会更简单，且已经足够使用。
2.4 API访问
支持多种级别的数据访问API:
- Read-any 读取的版本有可能是旧的，返回本地IDC的数据，不检查最新版本，性能最好。
- Read-critical(required_version) 读取指定版本，用户修改资料之后调用返回比当前版本更新的版本，以保证当前用户看到的不是修改前的记录。
- Read-latest 强制读取最新，可能需要执行远程IDC调用。比如上面例子介绍的读取权限列表的调用。
- Write 比如更新用户资料
- Test-and-set-write(required version) 只有当记录属于指定的版本才执行write，比如更新用户积分等业务，这个调用有点类似以前介绍的atom操作。
Write调用示意图
3. PNUTS疑问
记录级别master的问题，比如master选取如何达到效率最佳，如何面对2个修改合并冲突?合并冲突据说是需要client自行来处理，
这篇Details on Yahoo’s distributed database提到的平均调用latency 100ms的问题。web应用通常对每次数据的访问最好在10ms之内完成，因为每个web页面实际上不止一个数据访问的调用，经常调用10次以上db的访问的页面并不少见，因此如果平均latency在100ms以上那势必影响页面加载速度。不过yahoo!的开发人员回复paper中的数据实际是一个老版本的测试，目前的版本，在实际生产环境的pnuts的latency会在10ms以下。
另外PNUTS为什么要用消息系统代替replication/undo log？有何优点？
4. PNUTS感悟
Web应用使用通用的存储服务是大势所趋，类似BigTable, Amazon Dynamo/SimpleDB这样的方案，但是目前除非使用Amazon提供的商用SimpleDB之外几乎没有通用的解决方案，每个公司甚至每个项目需要面对及考虑数据规模增大的问题。比如初步统计下国内研究可扩展数据存储及访问的项目就有
当然上面几个只是冰山一角，大部分互联网公司都有自己的数据层分布及访问实现，只不过没有对外公开而已。架构师、DBA、程序员具备这方面的实践经验及技能当然是好事，但是如果业界能够有通用稳定的解决方案来解决大家的重复工作则对整个业界更佳。PNUTS虽然声称会开源，但是一直没有进一步消息。而且即使开源是是开放核心代码还是全部可用于部署的程序(比如YMB等)这也是一个问题。
当然，我不是第一个也不是最后一个考虑这个问题的，比如2006年Greg Linden就说I want a big, virtual database
What I want is a robust, high performance virtual relational database that runs transparently over a cluster, nodes dropping in an out of service at will, read-write replication and data migration all done automatically.
I want to be able to install a database on a server cloud and use it like it was all running on one machine.
参考资料
