AppEngine 数据存储区中的过度读取答案

【问题标题】：Excessive reads in AppEngine datastoreAppEngine 数据存储区中的过度读取
【发布时间】：2013-04-25 23:42:17
【问题描述】：

我正在将数据批量导入到最初采用另一种格式的 appengine 数据存储中（我的应用会处理该部分）。

当前阶段插入最终作为一对实体（不同种类的）的对象。对中的每个实体都有 4 个（索引属性），然后在插入它们后，我再次重写它们以添加使用 id 的第 5 个属性（也是索引的，并且是唯一更改的属性）。

我在这样做时开始遇到免费配额限制，所以我一天插入了大约 1000 对这样的对。我真的不知道为此使用了多少配额，因为这不是我那天做的唯一事情。

所以，第二天我又试了一批。我又增加了大约 500 个，发现我的配额使用情况非常奇怪。

我使用的写入配额为 0！后来我发现了这一点，我试图进行 XG 事务但没有设置适当的选项，所以写入失败，这是有道理的。没有意义的是，我的读取使用量超过了 30,000 次操作（占我每日配额的 60+%）！这些实体中的每一个在写入后都会从其他 2 个实体中读取，因此预计会有一定数量的扇出，我预计会有 500 个项目 * 2 个实体/项目 * 2 个读取/实体 = 2000，而不是 30,000！

我如何追踪发生了什么？

【问题讨论】：

标签： google-app-engine

【解决方案1】：

打开应用统计。它提供了每个请求的数据存储使用情况的详细视图。

【讨论】：

我打开了 appstats。得到了一些有趣的数据。有一些我没想到的 RunQuery 操作。我将不得不跟踪我的代码。更好地使用内存缓存可能会有所帮助。它没有显示每次调用发生了多少读/写操作，所以它仍然有点猜测。另外，我想检查我缓慢导入的进度，所以我去了管理页面上的 Datastore Admin。统计数据在 5 天内（自 4 月 27 日起）未更新。我以为可能是因为我每天的阅读配额都用完了，但昨天我把它留在了 60% 仍然没有更新。
添加一些日志代码来识别每次获取返回的实体数量非常容易，这将有助于估计每次查询的成本。您正在寻找一些意外的扇出、重复读取或返回比您预期更多的实体的查询。或者，您可以执行 StackOverflow 的用途：发布一些代码，人们可以查看它以查看是否存在任何潜在问题。
我没有发布代码的原因是问题出现在非常依赖于我编写的大型库的代码中，我认为发布 1000 行代码中的 10 行是不行的:-) 我将尝试添加更多日志记录，看看是否可以将其固定下来。如果这不起作用，我会在查看是否可以使用适合发布的独立代码重现问题后再次跟进。