Группы сущностей Google для приложений

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

"Используйте только группы объектов, когда они необходимы для транзакций" (из учебника)

Определение того, что в одной группе сущностей должно иметь один и тот же корень. В этом случае, в чем состоит использование более одного уровня иерархии? То есть, почему я должен использовать "A → B → C" (A - корень, B - его сын, C его внук) вместо "A → B; A → C"? (A, B и C все еще находятся в одной группе сущностей, поскольку A является их корнем).

Если единственная цель групп объектов в том, чтобы сделать транзакцию возможной между объектами, почему я должен использовать более одного уровня иерархии (что я могу получить от Root → Grandson linkage)?

Ответы

Ответ 1

Когда вы выполняете запросы, вы можете использовать ancestor(), чтобы ограничить запрос дочерними элементами определенного объекта - в вашем примере, вы можете искать только потомков B, которые вы не могли бы сделать, если бы они были на верхнем уровне.

Более подробно о запросах предков в Программирование Google App Engine

Группы ключей и сущностей doc также говорит, что:

Связи группы объектов сообщают App Engine хранить несколько объектов в одной и той же части распределенной сети... Все объекты в группе хранятся в то же хранилище данных node

edit: в том же документе также перечислены некоторые причины, по которым вы не хотите, чтобы ваши группы лиц становились слишком большими:

Чем больше сущностей группирует ваши приложение - то есть, чем больше root сущности, тем больше эффективно хранилище данных может распределять группы сущностей через узлы хранилища данных. Лучшее распространение улучшает производительность создания и обновление данных. Кроме того, несколько пользователи, пытающиеся обновить объекты в одна и та же группа лиц одновременно приведет к тому, что некоторые пользователи транзакций, возможно, не вносить изменения. Не ставьте все заявлений субъектов один корень.

Любая транзакция на объекте в Группе приведет к сбою любой другой записи в ту же группу лиц. Если у вас большая группа лиц с большим количеством записей, это вызывает много конфликтов, и ваше приложение затем должно обрабатывать ожидаемые неудачи записи. Предотвращение конкуренции с хранилищем данных более подробно описывает стратегии, которые можно использовать для минимизации конкуренции.

Ответ 2

Фактически, транзакция является побочным эффектом групп объектов. Поскольку строки группы объектов являются совместно расположенными, транзакции на них возможны вообще.

Я бы даже дошел до утверждения, что группы сущностей являются внутренним свойством хранилища данных, что делает его похожим на иерархические базы данных.

Ответ 3

Когда вы храните A → B → C, A имеет много Bs, а B имеет много Cs. Когда вы храните A → B и A → C, A имеет много Bs и много Cs. Другими словами, C не принадлежит ни одному B.

Какая структура, которую вы используете, действительно зависит от данных, которые вы храните.

При использовании большого количества запросов на запись вам может понадобиться сделать неинтуитивные вещи для ваших групп объектов, см. Sharding Counters для примера: