GAE对象数据库设计特点

Google App Engine的数据库属于对象数据库,设计的思路比较独特,主要适用于“多查询,少更新”的web应用。今天去参加Sun的开发者日,正好有个MySQL的讲座,其中提到MySQL的pluggable storage engine当中,针对web应用优化的MyISAM,也是延续这个思路。不过MySQL毕竟是关系数据库,对于复杂的表查询操作,专家和新手写出来的语句,效率那可是千差万别。而GAE则不同,可以保证任何人只要能完成功能,效率都不会太差。当然,这是以牺牲部分功能作为代价的。但是想一下,还是更喜欢GAE的方式,毕竟设计数据结构和关系的时候就把问题解决,总比上线以后才发现数据库操作效率低下要好。

使用GAE的Python版和Java版做的程序也有好几个了,正好把它与传统的关系数据库比较一下。

  • 查询比更新快十倍。
  • 查询结果数量有限制。GAE进行查询时最多返回1000条数据,即使使用count来查看记录数量,最多也只返回1000。但是,在获取数据时可以指定offset,这样可以简单分页。
  • 想统计,就要维护计数器。由于最多返回1000,无法得知到底有多少数据,如果程序中需要总数、平均值、总和、按月总数等等统计数据,就要自己维护一个计数器对象。具体做法,参考Google官方的文章计数器
  • 先索引,后查询。出现在查询条件中的字段,必须设置索引。
  • 不用严格遵循数据库设计范式。在关系数据库中,类别名称、tag名称等一般要独立成表,然后使用时放置索引。但在GAE中,对象可以直接保存这些短小的数据,这样在查询时就规避了GAE无法进行表关联的缺点,而且由于有索引,这样速度其实也非常快。
  • 查询条件,只能有一个不等。允许有多项查询条件,但是其中只能有一项是非相等条件(例如:大于,小于)。
  • ID或Key的使用,用于定位获取对象,速度最快。对于帐户对象,可以使用唯一的email作为key,这样更新时就不需要再查询一次了,直接在Transaction中完成更新即可。
  • 在一个Transaction中,不能出现不同组的对象。
  • 尽量减小单个组内的对象数量。由于Google App Engine属于云计算,所有的对象数据都分布在无数节点之上,这样数据查询可以并行完成,速度大大提高。如果把大量对象放置在一个组内,所有这些对象只能存在一个节点之上,查询时就没有并行查询的优势了。
  • 数据关系的强制一致性。如果删除一个对象,所有依赖于该对象的对象都将被删除。
  • tag的实现,可以结合对象的list属性,直接保存所有的tag字符串。这样便于查询、增减。但不利于统计例如:具有某tag一共有多少对象。

暂时想到这么多,有空再补充。

DeliciousDiggFacebookStumbleUponFriendFeedMySpaceTechnorati FavoritesTwitterLinkedInRedditGoogle BookmarksMixxShare

关于 Harry

关注产品管理,敏捷,Google,iPhone等领域。