Приветствую всех ребята.
Постараюсь описать как можно короче и как можно понятнее.
Нужно написать полноценный парсер, который будет собирать информацию с сайтов по указанным юзерами категориям.
Простой пример 1 - Нужно с сайта toster.ru собрать информацию пользователей с ником на первую букву ( А ) сколько вопросов было решено этими юзерами, процент, сколько сообщений они оставили под какими тегами больше всего решенных вопросов и т.д.
Простой пример 2 - Нужно с сайта фриланс собрать среднюю стоимость работы в час php разработчика по гео РФ или Украина. Процент положительных и отрицательных отзывов и т.д.
Собственно вопрос стоит в реализации. На каком языке будет практичнее пилить данный скрипт?
Где то, слышал что подобные затеи хорошо реализуются на ASP.NET собственно вопрос к знающим, так ли это?
Классика PHP так как скрипт будет на сервере я думаю при многократном обращении в секунду будет долго обрабатывать. Допустим парсят ежесекундно 500 человек по ( хххх mb) данным. Небольшая ли нагрузка для PHP как долго он будет справляться с задачей?
Взгляд на Golang - как GO справляется с такими задачами?
Взгляд на node js и java - хотелось бы услышать ваше мнение.
Друзья, прошу не кидать нелестные фразы в мою сторону. Так как раньше такого опыта не было, решил спросить у вас.
Я не совсем понимаю что лучше использовать в данных ситуациях.
Задача: Быстрота, Надежность, Многопоточность, что бы выдерживал большое количество обращений в секунду.
Всем спасибо! :)
PRAIT, дорогой пользователь, настоятельно рекомендуем еще раз обратить самое пристальное внимание на п. 3.1 регламента работы сервиса (и, в особенности, на его последний абзац).
В противном случае, ваши вопросы будут удаляться по причине тег-спама, а систематические нарушения приведут к блокировке учетной записи.
Мне кажется стоит обратить внимание на javascript движки для парсеров, типа phantomjs и casperjs
С их помощью вытаскивание данных со страницы становится проще в десятки раз
Многопоточность работы с этими приложениями уже реализовывайте на любом языке и складывайте в удобном формате в БД или куда-то еще.
Зато нагрузка на сайты доноры тоже возрастает в разы :) да и на сервер на котором запускается решение основанное на хедлесс браузере + скорость работы очень низкая. Писать парсеры конечно же будет проще для сайтов, которые работают на JS, однако все будет весьма малоэффективно.
Михаил Сисин, далеко не все сайты, которые парсишь позволяют большую скорость парсинга или предоставляют данные в "открытом виде". Само собой, если это ряд хтмл страничек однотипных, то проще использовать голый curl
Danil Sapegin, Дело даже не в скорости, а скорее в этичности. 1 или 2 запроса на ресурс, чтобы забрать данные со страницы стандартным HTTP запросом, даже в случае когда сайт работает полностью на JS, лучше чем несколько десятков, сделанных хедлесс браузером. Дополнительным плюсом является то, что бот в этом случае не виден для аналитики и метрики и поэтому не портит статистику.
Я предпочитаю потерять вначале единицы или десятки минут на разбор работы сайта, зато в долгосрочной перспективе сэкономить на машино-времени. Но это в общем то просто мое мнение :)
Михаил Сисин, Знаете, я тоже придерживаюсь такого мнения, чтобы создать минимум неудобств целевому сайту, но почему-то сталкивался с тем, что надо парсить ВК, Яндекс и прочих подобных, где стоит куча защиты от таких умников типа меня, где весь js обфусцирован, все данные прилетающие с сервера по ajax запросу тоже закодированы и надо потратить ощутимо много времени, чтобы решить задачу :)
Все равно какой язык вы выберете. Тот, который лучше знаете в данный момент, или тот, который хотите изучить в процессе. Все равно вы упретесь не в скорость парсера, а в ширину канала. Ну или вас забанят за слишком большую нагрузку на сервер.
PRAIT, вот представьте, что вы поддерживаете какой-то средних размеров сайт.
И однажды вы сидите дома вечером, пьете чай. и тут внезапно менеджер звонит, и говорит: какие-то негодяи запрашивают с нашего сервера 100500 страниц в секунду, и все томозит. А-а-а-аа!
Вы конечно же первым делом делаете простейший бан по ip. Но через 20 минут выясняется, что эти редиски со своим кривым парсером умеют ip менять. Интересно, получится ли у них "избежать бана" тупо сменой ip?
в черный список попадают только ip. Поэтому нет другого способа кроме прокси. ip с которого было более 10 периодических запроса на нормальных сайтах автоматом попадают в черный список. Но баном на автомате пользуются только крутые сайты. Сапожники в основном об этом даже и не думают.
Stalker_RED, Согласен с вами, но есть масса сервисов по парсингу крупных порталов и работают они прекрасно. Значит тут есть какая то фишка о которой мы не знаем. Или там просто задержка, либо лимит на парс. Как думаете?
PRAIT, конечно ставятся какие-то лимиты. Ну и чем крупнее портал, тем легче ему выдержать лишнюю сотню или тысячу запросов.
Даже если этот крупный портал заподозрит что-то неладное, то он вряд ли выдаст сразу бан. Скорее он выдаст капчу, или даже просто уменьшит скорость отдачи.
В общем, скорее всего вы не упретесь в скорость собственно парсинга. Любой язык сможет парсить настолько быстро, что либо положит "донорский" сайт либо столкнется с банами, капчами и ограничениями скорости.
PRAIT, устойчивость чего? Определить порог, после которого вас начнут банить можно только экспериментально.
Вы всегда можете взять пару сотен проксей, и парсить через них. В особо тяжелых случаях можно парсить через тор (хотя на некоторых ресурсах его блокируют). Скорость конечно будет довольно низкой. А так - просто настройте себе какие-то разумные лимиты. 10 запросов в минуту, или 300, или может быть пару тысяч, но не все 100500, которые может выжать ваш сервак.
Задача: Быстрота, Надежность, Многопоточность, что бы выдерживал большое количество обращений в секунду.
Не DDoS'те ресурсы!!! Уважайте друг друга и избежите бана! Парсите всегда с интервалом и в один поток!
Классика PHP так как скрипт будет на сервере я думаю при многократном обращении в секунду будет долго обрабатывать. Допустим парсят ежесекундно 500 человек по ( хххх mb) данным. Небольшая ли нагрузка для PHP как долго он будет справляться с задачей?
Я бы посоветовал вначале ПОСТЕПЕННО всё скачать, чтобы не напрягать ресурс-донор.
А уже после - спокойно распарсите у себя на сервере.
Попробуйте HTTrack
Вы предлагаете качать такой объём? Это очень долго и ресурсоёмко. При этом, HTTrack действует также от вашего ip и может быть забанена.
Или я чего то не понял?
PRAIT, там есть тайм-ауты между запросами, фильтрация лишнего (по расширениям, путям и типам контента) и есть режим прерванной докачки.
Чтобы не быть забаненым - нужно не скрывать IP, а думать не только о себе, но и о том, какую нагрузку своим парсингом Вы даёте на ресурс-донор.
Там также можно выставлять подключение через прокси, как и в PHP и других.
Единственная проблема - это место для сохранения "сырого" контента.
А в плане "долго" - это абсолютно одинаково.
Только всё, что нужно - за Вас уже написали)
Вам - только настроить и скачать.
Ну и распарсить на своей стороне нужные данные.
Про IP:
1.смотря где будете запускать ту версию и качайте (она кросс-платформенная).
2.можете настроить proxy-port на хостинге - это делается очень просто.
Но забанить могут и Ваш IP, и IP сервера. Так что лучше - думать про PROXY.
xmoonlight, Похоже начинаю понимать.
Получается программа не просто копирует сайт а собирает с него данные?
Но я не пойму каким образом мне внедрить её в сайт? Скорее всего недопонимание из за недосыпа, не посчитайте за глупость.
PRAIT, Программа - делает локальную копию сайта. Остальное (парсинг файлов в папке) - делаете Вы.
Фильтры в программе - это только для URI и типов контента (заголовков). Просто она достаточно гибко настраивается, чтобы не качать то, что Вам не понадобится.
Вот почитайте раздел помощи по CLI (интерфейс командной строки).
Go - отличный язык и справляется очень хорошо с многопоточностью. Если планируются высокие нагрузки и конкурентные запуски, то из всего что перечислено - только Go.
Однако для примера 1 и 2 непонятно как вы будете использовать эффективно многопоточность. Определитесь сначала с объемами, сколько запросов будете делать. Как часто датасеты будут обновляться и так далее. После этого можно будет выбирать инструмент.
D - отличный язык и справляется очень хорошо с многопоточностью. Если планируются высокие нагрузки и конкурентные запуски, то из всего что перечислено - только D.
Простой
