实体组 - 决定如何分组 [英] Entity Group - deciding on how to group

问题描述

我在整个互联网上都读过，数据存储实体组的每秒写入次数限制为1次。我读到的大部分内容都表示写入实体，我将其理解为更新。每秒1次写入是否也适用于将实体添加到组中？

一个简单的例子是一个Thread，其中可以由不同的用户添加多个帖子。我看到它的方式，让Thread成为帖子的祖先是合乎逻辑的。因此，形成一个广泛的实体组。如果我对上述问题的回答是肯定的，那么一个趋势线程将会受到写入限制的破坏。

也就是说，摆脱祖先完全是祖先还是应该切换为用户？我希望避免的是，当用户因最终一致性而看不到该帖子时，他们会感到困惑。

解决方案

以开始的快速说明

每秒写入1次并不意味着每秒1个实体。您可以一起批量写入，最多可以有500个实体（交易也有10个MiB限制）。因此，如果你可以修补帖子，你可以提高你的写入速度。注意：你可以在技术上超过1每秒，尽管你的争用错误的风险增加了更长的时间您超过了此限制以及系统的最终一致性。

您可以阅读限制在这里。

客户端分片

如果您需要使用祖先查询来提高一致性，并且每秒写入1次是不够的，则可以实施客户端分片。这基本上意味着您可以使用已知的密钥方案将帖子写到最多 N 不同的实体组中，例如：

• 主要父项：AncestorA
  
• 可选分片1：AncestorA-1
  
• 可选分片N：AncestorA-（N-1）

要查询您的帖子，请发送 N 祖先查询。当然，您需要将这些结果合并到客户端，以正确的顺序显示。

这将允许您执行 N 每秒写入数据。

I've read throughout the Internet that the Datastore has a limit of 1 write per second for an Entity Group. Most of what I read indicate a "write to an entity", which I would understand as an update. Does the 1 write per second also apply to adding entities into the group?

A simple case would be a Thread where multiple posts can be added by different users. The way I see it, it's logical to have the Thread be the ancestor of the Posts. Thus, forming a wide entity group. If the answer to my question above is yes, a "trending" thread would be devastated by the write limit.

That said, would it make sense to get rid of the ancestry altogether or should I switch to the user as the ancestor? What I'd like to avoid is having the user be confused when they don't see the post due to eventual consistency.

解决方案

A quick clarification to start with

1 write per second doesn't mean 1 entity per second. You can batch writes together, up to a maximum of 500 entities (transactions also have a 10 MiB limit). So if you can patch posts, you can improve your write rate.

Note: you can technically go higher than 1 per second, although your risk of contention errors increases the longer you exceed that limit as well as the eventual consistency of the system.

You can read more on the limits here.

Client-side sharding

If you need to use ancestor queries for strong consistency AND 1 write per second is not enough, you could implement client-side sharding. This essentially means that you write the posts to a up to N different entity-groups using a known key scheme, For example:

• Primary parent: "AncestorA"
• Optional shard 1: "AncestorA-1"
• Optional shard N: "AncestorA-(N-1)"

To query for your posts, issue N ancestor queries. Naturally, you'll need to merge these results on the client-side to display it in the correct order.

This will allow you to do N writes per second.

这篇关于实体组 - 决定如何分组的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！