Группы объекта механизма приложения Google
Насколько я понимаю из учебного руководства по механизму приложения, группы объекта существуют только в целях транзакций:
"Только используйте группы объекта, когда они будут необходимы для транзакций" (из учебного руководства)
Определение того, чтобы быть в той же группе объекта должно иметь тот же корень.. В этом случае, каково использование наличия больше чем 1 уровня иерархии? Таким образом, почему должен я использовать "-> B-> C" (A, корень, B его сын, C его внук) вместо "-> B;-> C"? (A, B и C находятся все еще в той же группе объекта, так как A является их корнем).
Если единственная цель групп объекта в сделать транзакцию возможной между объектами, почему я должен использовать больше чем 1 уровень иерархии (что я зарабатываю от Корня-> связь Внука)?
2 ответа
] Когда вы делаете запросы, вы можете использовать [] ancestor()[], чтобы ограничить запрос дочерними процессами определенной сущности - в вашем примере вы могли искать только потомков []B[], что вы не могли бы сделать, если бы все они были на верхнем уровне. [
]О запросах предков можно узнать больше в []Программирование Google App Engine[][
] [] В доке []Ключи и группы сущностей[] также сказано об этом: [
] [] [] []Отношения групп сущностей говорят App Engine хранить несколько сущностей в одной части распределенной сети ... Все сущности в группе хранятся в тот же самый узел хранилища данных[
] [
]редактирование: В том же самом документе перечислены некоторые из причин, по которым вы не хотите, чтобы группы сущностей росли слишком большими:[
] [] [] []Чем больше групп сущностей у вас будет приложение имеет, то есть, чем больше корень есть - тем более эффективное хранилище данных может распределить группы организаций по узлы хранилища данных. Лучшее распределение повышает эффективность создания и обновление данных. Также, несколько пользователи, пытающиеся обновить сущности одна и та же группа организаций одновременно заставит некоторых пользователей повторить попытку сделки, что может привести к тому, что некоторые из них не совершить изменений. Не ставьте все организаций, подавших заявку на один корень.[
] [
]Любая транзакция по организации в группе приведет к неудаче любой другой записи в ту же самую группу организаций. Если у вас большая группа сущностей с большим количеством записей, то это вызывает много споров, и ваше приложение должно обрабатывать ожидаемые ошибки при записи. [] Избежать соперничества в хранилище данных [] более подробно рассматривает стратегии, которые вы можете использовать для минимизации соперничества [
].] Когда вы храните A -> B -> C, у A много B, а у B много C. Когда вы храните A -> B и A -> C, A имеет много B и много C. Другими словами, C не принадлежит ни одной B.[
]. [] Какая структура вы используете, зависит от данных, которые вы храните. [
] [] При использовании множества доступа на запись, вам, возможно, придётся делать неинтуитивно понятные вещи с вашими сущностными группами, смотрите [] Sharding Counters[] для примера:[
].