我有一个长期运行的工作,可以更新1000个实体组。我想在之后启动第二份工作,必须假设所有这些项目都已更新。由于有太多的实体组,我不能在一个事务中执行,所以我只安排第二个作业在第一个完成后使用任务队列运行15分钟。
有更好的方法吗?
是否可以安全地假设15分钟承诺数据存储与之前的呼叫同步?
我正在使用高复制。
在关于HRD的Google IO视频中,他们列出了处理最终一致性的方法。其中一个就是“接受它”。一些更新(如twitter帖子)不需要与下一次阅读保持一致。但是他们也说了一句“嘿,我们只是说它们在一致之前的几秒钟之内”。这个时间框架是否记录在其他地方?是否安全,假设在再次阅读之前等待1分钟再次阅读将意味着所有我的早期写入都在读取中?
此视频的提及时间为39:30({3}}
答案 0 :(得分:0)
我认为没有任何内置方法可以确定更新是否已完成。我建议将lastUpdated字段添加到您的实体并使用您的第一个作业进行更新,然后在运行之前检查您正在使用2nd更新的实体的时间戳...有点黑客但它应该有效。
有兴趣看看是否有人有更好的解决方案。有点希望他们这样做; - )
答案 1 :(得分:0)
这是自动的,只要您获得实体而不将一致性更改为Eventual。 HRD在返回之前将数据放入大多数相关数据存储区服务器。如果您正在调用put的异步版本,则需要先调用get对所有Future对象,然后才能确定它已完成。
如果您要查询第一份作业中的项目,则无法确定索引是否已更新。
所以例如......
如果要更新每个实体的属性(但不创建任何实体),则检索该类型的所有实体。您可以执行仅键查询,然后执行批量获取(与正常查询一样快/便宜),并确保已应用所有更新。
另一方面,如果您在第二个进程查询的第一个进程中添加新实体或更新属性,则无法确定。
答案 2 :(得分:0)
我确实找到了这句话:
通过最终的一致性,超过99.9%的写入可在几秒钟内用于查询。
在本页底部: http://code.google.com/appengine/docs/java/datastore/hr/overview.html
因此,对于我的应用程序,下次读取时不存在的可能性为0.1%可能没问题。但是,我计划重新设计我的架构以使用祖先查询。