java - 数据存储设计 - 如何模拟高效连接

Question

我有一个关于 Google 的数据库 Cloud Datastore 的设计问题。让我用一个例子来解释它:

我得到了具有以下属性的“文章”类型的实体:

• 标题
• 用户名
• ....
• sumOfScore

SumOfScore 应该是所有相关“分数”实体的总和，这些实体具有属性如:

• 文章编号
• 用户名
• 得分

在伪 SQL 中:
sumOfScore = 从 Score 中选择 sum(score) where score.articleId = article.id

我看到了两种设计方式(使用 Google 的数据存储 API):

1.) 文章没有属性 sumOfScore；但总是查询:

这意味着:每次阅读一篇文章时，我需要对这篇特定文章进行查询以计算sumOfScore。想象一下向用户显示的 100 篇文章的列表。这将需要对数据库进行额外的 100 次查询，以显示每篇文章的分数。

尽管如此:在使用关系数据库时，这是我的首选方式。没有冗余和良好的规范化。使用 SQL，您可以仅使用一个连接选择来捕获所有数据。但感觉它不适合 Cloud Datastore。

2.) 每当 Score 实体发生变化时计算 sumOfScore:

这意味着:每当添加、删除或更改分数实体时，相关的文章更新 sumOfScore 属性。

优点:阅读文章时不需要额外查询。 sumOfScore 在实体本身上是多余的。

缺点:每次更改分数，都会增加一次查询和一次写入(更新一个文章实体)。并且 sumOfScore 可能与实际的 Score 实体不匹配(例如，值通过 DB-Console 更改)

更有经验的人怎么想？这种情况是否有通用的最佳实践？引擎盖下的 JPA 或 JDO 实现是做什么的？

非常感谢

摩斯

Answer 1

The first thing I recommend you look into the GAE article about sharding counters .

那是一篇来自 GAE 最佳实践的文章，内容涉及您应该如何处理计数器/总和。这可能有点棘手，因为每次更新元素时​​，您都必须使用逻辑随机选择一个分片计数器；当您检索计数时，您实际上是在获取一组实体并对它们求和。我已经走了这条路，但不会在这里提供我是如何做到的代码，因为我还没有对它进行战斗测试。但是，如果您只是在各处复制/粘贴示例分片代码，您的代码可能会很快变得草率，因此如果您决定走这条路，请创建一个抽象或类型化的计数器类来重用您的分片逻辑。

另一种选择是使用模糊计数。此方法使用内存缓存并以牺牲准确性为代价提供更好的性能。

See the section here labeled "Transient and frequently updated data"

最后一个选择；就是只使用SQL。 Its experimental and hot out of the oven (in relation to being used on GAE) but it might be worth looking into.