Группы сущностей механизма приложений Google

Question

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

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

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

Если единственная цель групп сущностей состоит в том, чтобы сделать транзакцию между сущностями возможной, почему я должен использовать более 1 уровня иерархии (что я получаю от связи Корень -> Внук)?

Answer 1

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

Есть еще вопросы об Ancestor Queries в Программирование Google App Engine

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

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

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

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

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

Answer 2

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

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

Answer 3

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

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

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