NDB HRD 事务，哪个祖先决定实体组? [英] NDB HRD transactions, which ancestor determines the entity group?

问题描述

是被写入实体的最近的还是最远的父亲属，这决定了实体组?(问题 1)对于，如果我有，

Is it the closest or the most distant parent relative of the entity being written, which determines the entity group? (Question 1) For, if I have,

同时写入两个不同实体的两个请求，在本例中，都具有直接父级 Data 实体(键为2")，并且具有以下祖先:

two simultaneous requests to write two different entities, in this example, both having immediate parent the Data entity (with key '2'), and having subsequent ancestors of:

Person:9 > Collection:3 > Script:4 > Data:2 > Record of Tom Cruise
Person:9 > Collection:3 > Script:4 > Data:2 > Record of Shia La Boef

无论哪种情况，它们都属于同一个实体组，要么锚定在实体 Person:9 上，要么锚定在实体 Data:2 上.实体组 Person:9 或 Data:2 的正确确定器是哪个?此外，如果有两种实体从 Data:2 继承，比如 Record 和 Scheme，那么所有 Record 和 Scheme 实体是否都属于同一个实体组，由 Data:2 锚定，或者，凭借属于不同的种类，属于不同的实体组?(问题 2)

In either case they both belong to the same entity group, either anchored at entity Person:9, or at entity Data:2. Which is the correct determiner of the entity group, Person:9 or Data:2? Also if there are two kinds of entities descended from Data:2, say Record and Scheme, will all the Record and Scheme entities belong to the same entity group, anchored by Data:2, or, by virtue of being different kinds, belong to separate entity groups? (Question 2)

顺便说一句，如果是Person:9决定实体组，而一个parent下的不同种类不形成该parent下不同的实体组，那么一切都是Person:9的后代是同一个实体组，必须要连续写，太恐怖了

Incidentally, if it is Person:9 which determines the entity group, and different kinds under a parent do not form different entity groups under that parent, then everything descended from Person:9 is the same entity group and is going to have to be written in serial, the horror

因为在这个例子中，我同时对同一个实体组执行这些同种实体的写入，它们将被串行应用，因此需要双倍的时间"，而不是如果它们可以同时应用.

Since in this example, I am performing these writes of the same kind of entity to the same entity group concurrently, they will be applied serially, and therefore take 'double the time.', than if they could be applied concurrently.

对于这种加倍"的时间，有什么好的解决方案?(问题 3 - 可选！)

What is a good solution for this 'doubling' of time taken? (Question 3 -- optional!)

我想到了以下几点:

因为我知道这两个单独的写入必须由两个单独的客户端实例发起，所以我可以在链中添加一个进一步的祖先，它代表进行写入的客户端实例，如下所示:

Since I know that the two separate writes must be initiated by two separate client instances, I can add a further ancestor to the chain, which represents the client instance doing the writing, like so:

Person:9 > Collection:3 > Script:4 > Data:2 > **Client:92** > Record of Tom Cruise
Person:9 > Collection:3 > Script:4 > Data:2 > **Client:37** > Record of Shia La Boef

这种方式的写入将属于不同的实体组(只要Person:9 锚定该组的假设是错误的)，因此始终可以同时执行.AppEngineer/专家可以对此进行权衡吗?(问题 4)

This way the writes will belong to different entity groups (so long as the hypothesis of Person:9 anchoring the group is wrong), and therefore can always be performed concurrently. Can an AppEngineer/expert weigh in on this? (Question 4)

此外，由于我强制限制单独的客户端只能向数据存储区发出串行请求，并且我可以保证单个客户端进行的任何写入永远不会超过每秒 1 次，而不会对性能产生任何影响，因此上述方法，如果它有效，将意味着零性能影响，只要我有足够多的独立客户端(而且，他，有足够的配额)，我就可以进行尽可能多的写入以 HTTP 可以携带它们的速度传输到数据存储.AppEngineer/专家可以对此进行权衡吗?(问题 5)

Further since I enforce the restriction that separate clients can only make serial requests to the datastore, and I can guarantee without any performance impact that any writes made by a single client never need to occur more than 1 time per second, the above method, if it works, will mean there is zero performance impact and as long as I have enough separate Clients (and, he, enough quota) I can make as many writes to the datastore as fast as the HTTP can carry them. Can an AppEngineer/expert weigh in on this? (Question 5)

我在这种分组拆分方法中看到的唯一问题是，查询 Data:2 父项下的 Record 实体现在变得复杂了，因为即使尽管这些记录在语义上是相关的，但它们被不同的客户端分隔.所以为了收集所有记录，我需要先收集所有客户，然后收集所有记录.任何人都可以看到这是否会产生极其可怕的性能影响，执行这种查询您刚刚查询的孩子的所有孩子"查询......?AppEngineer/专家可以对此进行权衡吗?(问题 6)

The only issue I see with this group splitting approach is that querying for the Record entities under the Data:2 parent, is now complicated by the fact that, even though the records are related semantically, they are separated by the different clients. So in order to collect all records, I need to first collect all clients, and then collect all there records. Can anyone see whether this would create a stupendously horrible performance impact, doing this kind of "query all the children of the children you just queried" query...? Can an AppEngineer/expert weigh in on this? (Question 6)

推荐答案

你在这里有一些误解.

首先，文档对实体组的构成非常明确:它是根实体下的一切.

Firstly, the documentation is quite explicit on what constitutes an entity group: it is everything under a root entity.

但是，我不知道您从哪里得知实体组内的写入在某种程度上比外部写入更串行".文档没有说，或暗示它.它唯一说明的是，写入单个实体组的速度不超过每秒 1 次.

However I don't know where you got the idea that writes within an entity group are in some way more "serial" than ones outside. The documentation doesn't say that, or imply it. The only thing that it does say about this is that writes to a single entity group take place at no more than 1 per second.

你的其余问题根本没有意义:向链中添加另一个元素不会改变根实体.

The rest of your questions make no sense at all: adding another element to the chain doesn't change the root entity.

我不确定为什么您首先需要如此深的实体组链.该文档的关于扩展的建议旨在保持实体组的规模较小.如果每个叶实体只会被一个客户端写入，听起来客户端本身应该是根，而路径的其余部分根本不应该是祖先的一部分:也许您可以使用 ReferenceProperty 来引用这些实体中的一个或多个通过其密钥.

I'm not sure why you need such deep entity group chains in the first place. The documentation's advice on scaling is to keep entity groups small. If each leaf entity will only ever be written to by one client, it sounds like the client itself should be the root, and the rest of the path should not be part of the ancestry at all: perhaps you could use a ReferenceProperty to refer to one or more of those entities via its key.

这篇关于NDB HRD 事务，哪个祖先决定实体组?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！