Как стать автором
Обновить

Комментарии 7

Очень интересный, амбициозный проект!
Да, тут основная сложность в разрозненности и нестабильности источников информации: страницы, их адреса, Dom, айдишники и прочие атрибуты постоянно меняются, поэтому для поддержки скрипта нужны будут люди. И чем больше база конкурентов, тем больше нагрузка на этих людей. Опять же, требования к полноте и достоверности данных нужно как-то покрывать, поэтому важно собирать по максимуму инфы, иначе картина рынка будет искажённой и полагаться на такие данные, при принятии решений, будет опасно.
Т.е., в целом, нужно иметь команду, постоянно переписывающую много кода (из плюсов, можно экономить на качестве). Тут, как мне кажется, выбор node.js и js прекрасный. Вот с реляционной бд я не очень согласен: структуру менять сложнее, у вас разреженность вижу большая достаточно. Можно было бы взять хорошую документоориентированную бд, типа монги, и хранить все там. Можно даже сразу в, скажем, elastic search и к нему отчёты уже независимо прикрутить, которые на лету генерировать можно, т.к. скорость позволяет :) Ну и используйте преимущество node.js -закладывайте модульность, так с кодом работать будет легче.
Ах, самое главное — обязательно продумайте систему мониторинга ошибок при парсинге, чтобы сразу в одном месте видеть, где и на каком конкуренте какой код не смог отработать (скажем, структура сайта поменялась), чтобы сразу знать куда лезть, чтобы починить!
Очень надеюсь, что у вас все получится и жду продолжения!

Большое спасибо за отзыв, но это не проект. Сложилась необходимость реализовать это в кратчайшие сроки. Что касается выбора БД — то тут все же исторически сложилось что у нас MySQL. Всю фичи node.js — вообще надо использовать кластеры, надо разбить на модули, и много чего можно сделать. По вопросу аналитики — необходимы код ответа, title и т.п. По поводу elasticsearch — он как раз таки и используется, но немного в другой стезе (для сопоставления товара конкурентов с товаром из магазина)
Исторически сложилось, что интернет-магазин – на 1C-Bitrix, поэтому мониторинг цен был написан на php. Но это неправильный подход, поэтому ниже будет описан алгоритм парсинга на Node.js.

Что неправильного в написание парсера на php? Почему node.js а не python например?
Что неправильного в написание парсера на php?

В написании парсера на php ничего не правильного, неправилен подход — необходимо именно событийный ЯП. Про вопрос почему не python или java, можно и на C если захотеть, но я выбрал JS как знакомый для меня ЯП.
Мы делаем похожий проект, на базе .net (все работает в облаке). xmldatafeed.com — парсинг и мониторинг цен конкурентов.
Недавно закончил этот проект. У меня он написан на node.js, я просто не фан microsoft. У нас сервера на ubuntu. Отличная работа, судя по работе, единственный минус это то, что магазины постоянно изменяют свою верстку. И у меня так и не получилось нормально связать данные через elastic-search, сейчас работаю над этим (Проблем нет, если у вас 1000 товаров, их хотя бы можно сопоставить в ручную, но когда 40 000 — тут уже надо думать). Погрешность в сопоставлении ~ 30% (сопоставляю, по имени, по цене, по категории). Если у вас есть опыт сопоставлении товаров, то я буду очень признателен если вы поделитесь.
все аналогичное. по названию. и не могу сказать что результаты хорошие. делаем на Эластике тоже. В общем — большая погрешность.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Истории