google app engine - рекомендации по проектированию задач cron

Question

Я занимаюсь разработкой программного обеспечения с использованием Google App Engine.

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

В обычном мире реляционных БД я буду создавать задания БД, которые будут вставлять новые сводные записи.

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

Я хотел бы знать, каков наилучший способ добиться этого в Google App Engine. Я знаю, что есть сервис Cron, но позволяет ли он нам выполнять задания, которые будут вставлять / обновлять тысячи записей?

Answer 1

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

Мое предложение будет следующим: добавьте поле 'последний снимок' и создайте подкласс для функции put () вашей модели (при условии, что вы используете Python; то же самое возможно в Java, но я не знаю синтаксис ), так что всякий раз, когда вы обновляете запись, она проверяет, прошло ли больше часа с момента последнего снимка, и, если да, создает и записывает запись снимка.

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

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

Answer 2

Рассматривали ли вы вместо этого remote api ? Таким образом, вы можете получить оболочку для вашего хранилища данных и избежать таймаутов. Класс Mapper, который они демонстрируют в этой ссылке, весьма полезен, и я успешно использовал его для выполнения пакетных операций над ~ 1500 объектами.

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

Answer 3

Я бы использовал комбинацию заданий Cron и метод циклического извлечения URL-адреса, подробно описанный здесь: http://stage.vambenepe.com/archives/549. Таким образом, вы можете перехватить время ожидания и начать другой запрос.

Чтобы подвести итог статьи, задание cron вызывает ваш начальный процесс, вы ловите ошибку тайм-аута и снова вызываете процесс, маскируемый как второй URL. Вы должны пропинговать между двумя URL-адресами, чтобы двигатель приложения не думал, что вы попали в случайный цикл. Вы также должны быть осторожны, чтобы не зацикливаться бесконечно. Убедитесь, что для вашего цикла обновления есть конечное состояние, так как это очень быстро поместит вас в ваши квоты, если оно никогда не закончится.