NDB HRD транзакции, какой предок определяет группу объектов?

Question

Это самый близкий или самый дальний родительский родственник записываемого объекта, который определяет группу объектов? (Вопрос 1) Ибо, если у меня есть,

два одновременных запроса на запись двух разных сущностей, в этом примере оба имеют непосредственный родительский объект Data (с ключом '2') и имеют последующих предков:

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. Какой правильный определитель группы сущностей, Персона: 9 или Данные:2? Также, если существует два вида объектов, произошедших от Данных:2, скажем, "Запись" и "Схема", будут ли все объекты "Запись" и "Схема" принадлежать к одной и той же группе объектов, привязанные к данным "2", или, в силу своего различного вида, принадлежат отдельные группы лиц? (Вопрос 2)

Между прочим, если именно Person:9 определяет группу сущностей, а разные виды под родителем не образуют разные группы сущностей под этим родителем, то все, что происходит от Person:9 - это одна и та же группа сущностей, и ее нужно записать. в сериале ужас

Так как в этом примере я выполняю эти записи одного и того же вида сущности в одну и ту же группу сущностей одновременно, они будут применяться последовательно и, следовательно, потребуют "удвоенного времени", чем если бы они могли применяться одновременно.

Какое хорошее решение для этого "удвоения" времени? (Вопрос 3 - необязательно!)

Я думал о следующем:

Поскольку я знаю, что две отдельные записи должны инициироваться двумя отдельными экземплярами клиента, я могу добавить еще одного предка в цепочку, которая представляет экземпляр клиента, выполняющий запись, примерно так:

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)

Кроме того, поскольку я применяю ограничение, согласно которому отдельные клиенты могут только отправлять последовательные запросы к хранилищу данных, и я могу гарантировать без какого-либо влияния на производительность, что любые записи, сделанные одним клиентом, никогда не должны выполняться более 1 раза в секунду, описанный выше метод, если это будет работать, это будет означать, что производительность будет нулевой, и до тех пор, пока у меня будет достаточно отдельных Клиентов (а у него достаточно квоты), я могу делать столько же записей в хранилище данных, сколько и HTTP, чтобы их перенести. Может ли AppEngineer/ эксперт оценить это? (Вопрос 5)

Единственная проблема, которую я вижу при таком подходе группового разделения, заключается в том, что запрос сущностей Record в родительском элементе Data: 2 теперь осложняется тем фактом, что, хотя записи связаны семантически, они разделены разными клиентами. Поэтому, чтобы собрать все записи, мне нужно сначала собрать всех клиентов, а затем собрать все имеющиеся записи. Может кто-нибудь увидеть, не приведет ли это к невероятно ужасному влиянию на производительность, выполнив такой запрос типа "запросить всех дочерних элементов только что запрошенных вами"...? Может ли AppEngineer/ эксперт оценить это? (Вопрос 6)

Answer 1

У вас есть некоторые заблуждения здесь.

Во-первых, в документации совершенно ясно говорится о том, что составляет группу объектов: это все, что находится под корневым объектом.

Однако я не знаю, откуда у вас идея, что записи внутри группы сущностей в некотором роде более "последовательны", чем те, что снаружи. Документация не говорит об этом, или подразумевает это. Единственное, что он говорит об этом, - это то, что запись в одну группу сущностей происходит со скоростью не более 1 в секунду.

Остальные ваши вопросы вообще не имеют смысла: добавление еще одного элемента в цепочку не меняет корневую сущность.

Я не уверен, зачем вам нужны такие глубокие цепочки групп сущностей. В документации по масштабированию рекомендуется сохранять небольшие группы объектов. Если каждая конечная сущность будет когда-либо записана только одним клиентом, это звучит так, как будто сам клиент должен быть корнем, а остальная часть пути вообще не должна быть частью предка: возможно, вы могли бы использовать ReferenceProperty для ссылки на один или несколько из этих объектов через его ключ.