转载自:http://timyang.net/architecture/yahoo-pnuts/
在分布式领域有个CAP理论(Brewer’s CAP Theorem) ,是说Consistency(一致性), Availability(可用性), Partition tolerance(分布) 三部分在系统实现只可同时满足二点,没法三者兼顾。所以架构设计师不要把精力浪费在如何设计能满足三者的完美分布式系统,而是应该进行取舍,选取最适合应用需求的其中之二。比如MySQL 5.1 cluster设计前显然不知道有CAP理论这样的经验, 所以MySQL cluster表面看来尽管可提供所有分布式特性,但实际大部分场合都无法提供稳定可靠的服务。
Yahoo!的PNUTS是一个分布式的数据存储平台,它是Yahoo!云计算平台重要的一部分。它的上层产品通常也称为Sherpa。按照官方的描述,”PNUTS, a massively parallel and geographically distributed database system for Yahoo!’s web applications.” PNUTS显然就深谙CAP之道,考虑到大部分web应用对一致性并不要求非常严格,在设计上放弃了对强一致性的追求。代替的是追求更高的availability,容错,更快速的响应调用请求等。
传统的数据库提供强一致性保证, 通常称为“serialization transaction”,保证调用时序的一致性。但在web应用中不是必须,比如用户A修改了自己的资料或上传了图片,他的好友B短时间不能立即看到并不是大的问题,通常的Web应用都可以接受。PNUTS像大部分分布式key/value系统类似,提供的是弱一致性的支持,也就是支持“最终一致性(eventually consistent)”。用户B最终会看到用户A的修改信息。
未够!但最终一致性并非可以适应所有场合,比如用户A修改了相册的访问权限,设置用户C不能访问,然后用户A又上传了新的图片,如果用户C处于另外一个IDC访问,如果图片数据先同步成功,而权限记录后同步的话,C实际上违反了A设置的权限而看到图片了。因此对于部分场合最终一致性是不够的。
每一条记录都有一个主记录。比如一个印度的用户保存的记录master在印度机房,通常修改都会调用印度。其他地方如美国用户看这个用户的资料调用的是美国数据中心的资料,有可能取到的是旧版的数据。非master机房也可对记录进行修改,但需要master来统一管理。每行数据都有自己的版本控制,如下图所示。
Write调用示意图
记录级别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?有何优点?
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.
参考资料