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

Question

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

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

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

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

Спасибо.

Answer 1

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

Answer 2

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

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

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

Answer 3

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