在GAE上使用 High Replication Datastore

• Master/Slave：
  采用主从复制系统。写数据时是写入主数据中心，然后再异步复制到从数据中心。读数据时可以选择使用强一致性，但这可能会遇到主数据中心暂时不可用和维护的情况。
  不过Google也提供了最终一致性方式来读取，当主数据中心不可用时，可以从从数据中心读取数据。但写数据以及使用事务是不能用最终一致性方式的。
• High Replication：
  采用Paxos算法，数据会被同时写入多个数据中心。读写时会有最快的速度，只有当所有数据中心都不可用时才会失败，但不能保证强一致性。
  相应的，Google也允许使用实体组来保证强一致性查询，但这需要使用祖先查询。而且如果使用实体组的话，由于实体组不能短时间内被多次更改，因此是无法高效地插入数据的。

Paxos这个算法之前我也研究过，大致上就是一个决策系统，当大多数数据中心认可一个读或写操作后，就认为它有效，因此不会遇到某个数据中心暂时无法访问而失败的情况。（印象中暂时不可用的出现概率是万分之三，懒得去确认了。）
至于开销和速度方面，Google提供了一个比较文档，大多数操作都要花3倍的开销（暂定，7月份可能会更改），而响应时间似乎没有明显提高（不过网络延迟应该会降低）。

此外，现有的应用都只能使用Master/Slave方式，只有创建新的应用时才能选择High Replication方式。因此Google也提供了一个复制数据的功能，以便你移植到新应用上。

顺带一提，Python SDK 1.4.1也发布了，只是把offline URL Fetch API的时间增加到10分钟而已，这个估计是计划任务或任务队列中的请求时间吧，正常的请求仍然有10秒限制。


更新性能测试：

以2个6字节长的应用来做对比测试，方法是创建、查询、获取和删除500个Test类型无属性的实体，代码如下：

from time import time
from google.appengine.ext import db

class Test(db.Model):
    pass

keys = [db.Key.from_path('Test', i) for i in xrange(1, 501)]
tests = [Test(key=key) for key in keys]
t = time()
db.put(tests)
print time() - t

t = time()
Test.all().fetch(500)
print time() - t

t = time()
db.get(keys)
print time() - t

t = time()
db.delete(keys)
print time() - t

测试结果：

Master/Slave：

1.52360796928
0.141813993454
0.147518157959
1.14946293831

ms=3060 cpu_ms=44519 api_cpu_ms=43446 cpm_usd=1.236788

High Replication：

4.77071118355
0.235147953033
3.09301185608
5.15948295593

ms=13304 cpu_ms=114004 api_cpu_ms=112812 cpm_usd=3.166840

由此可见，High Replication在各方面都比Master/Slave慢（特别是db.get()，慢了20倍），而且消耗的资源更多，因此绝大多数应用不建议使用它。

原文