Обработка веб-канала несколько раз в день - PullRequest
Новая
       25

Обработка веб-канала несколько раз в день

0 голосов
/ 15 февраля 2009

Хорошо, вот вкратце сделка: я паутину в сети (все виды данных, блоги / новости / форумы), как это появляется в Интернете. Затем я обрабатываю этот канал и делаю анализ обработанных данных. Паук не имеет большого значения. Я могу получить это в значительной степени в режиме реального времени, так как интернет получает новые данные. Обработка является узким местом, она включает в себя некоторые вычислительно сложные алгоритмы.

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

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

1 Ответ

1 голос
/ 15 февраля 2009

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

Моя рекомендация состоит в том, чтобы реализовать очередь, используя клиентскую / SQL-базу данных SQL. MySQL отлично подойдет для этой цели.

Цели проектирования

  • Не позволяйте паукам слишком сильно опережать процессоры
  • Обеспечить баланс сил между пауками и процессорами (каждый занят)
  • Сохраняйте данные как можно более свежими
  • Масштабирование и увеличение по мере необходимости

Очередь: Создайте очередь для хранения данных от пауков до их обработки. Это можно сделать несколькими способами, но это не звучит так, будто IO - это ваше узкое место.

Простым подходом было бы иметь таблицу SQL с таким макетом: 

TABLE Queue
    Queue_ID int unsigned not null auto_increment primary key
    CreateDate datetime not null
    Status enum ('New', 'Processing')
    Data blob not null

# pseudo code
function get_from_queue()
    # in SQL
    START TRANSACTION;
    SELECT Queue_ID, Data FROM Queue WHERE Status = 'New' LIMIT 1 FOR UPDATE;
    UPDATE Queue SET Status = 'Processing' WHERE Queue_ID = (from above)
    COMMIT
    # end sql

    return Data# or false in the case of no records found

# pseudo code
function count_from_queue()
    # in SQL
    SELECT COUNT(*) FROM Queue WHERE Status = 'New'
    # end sql
    return (the count)

Паук:

Итак, у вас есть несколько процессов паука .. Каждый из них говорит: 

if count_from_queue() < 10:
    # do the spider thing
    # save it in the queue
else:
    # sleep awhile

repeat

Таким образом, каждый паук будет либо отдыхать , либо паук . Решение (в данном случае) основано на том, что для обработки осталось менее 10 ожидающих пунктов. Вы бы настроили это на ваши цели.

Процессор

Итак, у вас есть несколько процессорных процессов .. Каждый из них говорит: 

Data = get_from_queue()
if Data:
    # process it
    # remove it from the queue
else:
    # sleep awhile

repeat

Таким образом, каждый процессор будет либо отдыхать , либо обрабатывать .

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

...