Спарсю бесплатно на Ocaml

[lorien]

Хочу изучить новый язык. Интерсней учить на каких-то реальных задачах. Если кому-то надо спарсить что-нибудь простое, пишите сюда, попробую спарсить c помощью Ocaml.

[Shadefirst]

Спарси 10кк сайтов Алексы. Если можешь)

[kalombo]

Сообщение от vlad0708

Проблема Python. В pycurl multi я заряжаю список url, прохожу по ним, потом всю инфу надо отдельно обработать, пропустить через базу, по мере добавления информации база растет и начинаются тормоза, затем зарядить новый список url (на разные сайты). И так каждый раз по новой.

А причем тут Python, если тормоза появляются при увеличении базы?

[vlad0708]

Сообщение от kalombo

А причем тут Python, если тормоза появляются при увеличении базы?

при том что не могу сразу зарядить тысячу пауков, и никакой обработки тогда не надо делать, просто insert в базу и все.

[lorien]

Спарси 10кк сайтов Алексы. Если можешь)

Напиши подробно, откуда что парсить.

[lorien]

Не до конца. Забил 2Тб винт под завязку и остановил.
Я особо не торопился, поэтому строил DOM на BeautifulSoup. Но для более быстрого варианта у меня есть классы и на регекспах. Когда нужна скорость, использую их. Еще читал что libxml вроде как шустрее, чем BeautifulSoup.

Не вроде как, а шустрее, причём значительно. Парсить весь рунет с помощьью BeautifulSoup - это чудовщино неоптимально с точки зрения CPU-ресурса. Памяти оно тоже жрёт больше, возможно. Ну и бонусом BeautifulSoup падает на некоторых HTML-документах.

Проблема Python. В pycurl multi я заряжаю список url, прохожу по ним, потом всю инфу надо отдельно обработать, пропустить через базу, по мере добавления информации база растет и начинаются тормоза, затем зарядить новый список url (на разные сайты). И так каждый раз по новой.

Это не проблема python и не проблема multicurl. Во-первых, то, что ты заряжаешь multicurl пачками это просто твоя неоптимальная реализация многопоточного скачивания документов. Правильная архитектура позволяет постоянно подкладывать новые задания в multicurl по мере готовности запущенных ранее заданий. Например, мой Grab::Spider так работает. Или scrapy (правда он не на multicurl, а на twisted).

В том, что по мере роста базы начинаютя тормоза, вряд ли виноват python. У тебя, например, неоптимальные индексы, или твои индексы не влезли в память или например, не хватает скорости винчестера.

Ни одно решение у меня не получилось сделать, так чтобы в отдельном процессе был свой краулер на свой сайт.

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

multiprocessing не позволяет сделать такое количество. Вменяемое кол-во процессов 50 - 100.

А какой смысл заряжать сразу 2000 пауков? Они будут друг у друга вырывать CPU-ресрс для парсинга HTMl. Ты упрёшься в CPU, тем более, учитывая что ты юзаешь мегатормозной BeautifulSoup

gevent в связке с urllib2 имеет косяк, если ДНС не резолвится, то таймаут не помогает, он просто зависает.

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

Поэтому чую для таких задач надо прибегать к помощи другого языка.

Я думаю, ты недостаточно хорошо изучил средства, предоставляемые python-платформой. С таким настроем, ты и в других языках найдёшь какие-то баги, мешающие тебе выполнить задачу.

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

Я не очень понял твою формулировку. Могу написать лишь за себя. У меня есть решение, которое позволяет запустить количество пауков по числу ядер т.е. забить все ядра на 100% и спарсить какое угодно количество сайтов.

[vlad0708]

Сообщение от lorien

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

разумеется с cares, без него об асинхронности и речи быть не может.

Сообщение от lorien

Я не очень понял твою формулировку. Могу написать лишь за себя. У меня есть решение, которое позволяет запустить количество пауков по числу ядер т.е. забить все ядра на 100% и спарсить какое угодно количество сайтов.

допустим 4 ядра - ты запустишь 4-х пауков.
Не уверен, но из чтива на форумах, например на C++ можно очень много таких пауков запустить в потоках, которые будут жрать мало ресурсов. В Питоне это нельзя. Python не для мега промышленных масштабов. Об этом речь.

[lorien]

По поводу BeautifulSoup. Вот код который тестирует скорость парсинга заглавной страницы сайта ixbt с помощью библиотек BeautifulSoup и lxml.

http://dumpz.org/590565/

По результатам теста lxml работает в 130 (сто тридцать) раз быстрее, чем BeautifulSoup. О каких других языках может вообще идти речь с таким подходом к решению задачи?

допустим 4 ядра - ты запустишь 4-х пауков.
Не уверен, но из чтива на форумах, например на C++ можно очень много таких пауков запустить в потоках, которые будут жрать мало ресурсов. В Питоне это нельзя. Python не для мега промышленных масштабов. Об этом речь.

Я не знаю C++, ничего не могу сказать. Для меня лишь очевидно, что магии не бывает и если ты в состоянии подавать беспрерывно новые документы для парсинга процессам парсинга, то ни о каких тысячах процессов не может идти и речи. На каждое ядро по процессу и всё. Ядра не резиновые.

Для меня вообще потерял смысл разговор, после того как ты сказал, что юзаешь BeautifulSoup. Ты точно также в C++ или любом другом языке можешь взять чудовищно медленный парсер для разбора HTML, потом ещё например криво настроить базу данных и получить медленную скорость.

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

[lorien]

Чё-то пропал куда-то мой ответ, который я написал Если в кратце, я написал, что процессор не резиновый и если ты можешь подавать беспрерывно новые документы процессам-парсерам, то создавать процессов больше чем кол-во ядер не имеет смысла, ну может быть, в два раза больше процессов чем ядер. Но тысячи процессов - смысла нет. Ещё написал, что прежде чем пенять на питон неплохо бы разобраться, что именно у тебя тормозит, на другой платформе ты точно также сможешь найти тормозную либу для парсинга html, потом криво настроить базу данных, добавить ещё пару костылей и получить тормоза.

[vlad0708]

beautifulsoup тут вообще не причем, тесты делал на чистых регулярках
я о том что не получается запустить очень много независимых пауков на питоне. В C++ работают потоки (жалко что я его не знаю, а учить времени нет), в Питоне разных независимых пауков можно только через multiprocessing запускать, а это совсем не то.

Я думал ты OCaml начал изучать - потому что уперся в это ограничение. Если не для этого, то зачем он вообще нужен. В тиобе рейтинге он в жопе, а это значит проблемы с библиотеками

[masolit]

lua ?