Question

我需要帮助才能理解为什么以下代码需要3到4秒。

更新：我的应用程序的用例是获取自上次登录以来的人的活动供稿。此Feed可能包含来自朋友的更新或他网络之外的一些他可能感兴趣的新项目。 Activity表存储所有这些活动，当用户登录时，我在GAE-DataStore上运行查询以返回上述活动。我的应用程序也支持无限滚动，因此我需要GAE的光标功能。在给定的时间，我得到大约32个项目，但活动表可能有数百万行（因为它包含来自所有用户的数据）。

目前，Activity表很小，只包含25条记录，下面的java代码只读取同一个表中的3条记录。

Activity表中的每条记录都有4个UUID字段。

我无法想象如果表包含数百万行且结果包含100行，查询将如何表现。

下面的代码有什么问题吗？

（我正在使用Objectify和app-engine游标）

Filter filter = new FilterPredicate("creatorID", FilterOperator.EQUAL, userId);
Query<Activity> query = ofy().load().type(Activity.class).filter(filter);
query = query.startAt(Cursor.fromWebSafeString(previousCursorString));
QueryResultIterator<Activity> itr = query.iterator();
while (itr.hasNext())
{
    Activity a = itr.next();
    System.out.println (a);
}

我已经完成Google App Engine Application Extremely slow并验证了如果我继续刷新页面（调用上面的代码），响应时间会有所改善。然而，改善仅为~30％

将此与任何其他数据库进行比较，这些微小数据的响应时间以毫秒为单位，甚至不到100毫秒。

我期望从GAE DataStore获得常规数据库的性能是错误的吗？

我还不想打开memcache，因为我想先改进这个图层而不先缓存。

Answer 1

不完全确定您的查询应该做什么，但它看起来不需要游标查询。在我看来，游标查询的唯一有效用例是对结果行数量有限的数据进行分页查询。由于您的查询没有限制，我不明白为什么您要使用光标。

当您需要数百万个结果时，您可能正在对数据进行临时分析（因为没有人能够解释数百万个原始数据行），您可能最好使用BigQuery而不是appengine数据存储。我只是在这里猜测，但对于普通的前端应用程序，你很少需要数百万行的结果，但只有少数（可能是数百次）你从总的可用行中过滤掉。

另一件事：

你确定这是一个需要很长时间的查询吗？它也可能是查询的包装器。由于您使用的是游标，因此必须重新调用查询，直到没有更多结果为止。处理这个问题可能会很昂贵。

最后：

您是在测试appengine本身还是在本地开发服务器上？ devserver很可能不会模拟云，因此有时可能比真实的更慢（或更快）。当您的查询生成新实例时，devserver不知道实例预热时间。

说到云：关于云数据库的问题并不在于它们对于非常少的数据具有最佳性能，而是它们可以在数百和数十亿行的情况下一致地扩展和执行。

编辑：

执行检索操作后，应用程序可以获取a   cursor，这是一个标记索引的不透明的base64编码字符串   检索到的最后一个结果的位置。

[...]

光标的位置被定义为结果列表中的位置   在最后一个结果返回后。光标不是相对位置   清单（它不是抵消）;它是数据存储区的标记   在开始索引扫描结果时可以跳转。如果结果为   查询在使用游标之间进行更改，查询通知仅更改   在光标后的结果中出现。如果之前出现新结果   对于查询的光标位置，当它的时候不会返回   获取光标后的结果。   （Datastore Queries）

这两个语句使得查询性能应与游标查询一致或不一致。

以下是您可能需要检查的更多内容：

如何用objectify注册实体类？
您的实际测试代码是什么样的？我想看看你测量的方式和位置。
您可以在没有游标的情况下共享游标查询和查询之间的比较吗？
多个请求的改进可能是Objectifys集成缓存的结果。您可能希望禁用数据存储区性能测试的缓存

Google App-Engine数据存储区速度极慢

1 个答案: