GAE对象数据库设计特点

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一共有多少对象。

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