LINUX.ORG.RU

Подскажите, возможно ли такое архитектурное решение?

 


0

1

Добрый день, Сейчас работаю над проектом, который делает web scraping данных с одного веб сервера, обрабатывает их и выдает уже пользователю в удобном для него виде. Особенность проекта в том, что пользователю нужны свежие данные и по сути пользователь сам инициирует scraping ожидая довольно оперативно получить результат (в виде web интерфейса). Я написал скрипт, который забирает данные с веб сайта и загружает в БД сервера.

Все в принципе работает на одном пользователе, но я стал задумываться над масштабированием системы. Что-то мне подсказывает, что при увеличении нагрузки (количество запросов) на веб сервер, у него сработает какая-то внутренняя защита и мой сервер, который делает выгрузку будет забанен, как минимум на некоторое время.

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

Ответ на: комментарий от crarkie

Почему просто не использовать список прокси?

Хорошая идея, интересна финансовая сторона вопроса и на сколько реально найти прокси сервера, у которых большое количество белых IP, чтобы можно было делать ротацию?

Интересно, как такие задачи реализуют другие проекты.

samson_b ()
Ответ на: комментарий от samson_b

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

ddidwyll ★★ ()
Ответ на: комментарий от ddidwyll

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

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

Нужно смотреть как донор контента будет реагировать на большое количество запросов, возможно лимитов нет,

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

По поводу тора здравая мысль и ipv6 прокси тоже. Спасибо.

samson_b ()
Последнее исправление: samson_b (всего исправлений: 1)

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

pfg ★★★ ()
Ответ на: комментарий от anonymous

Что мешает договориться с владельцами веб-сервера и получать от них нужные данные через API?

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

samson_b ()
Ответ на: комментарий от samson_b

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

Получается вы даже тупо своровать не можете.

ggrn ★★★★★ ()
Ответ на: комментарий от samson_b

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

Чем я могу помочь? Только размышлениями.

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

А если там личной кабинки нет и апи нормальное, то пили так, чтобы сборщиков данных было много с разными айпи (любым из способов и их комбинаций: несколько айпи на сервак, прокси, отдельный шаред или впс). Где на каждый клиентский запрос к тебе запускается очередной твой сборщик (раунд робин или рандом).

deep-purple ★★★★★ ()

Как часто обновляется информация на внешнем сервисе? На сколько критично, если пользователь получит устаревшую информацию, например, на минуту?

ИМХО, я бы поднял службу, которая раз в n-минут/секунд обновляет данные с внешнего сервиса, производив необходимые манипуляции. Клиенту отдавал бы последние сохранённые данные. В итоге получаем: Фиксирование количество запросов к внешнему сервису; Масштабирование на любое количество собственных пользователей.

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

Adeptus-Mechanicus ()

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

dtm ()
Ответ на: комментарий от slovazap

Но вы же наверное хотите не задачу пользователя решать, а воздух продавать?

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

samson_b ()
Ответ на: комментарий от Adeptus-Mechanicus

Как часто обновляется информация на внешнем сервисе? На сколько критично, если пользователь получит устаревшую информацию, например, на минуту?

Минута - это не критично, а вот 3 часа уже не влияет на качество сервиса.

ИМХО, я бы поднял службу, которая раз в n-минут/секунд обновляет данные с внешнего сервиса, производив необходимые манипуляции. Клиенту отдавал бы последние сохранённые данные. В итоге получаем: Фиксирование количество запросов к внешнему сервису; Масштабирование на любое количество собственных пользователей.

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

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

PS Вообще спасибо за советы, действительно очень много толковых и дельных советов. Есть что попробовать.

samson_b ()

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

Нельзя.

anonymous ()
Ответ на: комментарий от pfg

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

Местные трехзвездочные аналитики про cors не слышали? Жесть.

anonymous ()
Ответ на: комментарий от samson_b

как такие задачи реализуют другие проекты

Договариваются с владельцем.

интересна финансовая сторона вопроса

Вангую, что договориться будет дешевле, чем покупать 100500 ip на проксе.

no-such-file ★★★★★ ()
Ответ на: комментарий от samson_b

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

Записывай время последнего обновления базы на своём сервере, и когда пользователь делает запрос — сравнивай с текущим. Если разница больше желаемой — обновляй, если нет, выдавай какие есть.

anonymous ()