Java google app engine数据存储中查询聚合（“分组依据”）的替代策略

无法查询应用程序引擎数据存储以获取聚合结果

例如： 我有一个名为“Post”的实体，具有以下字段：

键id、字符串昵称、字符串postText、整数分数

在我的数据存储中，我有许多不同的昵称和每个昵称对应的许多帖子

如果我想要一个总分前十名的领导委员会，我通常会有如下sql：

select nickname, sum(score) as sumscore
from Post 
group by nickname 
order by sumscore 
limit 10

这种类型的查询在google app engine数据存储java api（jdo或jpa）中是不可能的

我可以使用哪些替代策略来实现类似的结果

我可以粗暴地加载每个Post实体，并在应用程序代码中完整地计算聚合。这在大型数据集上显然是无效的

---

我还可以采用什么策略？

创建一个

昵称

模型，每次添加新帖子时，检索相应的昵称并增加存储的分数总和。基本上，在插入/更新时进行计算，而不是在查询时。

Hi Amber。谢谢你的贡献。我已经在某种程度上这样做了。（我的模型比我描述的更复杂）。我已经收集了很多关于插入和更新的数据来解决这个问题。但以这种方式保存所有可能的聚合统计数据是不可行的（我有很多不同的聚合统计数据，我想时不时地计算）。但这仍然是一个有效的答案。Amber的方法是正确的，它将扩大规模。我使用一种非常类似于“物化视图扇入”（fan-in-with-materialized view）的方法来计算几十个聚合。它工作得很好，我使用这种技术，加上切分来最小化争用（）；以及能够原子化地推迟此类计数器和统计数据的更新。我认为这个答案是最好的。如果谷歌只更新他们的插件，DataNucleus会透明地为你提供“粗野和暴力”的方法。实现这一点的代码只有一年前贡献的插件的几行代码…@DataNucleus拥有内置支持不会使它更快或更高效。@Nick，当然不会，但整个用户体验会更令人愉快，而且人们需要编写的代码数量也会减少——这就是我们的业务in@DataNucleus关键是，如果您试图在读取时进行这种聚合，那么您可能正在做一些不应该做的事情。很少有人认为在读取时执行聚合查询是正确的选择，除非您正在执行OLAP类型的工作，而应用程序引擎并不是为OLAP类型的工作而构建的。尽管可能是这样，但DataNucleus所说的实际上是一个很好的建议，因为它提供了一个标准的完整实现。意味着人们有可移植的代码。有了谷歌这个标准，你可以拥有一点点，但随后必须为他们的平台重写你的代码。就我个人而言，我希望能够将我的代码交换到MySQL或GAE上运行，而不必进行各种黑客攻击，并准备接受偶尔出现的低效查询，以提高可移植性