Вычисление уникальных элементов из огромного списка в Google App Engine

#google-app-engine #mapreduce #tipfy

#google-app-engine #mapreduce #подсказка

Вопрос:

У меня есть веб-виджет с 15 000 000 просмотров в месяц, и я регистрирую каждый сеанс. Когда я хочу сгенерировать отчет, я хотел бы знать, сколько существует уникальных IP-адресов. В обычном SQL это было бы легко, поскольку я бы просто сделал:

 SELECT COUNT(*) FROM (SELECT DISTINCT IP FROM SESSIONS)

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

Решение, о котором я думал, состояло в том, чтобы иметь пустую таблицу уникальных IP-адресов, затем выполнить задание MapReduce для просмотра всех объектов сеанса, если IP-адреса объекта нет в таблице, я добавлю его и добавлю единицу к счетчику. Тогда у меня было бы другое задание MapReduce, которое очистило бы таблицу. Было бы это безумием? Если да, то как бы вы это сделали?

Спасибо!

1. Используя эту тактику, которую я объяснил, я, кажется, могу обрабатывать 6000 отслеживаемых сеансов в минуту (пробовал на 60k). Так что это казалось нормальным.

2. К вашему сведению. Использование memcache вместо другой таблицы приводит к результату в 9000 отслеживаемых сеансов в минуту. Но это может быть не так безопасно в использовании.

3. Обычная инструкция SQL должна быть такой: SELECT COUNT(DISTINCT IP) FROM SESSIONS

4. @topchef невозможно в app engine

5. Я сослался на «обычный SQL» вопроса.

Ответ №1:

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

В будущем поддержка reduce сделает это возможным с помощью единого простого mapreduce и без использования ваших собственных транзакций и моделей.

1. Спасибо, Ник! Поскольку вы, похоже, работаете над app engine. Один вопрос, насколько безопасно, по вашему мнению, было бы хранить уникальные IP-адреса в memcache вместо хранилища данных?

2. @Nixarn Это зависит от того, беспокоитесь ли вы о потере некоторых ваших данных.

Ответ №2:

Если время не важно, и вы можете попробовать taskqueue с ограничением задачи 1. В основном вы бы использовали рекурсивную задачу, которая запрашивает пакет записей журнала, пока не достигнет DeadlineExceededError . Затем вы записываете результаты в хранилище данных, и задача сама ставится в очередь с курсором конца запроса / значением ключа последней записи, чтобы начать операцию выборки с того места, где она остановилась в прошлый раз.