Инфраструктура для сбора данных: трафик, узлы, хранилище

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

Числа условные, подставьте свои. Важно другое: работа состоит из трёх разных нагрузок, и они мешают друг другу, если живут на одном сервере.

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

Сбор данных почти не нагружает процессор. Он ждёт: отправил запрос — ждёт ответа. Мощный процессор простаивает, а упирается всё в другое.

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

Второе — соседство с базой. Пока парсер пишет тысячи мелких записей, та же база отвечает на отчёты, и обе задачи начинают ждать диск. Разнести их на разные машины дешевле, чем купить одну большую.

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

Разделите на три части, и станет видно, что чему мешало:

• Узлы сбора. Их несколько, они одинаковые и легко заменяются. Требуют канала и терпимости к падениям, но почти не требуют процессора и диска.
• Очередь и хранилище сырых ответов. Сюда складывается то, что скачали, до разбора. Место дешёвое, объектное хранилище подходит лучше диска сервера.
• База и разбор. Здесь нужны диск и память. Эта часть живёт постоянно и масштабируется хуже всех — её и надо беречь от соседей.

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

Что из этого во что превращается у провайдеров, которых мы ведём. Цены сверены с их сайтами 15 августа 2026 года, все — при оплате за месяц.

Здесь важны не ядра, а канал и цена за штуку. Младший сервер у AdminVPS стоит 299 ₽/мес при оплате за месяц; для узла, который большую часть времени ждёт ответа, этого достаточно.

Если сбор нужен не постоянно, а прогонами — раз в сутки или раз в неделю, — считайте почасовую оплату. У Timeweb Cloud тариф Cloud MSK 40 стоит 900 ₽/мес, то есть сутки работы обходятся примерно в тридцать рублей. Узел поднимается на время прогона и гасится.

Отдельно про администрирование: если в команде нет человека, который поднимет упавший узел ночью, смотрите AdminVPS — там администрирование Linux входит в тариф.

Сырые ответы держите не на диске сервера, а в объектном хранилище: оно дешевле и не кончается в неподходящий момент. У Timeweb Cloud оно есть, и платить можно по объёму.

Базу имеет смысл вынести отдельно. Свой сервер дешевле, но обновления, резервные копии и репликация лягут на вас. Управляемая база у Timeweb Cloud начинается с 790 ₽/мес — за эти деньги копии и обновления делает провайдер, и при падении сбора данные не задеты.

Под аналитику собранного обычно берут колоночную СУБД: она читает выборки по миллионам строк быстрее строчной. Требования к дискам и памяти под неё разобраны отдельно — хостинг для ClickHouse.

Список для письма провайдеру. Первые три пункта решают исход задачи:

• Лимит трафика в тарифе и что происходит после превышения: счёт за гигабайт, снижение скорости или отключение. Ответ «безлимит» уточняйте — безлимит почти всегда с оговоркой.
• Ширина порта. Гигабитный порт при круглосуточной загрузке даёт около 295 ТиБ в месяц — это потолок, а не рабочая величина.
• Сколько IP-адресов даётся в тарифе и можно ли добавить ещё. Один адрес на все узлы означает общий лимит частоты на всех.
• Есть ли ограничения на исходящие соединения и их частоту. У части провайдеров они не в тарифе, а в правилах пользования.
• Сколько стоит исходящий трафик из объектного хранилища. Хранение дешёвое, а выгрузка тарифицируется отдельно — и на разборе сырых данных выходит дороже хранения.
• Можно ли увеличить диск без остановки. Уменьшить его, как правило, нельзя — поэтому сырые ответы и держат в хранилище, а не на диске узла.

Если нагрузка не постоянная, а редкая и высокая — распродажа, реклама, эфир — решают другие пункты: скорость подъёма и почасовая оплата. Про них отдельно: сервер под пиковую нагрузку.

• Не держите сбор и базу на одном сервере. Это первое, что ломается под нагрузкой, и чинить придётся обе части сразу.
• Не начинайте без расчёта трафика. Умножьте средний вес страницы на число страниц — и сравните с лимитом тарифа до покупки.
• Не складывайте сырые ответы на диск сервера: он кончится, и вместе с ним встанет всё остальное.
• Не наращивайте один большой сервер вместо нескольких мелких: узлы сбора выгоднее держать одинаковыми и заменяемыми.
• Не забывайте про закон: собирайте только общедоступные данные и соблюдайте условия использования тех сайтов, куда обращаетесь.

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

Задача про сбор данных — это не задача про мощный сервер. Процессор здесь почти ни при чём: упирается всё в трафик, в соседство с базой и в устойчивость к падениям.

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