NDB HRD交易，哪个祖先决定实体组？ [英] NDB HRD transactions, which ancestor determines the entity group?
问题描述
它是正在编写的实体的最接近还是最远的亲属亲属，它决定了实体组？ （问题1 ）如果我有，
两个同时写入两个不同实体的请求，在这个例子中，数据实体（带有键'2'），并具有后续的祖先：
Person：9>收藏品：3>脚本：4>数据：2>汤姆克鲁斯的纪录
人物：9>收藏品：3>脚本：4>数据：2> Shia La Boef的记录
在任何一种情况下，它们都属于同一个实体组，个人：9，或实体数据：2。哪个是实体组的正确确定者，Person：9或Data：2？同样，如果存在来自Data：2的两种实体，比如说Record和Scheme，那么所有Record和Scheme实体都属于同一个实体组，由Data：2锚定，或者由于属于不同类型，属于不同的实体组？ （问题2 ）
顺便提一句，如果是Person：9，它确定了实体组，不是在该父项下形成不同的实体组，然后
由于在这个例子中，我正在同时对相同的实体组写入相同类型的实体，因此它们将被串行应用，因此采用双倍时间，而不是如果他们可以同时申请。
这种倍增时间的最佳解决方案是什么？ （问题3 - 可选！）
我想到了以下内容：
因为我知道两个独立的写入操作必须由两个独立的客户端实例启动，所以我可以在链中添加一个进一步的祖先，它表示正在写入的客户端实例，如下所示：
Person：9>收藏品：3>脚本：4>数据：2> **客户：92 **>汤姆克鲁斯的纪录
人物：9>收藏品：3>脚本：4>数据：2> **客户：37 **> Shia La Boef的记录
通过这种方式写入属于不同的实体组（只要假设人：9锚定组是错误的），因此可以总是同时执行。 AppEngineer / expert可以衡量这个吗？ （问题4 ）
此外，由于我强制实行限制，即单独的客户端只能向数据存储区发出串行请求，性能的影响，即单个客户端所做的任何写入都不会每秒发生超过1次，上述方法（如果有效）将意味着对性能产生零影响，并且只要我拥有足够的性能单独的客户端（以及他足够的配额），我可以尽可能多地向数据存储区写入数据，这与HTTP可以承载的速度一样快。 AppEngineer / expert可以衡量这个吗？ （问题5 ）
我通过 组拆分 方法看到的唯一问题是查询Data：2父项下的Record实体，现在很复杂，即使记录在语义上相关，它们被不同客户端分隔。因此，为了收集所有记录，我需要先收集所有客户，然后收集所有记录。任何人都可以看到这是否会造成巨大的可怕的性能影响，做这种查询你刚才查询的孩子的所有孩子查询...？ AppEngineer / expert可以衡量这个吗？ （问题6 ）
您有一些误解。
首先，文档对实体组的构成非常明确：它是根实体下的 。
但是我不知道你从哪里得到这样的想法，即在一个实体组中写入的内容在某种程度上比外部的更串行。文档不会这么说，或者暗示它。它唯一说的就是写入单个实体组的速度不超过每秒1次。
其他问题没有意义完全可以：向链中添加另一个元素不会改变根实体。
我不确定为什么您首先需要这样深的实体组链。文档的缩放建议是保持实体组较小。如果每个叶子实体只能由一个客户端写入，那么听起来客户端本身应该是根，而其他路径根本不应该是祖先的一部分：或许您可以使用ReferenceProperty来引用一个或多个实体通过它的关键字。
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,
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
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)
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.
What is a good solution for this 'doubling' of time taken? (Question 3 -- optional!)
I have thought of the following:
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
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)
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)
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)
You have some misconceptions here.
Firstly, the documentation is quite explicit on what constitutes an entity group: it is everything under a root entity.
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.
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屋！
