随着在国外一些开放API的成功,国内开放的趋势尤其是在SNS领域也开始涌现,实际上开放的需求不局限SNS领域,所有的互联网应用都可以从开放API获得更多的用户使用等潜在的价值。Tim在这方面也进行了一些尝试和思考,这里初步探讨开放API产品及开发方面实践中需要面对的几个问题。
Archive for June, 2009
国内开放API平台实践的一些问题
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,容错,更快速的响应调用请求等。
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的结构
2.3 Tablets寻址与切分
2.4 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之外几乎没有通用的解决方案,每个公司甚至每个项目需要面对及考虑数据规模增大的问题。比如初步统计下国内研究可扩展数据存储及访问的项目就有
- 手机之家的数据访问层封装DAL 2.0
- 盛大陈思儒写的开源项目Amoeba,类似MySQL proxy
- 国内的Erlang geek @litaocheng 曾经对Dynamo paper深有研究,正在开发开源的erlang Dynamo实现e2dynoma
- 豆瓣的doubanDB,也是类Dynamo实现
当然上面几个只是冰山一角,大部分互联网公司都有自己的数据层分布及访问实现,只不过没有对外公开而已。架构师、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.
参考资料
- [1] [Paper/PDF] PNUTS: Yahoo!’s Hosted Data Serving Platform
- [2] [PPT] PNUTS: Yahoo!’s Hosted Data Serving Platform
Facebook平台设计(一)
为了研究Facebook platform的设计, 我们可以从最早的第一个版本f8 07开始了解,当时是由Facebook创始人兼CEO Mark Zuckerberg 在2007年5月f8开发者会议上发布的。根据当时的数据是,50%以上的Facebook用户会每天都访问Facebook,超过同行3倍以上。
为了理解Facebook平台,我们可以从Facebook相册说起。Facebook相册虽然只提供了最简单的特性,比如不能存高像素原图,没有编辑工具等,非常简单,但是Facebook的相册流量是是其他所有相册(Flickr, Picasa…)流量之和的2倍以上。为什么?这就是Mark介绍的Social Graph的力量。
1. 用户A上传图片,他所有好友都能看到。
2. 用户A继续在图片上tag people(标注图片上的好友),这个tag的图片会出现在被tag好友B profile wall上,接着B的好友接着可以看到这个图片(受privacy设置控制,默认开启)。
特别是第2点它扩大了传播范围,在Facebook认为,第2点比1更为重要,Facebook平台的意义就是在这里。”we build the platform optimize for build apps for social graph”,开放平台的意义就是让扩展应用将social graph发扬光大。
“在Facebook开放平台以前,social network封闭式平台,但是今天这种情况结束了”
Facebook Platform的三大目标
1. Apps深度整合到Facebook平台(Deep Integration Into Facebook Website)
- app可以集成到用户profile
- app拥有独立的首页(canvas page),首页完全是应用自己控制的,可放任何内容,包括广告。
- app可以以用户身份发布feed
- app可以发送消息,邀请,提醒等
一个应用只要被用户授权访问他的profile之后,应用就可以调用api获取到比如user/friend/application/privacy information,Facebook API接口也值得各种平台设计者学习。比如用户API接口
2. 病毒式的传播(Mass Distribution through the Social Graph)
传播的核心是feed体系(从09年的眼光来看,Twitter的feed可能比它做得更出色,甚至造成了威胁,并进一步引发它最近的homepage改版)。App可以发布3种不同类型的Feed
- application story,相当与应用添加提醒,比如A添加了某应用。
- simple story, feed里面表现为一行文本。
- full story, 详细,可以预览图片,视频等。
关于feed可参看另外一篇技术分析文章:Facebook的feed格式设计
App可以发送notification(提醒),request(邀请)。Facebook还提供平台级别的工具如friend selector供app使用。Facebook还通过应用嵌入到Profile通过exposure让更多的用户来使用,比如用户看到好友Profile某个应用有趣也会立即add。
通过以上途径,促进应用的传播,促进信息的传播,促进人的社会化交流。
3. 商业机会(New Business Opportunity)
canvas page可以放任何广告,也可以进行电子商务进行销售,app可以获得所有收入。对于这两种方式,Facebook都是持支持态度。
视频:Mark Zuckerberg Keynote Speech f8 2007
http://www.facebook.com/video/video.php?v=28202665043&ref=mf