Структурирование Google App Engine для строгой согласованности

Я хочу повторить этот план, который у меня есть для достижения строгой согласованности с моей структурой GAE. На данный момент вот что у меня есть (это очень просто, обещаю):

У вас есть модель класса (класс означает класс, а не класс программирования) и модель назначения, а также модель пользователя. Теперь класс имеет целочисленное свойство списка, называемое memberIds, которое представляет собой индексированный список идентификаторов пользователей. Класс также имеет строковый список идентификаторов назначений.

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

Я хочу получить новые назначения для пользователя. Я делаю запрос для всех классов, где memberId = currentUserId. Каждый класс, который я возвращаю, имеет список идентификаторов заданий. Я использую эти идентификаторы для получения соответствующих назначений по ключу. После нескольких месяцев работы с этой моделью данных я только что понял, что не могу добиться строгой согласованности с этим (для части запроса класса).

Если пользователь А публикует задание (которое, следовательно, обновляет ClassA), пользователь B, который проверяет новые задания на долю секунды позже, может еще не увидеть обновленные изменения в ClassA (правильно?).

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

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

  • Получить соответствующий объект класса
  • добавить идентификатор задания в класс
  • получить идентификаторы всех членов этого класса
  • получить всех пользователей, которые являются членами, по ключам
  • сущность пользователя имеет список классов, членом которых является пользователь. (LocalStructuredProperty, что-то вроде словаря: {"classId" : "242", "hasNewAssignment" : "Yes"} ). Мы помечаем этот класс как hasNewAssignment = YES
  • Теперь, когда пользователь хочет получить новые назначения, вместо того, чтобы запрашивать группы, у которых есть новое назначение и членом которых я являюсь, я проверяю список объектов пользователя для классов и проверяю, какие классы имеют новые назначения. .
  • Я извлекаю эти классы по ключу (до сих пор строго согласованно, верно?)
  • Я проверяю список назначений классов и получаю все назначения по ключу.

Так что на протяжении всего этого процесса я никогда не задавал вопросов. Все результаты должны быть строго согласованы, верно? Это хорошее решение? Я слишком усложняю вещи? Увеличиваются ли мои затраты на чтение/запись с этим? Что вы думаете?


person Snowman    schedule 22.10.2012    source источник


Ответы (2)


Запросы не являются строго последовательными. Gets строго согласованы.

Я думаю, вы поступили правильно:

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

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

person Peter Knego    schedule 22.10.2012

Я думаю, что использование запросов предков - лучшее решение.

  • Установите предка объектов назначения в качестве класса, которому назначено назначение
  • Установите предка объекта Student в качестве класса, к которому принадлежит студент.

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

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

person Binu Jasim    schedule 17.02.2015