Юрий Заяц

Шесть банальных выводов из домашнего хайлоад-проекта

16 ноября 2015 г.

В 2004 году я написал курсовую работу о том как подмешивать данные в результаты поисковой выдачи, чтобы по запросу “Opera” не только про красноглазый браузер показывало, но и про Сиднейскую филармонию. В 2006 году Google оформил патент, в котором точь в точь моя работа. Меня, конечно же, никто не предупредил.

Я решил взять реванш и, не предупредив Google, сделать поискового паука.

Spyify server

Цель была сугубо меркантильная: создать паука, собирающего идентификаторы Adsense, Google Analytics, LI и, узнать побольше про денежные сетки сайтов и про то, какие темы WordPress самые популярные. Ну и заодно про распределение языков.

Если кто не знает, идентификаторы Adsense одинаковы для всех сайтов одного владельца, что помогает выявлять «Типа СДЛ», а код LI выдает русских, несмотря на выставленную локаль En_en. Для конкретного сайта идентификаторы можно посмотреть на Sameid.net или Spyonweb.com, но по группам не показывает никто. Уж очень ценная информация. (на момент написания этой статьи уже показывает Domainiq за 50 долларов в месяц)

Технические моменты, которые хотел бы прояснить для себя: многопоточность, highload и понять как ведет себя mysql с базой 100 гб.

Для тестов были куплены за $3000 две новые машины, одна на 4 ядра и 64 гб памяти, вторая на 8 ядер и 16 гб. Чтобы тестировать соотношение память-процессор и заодно несколько инстансов паука запускать. И еще базу в памяти хранить. Поэтому ECC.

Почему spyify.com

Я давно хотел себе домен sherloque.com. Просто чтобы был. Домен даже с аукциона продавался, но меня жаба душила за $8800 его покупать. А тут слово в голове всплыло – spyify. Зашел я к доменному брокеру, узнал что spyify.com через два дня освобождается и купил. Сэкономил.

Одна проблема – исходящий канал. 512 кб из моего дома. Поэтому на сервер база попадает как в эпоху BBS. Snail Mail. Я беру внешний диск и иду к другу. Потом я вспоминаю как разворачивать многотомные архивы. Это же 2015 год, нельзя просто так взять и написать unzip file.zip -d destination_folder. Потом еще сутки база заливается в mysql.

Нельзя написать универсального паука

Скачать заглавную страницу, найти ссылки, скачать страницу для каждой найденной ссылки, повторить?

Не, рекурсия не пройдет.

Интернет разный. На 98 процентов он состоит из вордпресса и больших парней, держащих собственный UX-отдел, но бывают и отдельные экземпляры, достойные кунсткамеры. Я встречал корневую страницу, на которой размещено 4000 ссылок. Каждая из этих ссылок ведет на страницу с еще 4000 ссылок. Это живой сайт, с живыми документами, имеющими определенный смысл. За ним стоит некто с той же болезнью, что и у Джона Нэша.

Нельзя ограничиться только количеством страниц (хотя в итоге я так и сделал для поиска новых доменов) или только уровнями вложенности.

Паук – это набор исключений: правила сканирования доменов, правила сканирования поддоменов. В Википедии нам нужно залезть как можно глубже поддомена конкретного языка, чтобы собрать побольше ссылок. При этом рекламные идентификаторы можно и не искать. В Блоггере нам достаточно одной заглавной страницы поддомена. Твиттер, фейсбук, web.archive и прочий Top-1000 мы пропускаем.

Иногда самым простым решением будет самое простое решение

Простое и совершенно неверное с точки зрения архитектуры.

Представьте себе список доменов верхнего уровня. *.ru, *.com, *.by и т.д. Среди них встречаются и посложнее, типа *.co.uk. Или японская пачка из пары десятков разных *.hokkaido.jp *.aomori.jp *.iwate.jp *.miyagi.jp *.akita.jp *.yamagata.jp *.fukushima.jp *.ibaraki.jp.

В определенный момент возникает задача сканировать Блоггер, т.к. в нем содержится множество разных идентификаторов Adsense. По одному на блог. Самым простым вариантом будет добавить .blogger.com как домен верхнего уровня, наплевав на сам домен. Если сделать по другому, придется потратить сначала время на написание исключений, потом запустить поток паука, через пару дней осознать, что Блоггер большой; что нам нужно еще и сохранять промежуточные результаты потока, написать сохранялку, ну и все заверте…

Канал важнее процессорных мощностей

По крайней мере пока вы не считаете pagerank.

10 мегабитного канала хватает для того, чтобы качать в 200 потоков шесть миллионов страниц в день, и еще остается место для торрентов. Процессор при этом занят на 15-20 процентов.
Ну а память вообще не важна, пока ее у вас 16 гб. 16 гб хватит всем. Или 32, если добавить потоков.

Верхние 30 миллионов сайтов сильно связаны

Чтобы их найти, понадобилось две недели работы инстанса с глубиной просмотра 10 страниц. Для затравки использовался единственный сайт – Википедия. Через 2 недели паук остановился – ссылки закончились.
Все остальные сайты – не очень сильно связаны. Для того чтобы пройти очередные 5 миллионов, понадобилось полгода работы инстанса с глубиной в 100 страниц – в шесть раз медленнее.

Mysql отлично справляется с базой в 100 гб

Конечно, все нужно кешировать. Views для фронтенда кешируются в реальные таблицы, по реальным таблицам строятся индексы и дополнительно развертываются данные. Поля DATETIME превращаются в DATE и TIME, а иначе глупый запрос «А сколько же мы сайтов сегодня просканировали» с WHERE date(threadLaunch) превращается в минуту ожидания.

Сайтов, сделанных под Адсенс, много

Их реально много. Миллионы. Настолько много, что пришлось добавить таблицы с рейтингами Alexa, чтобы отсеять сайты без трафика. Теперь моя коллекция датасетов содержит еще и ежемесячные дампы Alexa.

Spyify clien

Подпишись на RSS и Кодирующие кролики расскажут тебе много интересных историй.