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，即�**潭ū斫峁埂Ｊ导适褂胟ey/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.
from: http://timyang.net/architecture/yahoo-pnuts/
原文出自：B. Cooper, R. Ramakrishnan, et al. PNUTS: Yahoo!’s Hosted Data Serving Platform. PVLDB, 1(2):1277–1288, 2008.
=============
ApacheCon 09 上有一个关于 Yahoo! 云计算平台的设计思路和技术点 的 keynote, 对技术人员而言算是比较靠谱的云资料. Yahoo! PNUTS 是 Yahoo! 云计算体系中, 提供实时数据服务 (用户 profile, session, 社区网站 etc.) 的部分. 可以把 PNUTS 理解成一个可以无限扩展的大关系式数据库集群, 可以对单表进行各种查询以及单条数据更新 --- 它比 BigTable 或 GAE 的 DataStore 等更接近这一概念. 通过这篇论文 PNUTS: Yahoo!'s Hosted Data Serving Platform 可以了解它的基本设计.
基本设计
PNUTS 给我的第一个感觉就是: 土, 换个说法, 实在. 它没有什么花哨的东西, 一些基本要素就是:
- 底层存储支持 hash 和 ordered, 在论文中 ordered 的存储还是实验性的, 而且底层存储用的是 MySQL innodb, 在 apachecon 上发现已经是个叫 YDOT FS 的咚咚了 (别告诉我是换汤不换药).
- 数据分块, 根据 key hash 到一个 [0-2N] 的空间, 然后不同的机器存其中一组 tablet, 如果 tablet 大了就分裂, 机器存不下了就迁 tablet. 连 consistent hash 都不来一下. 不过确实简单好用, 不但可以适应 hash 和 range 分块的情况, 数据块跟踪和维护迁移机制也简单很多.
- tablet controller 保有 tablet 路由表, 一个 router 负责向存储单元查询, 对批量查询和 range 查询, 由 router 根据路由表决定查询哪些存储单元, 然后进行并行查询, 而对外给出一个易于理解的单连接接口.
- Message Broker, 一个可靠的消息传输服务, 实现 replication, 有效保证存储数据可靠和一致.
没有什么 magic, 是一个很容易看明白的架构.
一致性模型
有趣的是它的一致性模型和实现方法. 我们都知道 CAP (Consistency, Availbility, Network Partition) 不可兼得(让我最郁闷的是这个很好证明我却在这上面兜了那么久圈子), 不同的存储系统根据它的背景和业务需求在这三者中进行权衡. 例如 Amazon Dynamo 就是一个相当极端的最终一致模型, 并且需要开发者来处理不一致, 不同版本的合并问题. 而 PNUTS 的思路, 更明显地是来自社区或其他实时提交业务的经验: 快速开发, 编程模型尽量简单, 对一致性有要求但不同的场景要求不一, 要求可扩展性但不要求绝对的线性可扩展. 也来自于他们长期使用 MySQL-based 架构的经验, 以至于最后的设计还是我们很熟悉的一套.
PNUTS 首先提供了时序一致, 一个记录在不同机器上的状态可能不同, 但只会是某个严格顺序的状态序列中的其中一个, 不会出现 Dynamo 中的多分支版本, 需要应用处理冲突合并的情况. 实现方法很简单: 我们玩到熟的主从. 不同的是, 它不把鸡蛋都放在一个篮子里, 每个记录都有属于自己的一个 master 节点, 而要进行记录插入和删除操作时, 则使用基于 tablet 的 master 节点. 基于 PNUTS 只提供单条更新的前提, 这是很简单的事.
另一方面, 在读取端 PNUTS 能提供多种不同约束的读取模式: read-any, 用于纯浏览任务, 获取数据的任一状态; read-critical 和 read-latest 提供了必须读到某版本之后或最新版本的保证, 这可以用于完成典型的先查后改的更新模式. 这个如果简单粗暴点, 跟在 MySQL 中的主从架构一样, 纯浏览任务可以从从库中读, 但不保证从库是最新版本; 而更新操作中若需进行查询, 则需在主库上进行.
由这个一致性模型和它的实现, 我们可以看到 PNUTS 在 CAP 上的取舍:
- Network Partition vs. Consistency. 网络分片是扩展性的保证, 不可舍弃. 所以需要使用 replication, 它能使记录的不同备份最终一致. 考虑 master 挂掉需要选举新 master 的时候, 这时候 Network Partition 就要削弱; 另外, 如果所有的 replication 更新都是异步的话, 在 master 接到一个更新而所有 slave 都未同步的时候 master 挂掉, 是会丢数据的, 根据 Paxos, 要保证 N 个副本更新最终一致至少要 N/2+1 的副本同步确认, 这里是没有做到的. 这方面的可靠性由 YMB 可靠消息服务保证, 但要保证这个服务的可靠和一致, 需要的方法和同步确认的节点数是相同的 (YMB 采取同步写双盘策略).
- Availability vs. Consistency. 在这方面, Dyanmo 采取的是 always writable 策略, 而 PNUTS 显然更偏向后者. 一方面, 考虑 master-slave 架构, 当 master 挂掉的时候, 需要一个很长 (可能是秒级) 的时间发现和进行一次分布式选举决出新 master, 这段时间这个数据节点其实是不可写的; 另一方面, 如果需要保证一个记录先查后改的更新事务的原子性 (例如加减账户金额), 必须做 read-latest + test-and-set, 因此更新有可能失败而需要应用层重试, 带来另一种需要在应用程序中解决而不会被最终用户发现的不可用.
最后
之所以 PNUTS 叫做 ``云'', 不仅因为它的扩展能力, 更因为它是 hosted 的, 不是每个应用都搭一套自己的集群, 而是所有应用共享一个存储集群, 各自用自己的表. 从纯技术角度而言, 这似乎没什么挑战, 这造成了我们往往缺乏这方面的考虑. 我经常说应用生态是一个长尾: 极少数类似 Google Search 这样的超级应用, 他们必须使用专用的集群, 专用的软件和硬件, 为特殊需求优化; 而又有大量中小型应用, 他们需要易用, 低成本的云计算平台. 基础架构对这两种应用的满足方式是不一样的: 前者考虑的是必然无限增大的规模, 考虑为特定应用的效率无限优化; 而后者虽然同样考虑单个应用的可扩展性, 但无需达到无穷的规模 --- 当他们成长为另一个长尾头部应用时, 设计特殊方案是必然的, 另一方面, 却要考虑数量极大的中小规模应用堆在一个集群里的各种情况: 账号和 quota 管理, 数据隔离, 应用压力的平衡等等. 功能细微, 没啥挑战性, 常常被遗忘. 在这方面 PNUTS 显然没有遗漏.
PNUTS 是一个很容易借鉴的系统. 我们不需要像 Hadoop vs. GFS + MapReduce 一样照着 PNUTS 搭一套. 它的设计点, 特别是对 CAP 的权衡考虑和实现方法, 能很容易融入到已有系统设计中. 从从这方面看, 它会比 BigTable, Dynamo 这样的明星项目 ``实用'' 得多.
from:http://randomtaste.appspot.com/view/page/yahoo-pnuts
