Да, именно так. Например в Nginx можно настроить такое ограничение для отдачи основной (html) страницы, а доступ к остальным ресурсам (картинкам и пр.) не ограничивать.
UmbrellaCoders, как я и полагал, кроме словесного поноса конкретики от вас не будет.---------- Добавлено 11.06.2018 в 16:00 ----------vl12, обращайтесь к UmbrellaCoders - он за две копейки вам всё сделает, вы подходите друг другу.
Ну, давайте, давайте, предложите простое и дешевое решение, как быстро спарсить 100к страниц при следующих условиях:
1) Не доставить проблем целевому сайту.
2) Не попасть под автоматический бан/капчу.
3) Не попасть под подмену информации на некорректную (очень неприятный вариант).
4) Сервер сайта не позволяет скачивать с одного ip более одной страницы в секунду.
???
Мда, вы, похоже, вообще не понимаете, о чем речь... Вы не можете понять той мысли, что вычленять надо не слова/токены, а семантические единицы. Мне надо все эти варианты написания в своей базе данных свести к единому товару, а у вас для каждого варианта написания отдельный товар будет создаваться - такие сырые данные непригодны для серьезной обработки - это халтура.
Да, представьте себе, что существуют парсеры не только для скачивания порнухи. Серьезные парсеры используются не для републикации всякой развлекательной дряни, а для анализа и обработки импортированных данны, для их систематизации, выявления связей и пр.
Ох, как же всё запущено... Вычленить, внедрить, проверить. Выше написали, что полчаса достаточно. Хорошо, остановимся на получасе. Вы простые арифметические действия знаете? На калькуляторе можете умножить полчаса на 30 тысяч и перевести в человеко-часы?
Где??? Где есть такая команда квалифицированных специалистов, готовая за 5-10К долларов на меня несколько лет ежедневно пахать?
В том то и дело, что писал, причем серьезные.
Да, в среднем реакция хостингов сайтов именно такая. Даже если отклик менее секунды я бы рассчитывал на вышеуказанные цифры, принудительно бы к этим цифрам свёл, путем внедрения искусственной задержки.
Теперь я знаю, кто гадит в инете :). Профессионал не будет причинять вреда сайту-источнику, не будет запускать загрузку сайта в сотни параллельных потоков, не будет подставлять своего клиента. Неразумные школьники сразу отправляются в бан вместе с их неразумными заказчиками.---------- Добавлено 11.06.2018 в 14:09 ----------И просто спарсить - это половина проблемы. Проблема еще обработать, нормализовать данные, установить связи.
Пример некоторых вариантов написания названия модели смартфона:
"Планшет Lenovo Phab 2 Pro"
"Смартфон Lenovo Phab 2 Pro"
"Фаблет Lenovo Phab 2 Pro"
"Lenovo Phab 2 Pro"
"Lenovo Phab2 Pro"
"Lenovo Phab2Pro"
"Lenovo PB 2 Pro"
"Lenovo PB2 Pro"
"Lenovo PB2Pro"
"Lenovo Phab 2 Pro PB2-690M"
"Lenovo Phab PB2-690M"
"Lenovo PB2-690M"
...
Это разные варианты написания одной и той же модели смартфона. Я еще опечатки не учитываю.
-------
Есть желающие предложить универсальный алгоритм нормализации подобных вариантов написания, т.е. сведения их всех к одной и той же модели? А ведь таких нюансов там множество. А описание характеристик - вообще у всех по разному идет.
Как вы дойдете до нужного элемента с помощью xPath, если у элемента нет никакой тэговой разметки? Например, есть несколько абзацев, размеченных не тэгами <p>, а разделенных двумя <br>, да пусть и тэгами <p> (голыми) - без разницы. И вам надо вычленить из текста имена людей, которые могут быть записаны в любом формате, и по контексту установить связи между ними. Или пример проще: в неразмеченной простыне текста вычленить брэндовые товары и цены и связать их однозначно друг с другом. Никакой xPath вам не поможет.
Бывает и весьма часто. Даже когда разметка есть, но строго не выдерживается по разным причинам и поэтому только на нее одну полагаться нельзя.
Во, первых, как я написал выше, это можно сделать не всегда, а во-вторых, прежде чем добавить xPath/css/id нужных элементов, необходимо проанализировать структуру данных и разметку источника, выявить наиболее надежные комбинации xPath/css/id для каждого элемента, плюс к тому наверняка потребуется нормализация данных (например приведение импортируемой даты из всевозможных форматов написания в единый формат). И это всё надо проделать индивидуально для каждого сайта, а сайтов - десятки тысяч. Надстройки над парсером не сильно помогут, так как имеющиеся библиотеки универсальны и удобны и позволяют легко написать парсер на их языке, например на том же xPath. Нет смысла городить над ними априори негибкие надстройки, так как основная трудоемкость не в настройке парсера, а в предварительном ручном анализе структуры данных каждого сайта-источника.
НУ, сами то вы за сколько бы взялись за разработку системы парсинга (которой мог бы управлять "чайник") из десятков тысяч произвольных источников? И сколько бы взяли за ее поддержку?---------- Добавлено 11.06.2018 в 12:36 ----------И еще момент. Просто скриптом парсить не получится. На каждый урл будет уходить по 2-5 секунд. А в магазинах обычтно страниц много - тысячи, десятки и сотни тысяч. Да и самих сайтов десятки тысяч. Так что простой скрипт - это не вариант. Необходимо разделить процессы загрузки и обработки, а также в обязательном порядке их распараллелить - в рамках одной машины и в рамках кластера машин. Также система должна быть устойчивой к обрывам соединений и пр. Эти моменты сильно усложнят систему. На ПХП я бы такое точно не писал, скорее на питоне. Да, на первый взгляд все выглядит просто, но в реальности...
Вот это то и невозможно в общем случае. Каждый сайт имеет (или может иметь) индивидуальную структуру данных, индивидуальное форматирование, и далеко не всегда можно (и есть возможность) сходу понять, по каким признакам вычленять те или иные кусочки данных.
Представьте, что нужные вам данные в HTML коде источника вообще могут быть НИКАК не размечены, эти данные могут присутствовать в десятках разных вариантах написания, могут быть написаны с ошибками и опечатками. Вычленять такие данные - весьма нетривиальная задача, доступная лишь спецу высокого уровня.
Короче, если вы реально затеяли что-то замутить с такими парсерами, советую:
1) Подумать, надо ли оно вам? Ибо скорей всего всё будет не так просто, как кажется.
2) Хорошо продумать и максимально упростить требования к источникам, к их разметке. Например, если у источника кривая верстка, сразу его пропускаем и детально не анализируем. Т.е. берете в работу только те источники, в которых каждый элемент данных можно однозначно вычленить по тэгу/классу/id или по их комбинации, и где нет противодействия парсингу (банов бота, подмены контента и пр.). Все остальные источники исключайте из рассмотрения.
3) Исходя из п.1 и п.2 максимально всё упрощайте, все сложные/неоднозначные варианты смело исключайте, и пишите четкое детальное ТЗ.
----
Можно, конечно, попробовать написать и универсальный парсер, который даже с источников без разметки будет вычленять некие шаблонные данные и связи между ними, но там придется применять элементы ИИ, работать будет медленно, жрать ресурсов много и главное, точность и полнота будут низкими, негарантированными. Это явно вам не под силу, да и не нужно это в практической плоскости.
У меня тоже основная рабочая ось - дебиан, попробую Visual Studio Code поставить, а то phpStorm и pyCharm тормозят прилично, на шестиядерном интеле/32GB ram/SSD
Суть в том, что у них не некий универсальный парсер, а как я понимаю, у них на каждый источник - отдельный парсер, и все эти парсеры объединены единым интерфейсом управления. Т.е. задача ваша по любому сводится к тому, чтобы написать скрипт парсинга конкретного сайта. Если вам нужен парсинг 10000 сайтов, значит надо будет писать 10000 скриптов. Всякие надстройки и конструкторы особо не помогут, так как в большинстве случаев (но далеко не во всех) скрипты парсинга весьма простые и проблема не в написании таких скриптов, а в выявлении структуры данных сайта-источника, признаков элементов этой структуры, преобразовании в нормализованный вид, т.е. в собственную промежуточную модель данных. А изучение структуры данных и выявление признаков - это по любому ручная работа индивидуально по каждому сайту-источнику и никакого универсального парсера написать невозможно.
Вы упомянули 30000 сайтов источников? Ну, прикиньте, сколько времени понадобится квалифицированному специалисту, чтобы по каждому сайто проанализировать структуру данных, выявить признаки, написать (или настроить) скрипт импорта, протестировать... И так 30000 раз. Но это еще не всё. Надо потом регулярно будет проверять каждый сайт, не поменялась ли структура его данных и если поменялась, вносить изменения в скрипты импорта. Также наверняка пондобится постоянно добавлять новые источники и т.д., т.е. будет нужна постоянная квалифицированная поддержка.
Какие крупные инвесторы? Я указал 100-300 тысяч, а это зарплата квалифицированного специалиста. Ну, можно дешевле найти в странах ближнего зарубежья. Только вы сами то прикиньте, сколько времени понадобиться на разработку импорта индивидуально по 30000 источников и на их поддержку. Боюсь, что мои цифры занижены. Я еще не говорю о том, что при парсинге такого количества объемных сайтов возможно придется распараллеливать процессы на множество компов, также необходимо будет учитывать обрывы связи и повторные соединения, контроль за точностью и целостностью данных и т.д. и т.п. Гладко было на бумаге, да забыли про овраги.
Это не парсер, это интерфейс ко множеству парсеров конкретных сайтов. Вы даже задачу сформулировать не можете.---------- Добавлено 10.06.2018 в 19:39 ----------
Невозможно сделать универсальное решение. Для универсального решения нужна четкая и однозначная разметка (html+css), но разметка часто бывает кривая, может изменяться, а ее может и вообще не быть, но данные надо вычленять и их можно вычленять, но в индивидуальном порядке. Но в любом случае универсальное решение на все случаи невозможно.---------- Добавлено 10.06.2018 в 19:41 ----------
И это вершина айсберга. На этих 5к магазинах время от времени происходят какие-либо изменения в коде страниц и это надо постоянно отслеживать и постоянно вносить изменения.
Так что, как выше написали, для старта надо несколько миллионов рублей, а потом 100-300 тысяч ежемесячно на поддержку. Но это я рассматриваю не сам код, а минибизнес.
