Синхронизация Memcache и Datastore в Google App Engine

Question

Я пишу чат-приложение с помощью Google App Engine. Я бы хотел, чтобы чаты регистрировались. К сожалению, хранилище данных Google App Engine позволяет вам писать только один раз в секунду. Чтобы обойти это ограничение, я думал об использовании memcache для записи буфера. Чтобы не потерять данные, мне нужно периодически выталкивать данные из memcache в хранилище данных.

Есть ли способ запланировать такие задания в Google App. Двигатель? Или я об этом совершенно не так?

Я использую версию API для Python, поэтому предпочтение отдается Python-решению, но я знаю Java достаточно хорошо, чтобы я мог преобразовать Java-решение в Python.

Answer 1

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

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

Так что с выше советы, но дополнительно сделать:

1. Посмотрите на backends. Это всегда - в случаях, когда вы можете агрегировать сообщения чата в памяти (и немедленно/периодически выгружать их в хранилище данных).Когда пользователь запрашивает последние чат-сообщения, у вас уже есть их в памяти и будет обслуживать их мгновенно (экономия времени и затрат по сравнению с использованием Datastore). Обратите внимание, что серверы не на 100% надежны, они могут время от времени снижаться - соответственно настройте поток сообщений чата в хранилище данных.

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

Answer 2

Звучит не так, поскольку вы рискуете потерять данные в memcache.

Вы можете писать в одну группу объектов один раз в секунду.

Вы можете написать отдельные группы объектов очень быстро. Так что это действительно зависит от того, как вы структурируете свои данные. Например, если вы сохраняли весь чат в одном объекте, вы можете писать этот чат только раз в секунду. И вы будете ограничены 1MB.

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

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

Я пытался избежать осколков, но я думаю, что это будет необходимо. Если вы не знакомы с осколками, прочитайте об этом: https://developers.google.com/appengine/articles/sharding_counters

Sharding будет промежуточным звеном между написанием одного объекта для всех сообщений в разговоре, по сравнению с одним объектом на сообщение. Вы случайно разбивали сообщения между несколькими объектами. Например, если вы сохраняете сообщения в 3 сущностях, вы можете написать 5x/sec (я сомневаюсь, что большинство человеческих разговоров будут идти быстрее, чем это).

При извлечении необходимо было бы захватить 3 объекта и объединить сообщения в хронологическом порядке. Это сэкономит вам много средств. Но вам нужно написать код для слияния.

Еще одно преимущество заключается в том, что ваш лимит разговора теперь будет 3 МБ вместо 1 МБ.

Answer 3

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

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

Answer 4

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

Answer 5

Почему бы не использовать задачу по извлечению? Я очень рекомендую это видео Google, что вы недостаточно знакомы с очередями задач. Первые 15 минут будут охватывать информацию о очереди по очереди, которая может применяться к вашей ситуации. Все, что связано с каждым обновлением сообщений, может стать довольно дорогостоящим оператором re: database, и это будет значительно усугубляется, если у вас есть какие-либо индексы. Ссылка на видео: https://www.youtube.com/watch?v=AM0ZPO7-lcE&feature=player_embedded

Я просто установил свой объект чата, когда пользователи инициируют его в on-line-обработчике, передавая идентификатор объекта в чат-партии. Отправляйте сообщение id + в свою очередь, и сериализуйте сообщения в TextProperty субъекта чата. Вы, скорее всего, не планируете вытягивать очередь cron чаще, чем один раз в секунду, чтобы избежать ограничения на обновление вашего объекта. Что самое важное: операционная система базы данных будет значительно уменьшена.