Question

我正在使用Java。我这里有简单的场景。有4种1用户，2个帖子，3个评论，4个类似

祖先关系就是这样使用的。

 user---->post---->comment
           -
           ------->Like

用户是评论和喜欢的帖子以及父母的父母。帖子是评论的父母，喜欢。

在我的应用程序中，我需要最近3条评论的帖子。当用户点击评论按钮然后获得该帖子的所有评论和喜欢的相同。 Facebook和Instagram之类的东西。我认为对于这种情况，上面的结构（关系）是有用的，不是吗？

但问题是如文件中所描述的最大运行率为1 / s。如果从此操作增加，可能会出现错误。

单个实体组中的写入吞吐量限制大约为每秒一个事务。存在此限制是因为云数据存储区在广泛的地理区域上执行每个实体组的无主，同步复制，以提供高可靠性和容错性。 Documention

避免每秒多次写入实体组。以高于该限制的持续速率写入最终会使读取更加一致，导致强一致性读取超时，并导致应用程序的整体性能降低。对实体组的批处理或事务写入仅计为针对此限制的单个写入。 Documention

很有可能在一秒内有多个相似或评论。所以我在这种情况下做了什么。

任何建议如何克服这种情况或任何其他更好的结构？

Answer 1

正如您所提到的，文档说单个实体组中的写入吞吐量限制大约是每秒一个事务，我有两个建议：

在您的设计中，您拥有赞的发布父级，是的，这是一个潜在的问题，因为可能会有一些帖子，其中喜欢的内容每秒发生一次以上（ 如果是热门帖子）。那么为什么不使用最终的一致性呢？为什么使用父/祖先查询？实时更新喜欢是绝对必要的吗？
评论相同，而不是让它成为帖子的孩子，让它成为用户的孩子，单个用户不可能写多个评论每秒。

因此，在这种情况下，这可能是图

所有用户家长： 强一致性

User ---> Post
    |---> Comment ```with a Key property referring to the Post```
    |---> Like ```with a Key property referring to the Post```

或者 仅限Post＆amp;的用户父母评论： 尝试平衡强大的＆amp;最终的一致性

User ---> Post
    |---> Comment ```with a Key property referring to the Post```

Like ```single entity with a Key property referring to the Post```

Answer 2

没有办法克服这一点。您最好重新组织存储结构，而不是相对而言。我的意思是，你只能将它们拆分成不同的种类，而它们之间没有任何父亲关系。

您应该预测每种类型的可能更新速率并适当地构建数据存储架构。

在这种情况下，我相信用户将无法以每秒1个帖子的速度创建帖子。但喜欢和评论可能会试图垃圾邮件您的数据库。所以，这意味着你应该将它们作为独立的种类。

当然，还有其他技术可以帮助实现这一点，例如分布式缓存层，但对于这类任务来说，这是非常复杂的解决方案。

Answer 3

您需要将这些数据与主要实体分开。

类似的例子是处理计数器时。在这种情况下建议使用sharding counters。

用于对读取所有分片后可在代码中进行的数据（例如最近的3）进行排序。为避免在每个请求中执行此操作 - 将该数据的快照放在内存缓存中，并每分钟重新填充该缓存或您可能需要的频率。

来自documentation on sharding：

该解决方案依赖于从App Engine数据存储区读取的速度非常快且便宜的事实。减少争用的方法是建立一个分片计数器 - 将计数器分解为N个不同的计数器。当你想增加计数器时，你随机选择一个分片并递增它。当您想知道总计数时，您会读取所有计数器分片并总结其各自的计数。您拥有的碎片越多，您在计数器上增加的吞吐量就越高。

每个单一实体组每秒写入限制 - 数据存储

3 个答案: