Насколько большой может быть полезная нагрузка задачи appengine?

Я использую новую экспериментальную очередь задач для java appengine и пытаюсь создать задачи, которые собирают статистику в моем хранилище данных. Я пытаюсь подсчитать количество УНИКАЛЬНЫХ значений во всех сущностях (определенного типа) в моем хранилище данных. Более конкретно, скажем, объект типа X имеет поле A. Я хочу подсчитать ЧИСЛО уникальных значений A в моем хранилище данных.

Мой текущий подход заключается в создании задачи, которая запрашивает первые 10 объектов типа X, создавая хэш-таблицу для хранения уникальных значений A, а затем передавая эту хэш-таблицу следующей задаче в качестве полезной нагрузки. Эта следующая задача будет подсчитывать следующие 10 объектов и так далее, и так далее, пока я не пройду через все объекты. Во время выполнения последней задачи я подсчитаю количество ключей в моей хеш-таблице (которая все время передавалась от задачи к задаче), чтобы найти общее количество уникальных значений A.

Это работает для небольшого количества сущностей в моем хранилище данных. Но я беспокоюсь, что эта хеш-таблица станет слишком большой, когда у меня будет много уникальных значений. Каков максимально допустимый размер полезной нагрузки задачи appengine?????

Можете ли вы предложить какие-либо альтернативные подходы?

Спасибо.


java google-app-engine scheduled-tasks payload
person aloo    schedule 22.12.2009    source источник

Ответы (3)


arrow_upward
14
arrow_downward

Согласно документам, максимальный размер объекта задачи составляет 100 КБ.

person Jonathan Feinberg    schedule 22.12.2009
comment
размер объекта = размер полезной нагрузки? - person aloo; 22.12.2009
comment
Вам нужно как-то сериализовать свой объект. Это полезная нагрузка. Если вы ожидаете, что это будет более 10 КБ, вы можете использовать прием отложенной библиотеки для сериализации ключа объекта хранилища данных, содержащего фактические данные. - person Nick Johnson; 24.12.2009
comment
Обновлен URL-адрес страницы квот: cloud.google.com/appengine/docs/quotas#Task_Queue< /а> - person Nathan; 13.07.2016

arrow_upward
1
arrow_downward

«Можете ли вы предложить какие-либо альтернативные подходы?».

Создайте сущность для каждого уникального значения, создав ключ на основе значения и используя Model.get_or_insert. Затем Query.count создайте объекты партиями по 1000 (или столько, сколько вы сможете сосчитать до истечения времени ожидания вашего запроса - более 10), используя обычные приемы пейджинга.

Или используйте код, аналогичный приведенному в документации для get_or_insert, чтобы вести подсчет по ходу работы — транзакции App Engine могут выполняться более одного раза, поэтому счетчик memcached, увеличивающийся в транзакции, будет ненадежным. Однако в этом может быть какая-то хитрость, или вы можете оставить счетчик в хранилище данных при условии, что вы не делаете ничего слишком неприятного с родительскими объектами.

person Steve Jessop    schedule 22.12.2009

arrow_upward
0
arrow_downward

Это может быть слишком поздно, но, возможно, это может быть полезно. Во-первых, каждый раз, когда у вас есть отдаленный шанс последовательно пройтись по набору сущностей, предложите использовать индексированное поле auto_update date_created или date_modified. С этого момента вы можете создать модель с TextProperty для хранения вашей хэш-таблицы с помощью json.dumps(). Все, что вам нужно сделать, это передать дату последней обработки и идентификатор модели для объекта хеш-таблицы. Сделайте запрос с date_created позже последней даты, json_load() TextProperty и соберите следующие 10 записей. Может быть немного сложнее (например, обрабатывать коллизии date_created, используя переданные параметры и немного другой подход к запросу). Добавьте 1-секундный обратный отсчет к следующей задаче, чтобы избежать проблем со слишком быстрым обновлением объекта хеш-таблицы. HTH, -стев

person stevep    schedule 22.11.2013