分布式数据访问调研.doc

分布式数据访问调研
分布式数据访问调研
2011年10月15日
当前,使用业务和逻辑隔离的部署已经成为主流,但是对具体存储部署和接口的依赖,一直成为存储对业务逻辑完全透明的一个障碍。
为达到达到业务逻辑不必真正关心具体的存储逻辑,方便快速开发,便于日常维护,简化迁移等目的。对数据存储需要有一下的问题需要解决:
1. 抽象数据模型,统一数据访问接口,屏蔽业务层对数据层的逻辑依赖。同时提高业务的可维护性。
2. 解决当机房内的分布式数据相关问题,屏蔽业务层对数据部署,健康状态的依赖。同时提高对存储资源部署的灵活度。
3. 国际化跨IDC数据高可用性,互通,一致等问题。
4. 资源调度,资源隔离,屏蔽具体业务对资源的依赖。同时提高全局的资源利用率,降低整体成本。
5. 提供更好的数据抽象,便于快速开发,同时促进数据访问模式一致。
在当前的规划下,我们准备设计实现一套数据访问中间件,达成上面的目标;为了更好的实现数据访问中间件,达到既定目标,对业界知名的一些服务,产品进行调研,一方面补充我们在过去的思考中没有涵盖的需求,另外一方面对我们具体的实施,给出有意义的参考建议。 Yahoo的PNUTS是一个分布式带国际化方案的数据存储平台。PNUTS显然就深谙CAP之道,考虑到大部分web应用对一致性并不要求非常严格,在设计上放弃了对强一致性的追求。代替的是追求更高的availability,容错,更快速的响应调用请求等。
可扩展性
目前大多数的流行的web应用,对存储的可扩展性的需求主要是两部分:逻辑上的可扩展性和物理上的可扩展性。逻辑上的可扩展性:需要支持一个可扩展的数据引擎作支持,另外为数据提供非固定的表结构(schema-free);物理上的可扩展性:支持扩容/扩展资源的时候,需要尽量少的操作并且对系统的性能冲击尽量低。PNUTS在这两方面都做了相应的支持。
响应时间与地域
Yahoo的SNS服务大部分是全球化的服务,有很明显的地域性和要求低延迟的需求。假设某个应用的数据,具有全球化的信息,例如好友关系,需要在不一样的IDC内,做到低延迟访问,PNUTS通过多IDC部署副本的方式来支持,保证在不用地域的用户能够快速访问到所需要的数据。
高可用性与容错
Yahoo的应用需要一个高可用性的存储服务做支持。提供高可用性,需要容错和一致性两方面做一个权衡。例如,在存储服务出错的时候,保证所有的应用都能够读取存储服务的数据,但是一些应用必须要在这时候进行写操作,这样就会产生数据不一致的风险。PNUTS对各方面容错进行了考虑,包括 server出错,网络划分出错,IDC不可用等等。
弱一致性模型(最终一致)
传统的数据库需要支持序列化的事务,但是这里需要有个权衡,那就是:性能/可用性与一致性。按照我们的经验,大部分的Web应用,强一致性的需求都不是必要的。例如一个用户改变了他的头像,即便是他的好友不能马上看到这一修改,也不会造成什么严重的后果。PNUTS通过一种最终一致性(timeline consistency)支持,但也保留了强一致性的接口,可以通过该接口,强制读取最新的数据。

图1 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的异步消息订阅系统。 PNUTS主要是设计为在线存储服务,主要解决在线的大量单记录或者小范围记录集合的读和写访问。支持简单的关系型数据模型,并不支持大的二进制对象(如image、video),另外“blob”类型在PNUTS是支持的。
支持灵活的Schema,可以动态增加属性而不需要停查询或者更新,而且记录不需要对所有的属性赋值。目前只支持单表的查询,并且由应用指定两种索引方式(hash、ordered),支持单记录查询和范围查询。多表查询通过批量接口支持(接口需要给出多个表的ke