按:此为客座博文系列。投稿人吴朱华曾在IBM中国研究院从事与云计算相关的研究,现在正致力于研究云计算技术。 本篇会首先会从程序员角度来介绍一下Datastore在使用方面的一些信息,之后会接着介绍Datastore是如何构建的。 使用方面 首先,在编程方面,Datastore是基于”Entity(实体)”这个概念,而且Entity和”对象”这个概念比较类似,同时Entity可以包括多个Property(属性),Property的类别有整数,浮点和字符串等,比如,可以设计一个名为”Person”的Entity,它包含名为”Name”的字符串Property和名为”Age”的整数Property。由于Datastore是”Schema-less”的,所以数据的Schema都由应用维护,而且能非常方便地对一个Entity所包含的属性进行增删和修改。在存储方面,一个Entity的实例可以被认为是一个普通的”Row(行)”,而包含所有这种Entity的实例的Table被称为Kind,比如,所有通过”Person”这个Entity生成实例,比如小吴,小朱和小华等,它们都会存放在同一个名为”Person”的Kind中。在结构方面,虽然也能通过特定的方式在Datastore中实现关系型结构,但是Datastore在设计上是为层次(Hierarchical)性结构”度身定做”的,有Root Entity和Child Entity之分,比如,可以把”Person”作为Root Entity(父实体),”Address”作为”Person”的Child Entity,两者合在一起可以称为一个”Entity Group”。这样做的好处是能将这两个实体集中一个BigTable本地分区中,而且能对这两个实体进行本地事务。 接下来,将谈一下Datastore支持那些高级功能:其一是提供名为GQL( Query Language)的查询语言,GQL是SQL的一个非常小的子集,包括对””,””和”=”等操作符。其二是App Engine会根据代码中查询语句来自动生成相应Index,但不支持对Composite Index生成。其三是虽然由于Datastore分布式的设计,所以在速度方面和传统的关系型数据库相比一定的差距,但是Google的架构师保证大部分对Datastore的操作能在200ms之内完成,同时也得益于它的分布式设计,使得它在扩展性方面特别出色。其四是Datastore也支持在实体之间创建关系,比如在Python版App Engine中可以使用ReferenceProperty在实体间构建一对多和多对多的关系。 下表为Datastore和传统的关系型数据库之间的比较: Datastore 关系型数据库 SQL支持 只支持一些基本的查询 全部支持 主要结构 层次(Hierarchical) 关系 Index 部分可自动创建 手动创建 事务 只支持在一个Entity Group内执行 支持 平均执行速度(ms) 低于200 低于100 扩展型 非常好 很困难,而且需要进行大量的修改 表1. Datastore和关系型数据库之间的比较 最后,在接口方面,Python版提供一套私有的API和框架,在基本功能方面,比较容易学习,但在部分高级功能方面,比如关系和事务等方面,学习难度很高;Java版的API是基于JDO和JPA这两套官方的ORM标准,但是和现在事实的标准Hibernate有一定的差异。 实现方面 在实现方面,Datastore是在BigTable的基础上构建的,所以本段会首先重新介绍一下BigTable,之后会介绍Datastore的两个组成部分:Entities Table和Index,最后会讲一下它在事务和备份这两方面所采用的机制。 BigTable 在本系列的第一篇已经按照Google的Paper对BigTable技术做了一定的介绍,但其实BigTable本身其实没有之前介绍的那样复杂,其实就是一个非常巨大的Table,这也是是它之所以名为”BigTable”的原因,而且结构就像图1那样非常简单,就是一个个ROW,每个ROW都有一个Name和一组Cloumn,但是为了支持海量的数据,它将这个大的Table进行分片(Sharding)处理,每台服务器存储一个海量的Table的一小部分,并且为了查询效率,会对这个Table进行排序。就像App Engine的创始人之一Ryan Barrett所说的那样”BigTable is a sharded, sorted array “。 图1

Read the original post:
探索Google App Engine背后的奥秘(5)- Datastore的设计