Самый оптимизированный способ хранения состояний сканера?

В настоящее время я пишу поисковый робот (используя фреймворк Python scrapy).
Недавно мне пришлось реализовать система паузы/возобновления.
Решение, которое я реализовал, является самым простым и, по сути, сохраняет ссылки, когда они запланированы, и помечает их как «обработанные», как только они на самом деле.
Таким образом, я могу извлекать эти ссылки (очевидно, хранится немного больше, чем просто URL-адрес, значение глубины, домен, к которому принадлежит ссылка, и т. д.) при возобновлении паука, и пока все работает хорошо.

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

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

На данный момент он должен быть в состоянии обрабатывать сканирование нескольких десятков доменов, что означает хранение нескольких тысяч ссылок в секунду...

Заранее спасибо за предложения


person Sylvain    schedule 13.11.2009    source источник


Ответы (2)


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

Ваше конкретное приложение может быть дополнительно оптимизировано, поскольку оно не обязательно требует 100% надежности — если вы пропустите запись нескольких записей из-за внезапного сбоя, ну что ж, вы просто просканируете их снова. Таким образом, ваш лог-файл можно буферизовать, и его не нужно навязчиво синхронизировать с помощью fsync.

Я полагаю, что структура поиска также удобно уместилась бы в памяти (если бы это было только для нескольких десятков сайтов, вы, вероятно, могли бы просто сохранить набор со всеми их URL-адресами, не нужны фильтры Блума или что-то причудливое). возможно, придется хранить в памяти только набор последних записей и периодически сбрасывать этот набор на диск (например, объединяя все записи в файл Berkeley DB); но я не буду вдаваться в мучительные подробности об этих параметрах, так как не похоже, что они вам потребуются.

person Alex Martelli    schedule 13.11.2009
comment
десятки сайтов сканировались параллельно, но мне нужно будет отслеживать каждое сканирование, выполненное в прошлом, я думаю - person Sylvain; 13.11.2009
comment
Кроме того, при последовательной записи в файл, как мне «отметить» ссылку как загруженную? - person Sylvain; 13.11.2009
comment
@Sylvain, тогда вам определенно нужно периодически сбрасывать резервную копию в памяти set в более постоянную форму поиска - и Berkeley DB может или не может плавно масштабироваться до миллионов или миллиардов ... вам нужно будет провести сравнительный анализ, но Я подозреваю, что PostgreSQL (или какое-то амбициозное нереляционное хранилище ключей/значений, но у меня мало опыта работы с ними, кроме собственной Bigtable от Google) действительно будет вашим лучшим подходом, если ваш масштаб достаточно гигантский. Ключевым моментом является то, что вам не нужно постоянно обновлять эту БД — используйте память и журналы, чтобы обновлять БД только время от времени! - person Alex Martelli; 13.11.2009
comment
@Sylvain, вы добавляете в свои файлы журналов такие строки, как «TODO abc» или «DONE abc' (или использовать более короткие глаголы, чем 'TODO ' и 'DONE ', конечно;-). - person Alex Martelli; 13.11.2009

На PyCon 2009 был доклад, который может показаться вам интересным, Точное восстановление перезапуск для приложений анализа данных Билла Гриббла.

Другим быстрым способом сохранения состояния приложения может быть использование pickle для сериализации состояния приложения. на диск.

person John Paulett    schedule 13.11.2009
comment
Я почти уверен, что pickle нельзя использовать из-за некоторых объектов (из скрученной библиотеки). Спасибо за ссылку, постараюсь в ближайшее время посмотреть. - person Sylvain; 13.11.2009
comment
Наконец нашел время, чтобы посмотреть на разговор. Было интересно. Однако я думаю, что это немного выходит за рамки моих простых потребностей :-) - person Sylvain; 16.11.2009