Google App Engine DataStore 一致性答案

【问题标题】：Google AppEngine DataStore constistencyGoogle App Engine DataStore 一致性
【发布时间】：2013-08-16 21:29:17
【问题描述】：

我目前对 Google AppEngine 的 High Replication DataStore 的理解如下：

Gets 和 puts 的单个实体始终是高度一致的，即一旦一个 put此条目完成后，get 不会返回早于已完成 put 的版本。或者，更准确地说，只要任何一个 get 返回新版本，以后 get 都不会再返回旧版本。
Gets 和 puts 的多个实体是强一致的，如果它们属于同一个祖先组并且在一个事务，即如果我有两个实体都在一个事务中被 put 修改，并在一个不同的事务中“同时”读取 get，则 get 将返回两个条目的旧版本或两个条目的新版本，具体取决于 put 事务在 get时是否已完成> 与否，但它永远不会返回一个实体的旧值和另一个实体的新值。
具有祖先过滤器的查询可以选择为强一致或最终一致，其中强一致查询需要更长的时间才能完成，但将始终返回“相同”版本（旧版本或new) 在此祖先组中的同一事务中更新的所有实体，而不是一些旧版本和一些新版本。
跨越祖先的查询始终是最终一致的，即可能返回一个结果实体的旧版本和另一个结果实体的新版本。

我做对了吗？这实际上记录在任何地方吗？（我只找到了一些关于查询一致性here（在第一个和第二个“Note”之间）和here 的文档，但它没有谈到 gets 和 puts em>...)

【问题讨论】：

作为记录，我会对第 1 点提出异议，我发现放置在单个实体上的低级别 API 数据存储的一致性延迟超过 15 分钟。即我更新一个实体并在 15 分钟后获取，它大部分时间会显示更新的数据，但每 10 个周期左右它会显示旧数据。这似乎与这篇文章一致：developers.google.com/appengine/docs/java/datastore/… 似乎说强一致性只能通过祖先查询来实现，但请注意 1 request/sec 限制。

【解决方案1】：

是的，你是对的。他们只是措辞略有不同：

一开始就有 5 个点形式特征。最后两个描述了您的问题，只是它们指的是“读取”而不是“获取”。

这可能会增加您的困惑，但是当它们表示“读取”或“获取”时，它实际上意味着直接获取实体 - 通过键或 id。如果您使用键或 id 以外的属性调用 python 'get' 函数，它实际上是在发出一个查询，该查询最终是一致的（除非它是祖先查询）。

【讨论】：