Размеры групп объектов Google AppEngine и конечная согласованность

У меня есть приложение корзины покупок, которое содержит пользователей, учетные записи, заказы, строки заказов и т. д.

Многие из моих объектов принадлежат объекту учетной записи, например. учетная запись имеет много заказов, заказ имеет много строк заказа, а строка заказа имеет такое же отношение поставок «многие ко многим». У учетной записи также есть много пользователей, которые могут просматривать дочерние объекты учетной записи.

В документации рекомендуется, чтобы группы сущностей не превышали объем данных одного пользователя: https://developers.google.com/appengine/docs/python/datastore/entities

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

У меня есть два вопроса:

1.) Если я не использую предков, должен ли я просто признать, что если один пользователь редактирует объект, он может не обновляться в течение нескольких секунд?

2.) Если я использую предков, что произойдет, если у учетной записи есть много пользователей, которые создают/редактируют/удаляют все в одной и той же группе объектов в течение дня? Будут ли заблокированы некоторые транзакции?


python python-2.7 google-app-engine app-engine-ndb
person Tim Owens    schedule 02.09.2013    source источник

Ответы (2)


arrow_upward
2
arrow_downward

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

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

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

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

person Daniel Roseman    schedule 02.09.2013
comment
Если группа объектов представляет собой заказ плюс его элементы, когда пользователь редактирует объект заказа, гарантируется ли строгая согласованность на уровне заказа (родительском), а также на дочернем уровне? - person Tim Owens; 02.09.2013
comment
Не совсем уверен, что вы имеете в виду. Как я сказал выше, запрос «заказы для пользователя» не был бы строго последовательным. Но «получить этот заказ и его элементы» будет. - person Daniel Roseman; 02.09.2013
comment
Когда я обновляю заказ, получаю его с помощью get_by_id (ни по какой другой причине, кроме принудительной согласованности) и немедленно перенаправляю на страницу, отображающую заказы, я получаю стабильные результаты, которых раньше не было. В дополнение к вашим двум предложениям, это рекомендуемый подход? - person Tim Owens; 02.09.2013

arrow_upward
0
arrow_downward

  1. Да, но окончательная согласованность влияет только на запросы. Если вы отредактируете данные, а затем ПОЛУЧИТЕ их, изменения будут видны.

  2. Нет, в документах не упоминаются ограничения по размеру или блокировка транзакций для групп сущностей. Применяемое ограничение — пропускная способность записи на группу сущностей: в документах указано ограничение в 1 запись в секунду на группу сущностей (на практике я вижу около 5 операций записи в секунду). Но это не должно быть проблемой, если вы разрабатываете свою группу сущностей для каждого пользователя.

person Peter Knego    schedule 02.09.2013