Облачные конечные точки Google с Android — ответ на кэширование?

Я использую Google Cloud Endpoints (Java) в качестве серверной части для приложения Android. Данные на сервере хранятся в Datastore.

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

Можете ли вы сказать мне, что может вызвать эту проблему? Есть ли какое-то кэширование ответов в библиотеке Cloud Endpoints? Или кэширование в хранилище данных?

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

Большое спасибо.


person Jakub Kinst    schedule 02.09.2014    source источник


Ответы (2)


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

Предположим, у меня есть объект «Post» и объект «CommentForPost». Пользователи могут создавать множество записей CommentForPost для каждой записи Post. Логически, CommentForPost является потомком Post, но если вы не сделаете Post предком всех записей CommentForPost, немедленная согласованность не гарантируется. Если пользователь А создает комментарий, а затем запрашивает его, он может не сразу увидеть запись.

С другой стороны, если вы сделаете сущность Post родительской для всех записей CommentForPost, вы гарантируете немедленную согласованность, поскольку они сохраняются как одна EntityGroup. Если пользователь A создает запись и немедленно запрашивает ее (используя ключ Post в качестве предка), то он наверняка получит точные данные обратно.

Ограничение здесь в том, что вы сможете создавать только одну запись CommentForPost в секунду. Это где дать и взять лежит. Если вам нужно много обновлений за короткие промежутки времени, вы не можете гарантировать согласованность (например, 100 пользователей одновременно добавляют записи CommentForPost). Если вы хотите гарантировать согласованность, вы не можете иметь много обновлений в течение короткого периода времени.

Есть смысл?

person xsee    schedule 03.09.2014
comment
Большое спасибо! Думаю, я не уделял должного внимания документам. Теперь это имеет смысл. Знаете ли вы, могу ли я изменить родительский объект для существующих данных? - person Jakub Kinst; 04.09.2014

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

Query query = new Query("Greeting", guestbookKey).setAncestor(guestbookKey);

Вы не можете полагаться на задержку для достижения согласованности, поскольку она зависит от репликации между центрами обработки данных, и количество времени, которое требуется для этого, никогда не бывает согласованным :)

person Adam    schedule 02.09.2014
comment
Но как передать ключ между HTTP-запросами? - person Jakub Kinst; 03.09.2014