Как организовать парсинг товаров ИМ на python?

Question

[serjio568]

Я понимаю что в интернете очень много инфы на эту тему, но хотелось на несколько вопросов я ответ так и не нашел.
В общем нужно сделать парсер, который будет собирать данные с нескольких ресурсов (товары, цены, сроки доставки и т.д) и выводить в какую-нибудь вьюху джанги например. Товары обновляются достаточно часто, может быть один и тот же товар у одного поставщика, но на разных складах. Пользователь в принципе может ждать секунд 10. Аналитика цен не нужна, чисто информация у кого дешевле. Исходя из всего этого имеется смысл писать в БД? И как организовать подобную задачу?

Comments

[FulTupFul]

Если товары обновляются часто то вы должны решить нужно ли вам хранить эту информацию(для статистики, архива и.т.д.) или вы ориентированы только на вывод информации пользователю. Если так то могу посоветовать делать запросы через библиотеку requests и парсить это дело каким-нибудь beatifulsoup. Но такой вариант не подойдет для SPA магазинов.

Answer 1

[Roman K]

Парсить по запросу? Вздор. Ну разве что юзать Celery, отправлять юзера на страницу, где он будет ждать результата. Но результаты парсинга в любом случае сохранять в БД.

Answer 2

[sim3x]

Лучше хранить у себя в любом случае
В зависимости от сложности парсинга - [ celery ] + ( requests + lxml / celery + scrappy )

Answer 3

[stratosmi]

Исходя из всего этого имеется смысл писать в БД?

При большой нагрузке - да, для кэширования.

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

А вот сомнительно, чтобы поставщик столь оперативно обновлял свой сайт. Чтобы имело смысл парзить сразу, как только пользователь пожелает узнать информацию о товаре.

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

А еще пользователи иногда просто обновляют страницу. Зачем тут же делать запросы к 10 сайтам поставщиков.
А еще пользователи зачастую ходят между несколькими товарами, выбирая какой-то из них. Зачем при многократном заходе на страницу товара раз в 5 минут сделанным - заново обращаться к 10 сайтам поставщиков.

Так что да, имеет смысл кэшировать в своей БД.

При получении запроса - см. не протухла ли информация о товаре. Если не протухла, то отдаем из базы сразу.
Если товар у поставщика удобен для парзинга в один проход (например, можно скачать один файл актуального прайс лиса, не нужно проходить по всему сайту по всем страницам) - имеет смысл не дожидаться посетителя вашего сайта, а парзить заранее и регулярно, скажем раз в час. Результат разумеется сохраняется в вашей БД.

Про Scrapy уже написали.

Comments

[serjio568]

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

[stratosmi]

serjio568,

А так это должен быть парсер для проценки автозапчастей. Чтоб менеджер вбив артикул получил самую низкую цену.

О, я как раз это и предполагал!
В любом случае данные на сайтах с большой вероятностью - не оперативны. На них не стоит полагаться настолько, что обязательно отправлять запрос поставщикам на каждый запрос пользователя вашего сайта.
Товар вашими постащиками продается и с витрины в оффлайне. Возможно покупатель в магазине уже вертит этот товар в руках, а ваш менеджер на него тоже глаз положил...
Товар продается и с других сайтов, подобных вашему, где "менеджер подбирает у поставщика минимальную цену".
Товар продается и с сайтов поставщиков.
И чем ниже цена - тем больше вероятность, что большее число людей выберут одну и ту же последнюю единицу товара.

[serjio568]

stratosmi, Тогда спасибо за подсказку)