Во сколько обходится парсинг миллиона страниц

MAATRIX

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

Из чего складывается стоимость парсинга

Стоимость масштабного сбора данных — это не одна цифра, а сумма четырёх независимых статей, каждая со своей логикой роста:

1. Вычислительная мощность — сервер(ы), на которых крутится парсер, плюс, если нужно, headless-браузер для JS-рендеринга.
2. Трафик — входящий (скачанные страницы) и исходящий (запросы), а если рендерите через браузер — трафик вырастает в разы.
3. Прокси и ротация IP — обязательная статья, если целевой сайт банит массовые запросы с одного адреса. Часто крупнейшая по деньгам.
4. Хранение результата — сырой HTML занимает много места, структурированные данные (JSON/строки в БД) — на порядок меньше.

Плюс отдельная строка, которая не про деньги напрямую, но должна быть учтена в планировании — юридико-этическая сторона: robots.txt сайта, его условия использования (ToS), нагрузка, которую вы создаёте на чужую инфраструктуру. Это не про «посчитать в рублях», но игнорировать нельзя: часть площадок прямо запрещает автоматический сбор в ToS, часть — технически душит парсер (капчи, бан IP, троттлинг), и это тоже конвертируется в деньги — через прокси и через время разработки обходов.

Дальше разберём каждую статью по отдельности с методикой прикидки, а не с «вот вам цифра».

Вычислительная мощность: считаем от времени на страницу

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

Базовая формула:

Общее время (без параллелизма) = кол-во страниц × время на страницу
Нужное число воркеров = Общее время (без параллелизма) / Желаемый срок

Пример на условных цифрах (у вас будет иначе — зависит от сайта, сети, парсера):

• Если один запрос + разбор HTML занимает ~1 секунду (простой парсинг без рендеринга JS), то миллион страниц последовательно — это ~278 часов (~11.5 суток).
• Чтобы уложиться в сутки, нужно примерно 12 параллельных воркеров (278 / 24 ≈ 11.6, округляем вверх с запасом).
• Чтобы уложиться в 4 часа — уже ~70 воркеров.

Это ориентир на «страницу-секунду» — у вас цифра будет другая: сайт может отвечать за 200 мс или за 3 секунды, часть страниц может редиректить, часть — падать по таймауту и требовать повторов. Всегда мерьте реальное время на реальной выборке (100-1000 страниц) перед тем как считать дальше — экстраполяция на глазок здесь и создаёт основной риск промаха в оценке.

Дальше — сколько воркеров помещается на один сервер. Это упирается в:

• CPU — парсинг DOM (BeautifulSoup, lxml, Scrapy-парсеры) сам по себе не тяжёлый, узкое место обычно не в CPU, а в ожидании сети (I/O bound). Поэтому воркеров на ядро можно держать больше, чем ядер — они простаивают в ожидании ответа.
• RAM — критично, если используете headless-браузер (Playwright, Puppeteer, Selenium) для страниц с JS-рендерингом: один инстанс Chromium в headless-режиме съедает заметно больше памяти, чем простой HTTP-запрос, и параллельных инстансов браузера на сервер помещается на порядок меньше, чем простых HTTP-воркеров. Если сайт отдаёт нужные данные в исходном HTML или через отдельный API-запрос (посмотрите вкладку Network в браузере до того, как писать парсер) — headless-рендеринг не нужен вообще, и это резко снижает требования к железу.
• Сеть сервера — если воркеров много, а канал сервера узкий, воркеры начнут упираться друг в друга, и время на страницу вырастет — измеренная на 100 страницах скорость перестанет соответствовать скорости при 70 параллельных потоках.

Практический вывод: для парсинга без рендеринга JS хватает недорогого VPS с несколькими ядрами — узкое место чаще в прокси и в реакции целевого сайта, чем в CPU. Для парсинга с headless-браузером на миллион страниц разумнее не один мощный сервер, а несколько средних — рендеринг горизонтально масштабируется проще, чем вертикально.

Трафик: входящий и исходящий, с поправкой на рендеринг

Вес миллиона страниц — величина сильно переменная (от нескольких КБ на страницу для простого HTML до нескольких МБ, если страница тяжёлая — картинки, скрипты, шрифты), поэтому точную цифру дать нельзя. Но методика прикидки простая:

Суммарный входящий трафик ≈ кол-во страниц × средний вес одной страницы (замеренный на выборке)
Исходящий трафик (запросы, заголовки) — обычно на 1-2 порядка меньше входящего, им часто можно пренебречь в грубой прикидке

Дальше — важный нюанс: если парсите обычным HTTP-запросом (без браузера), можно скачивать только нужный ответ и не тянуть картинки/шрифты/скрипты — вес одной «страницы» в этом случае обычно ограничивается HTML-документом и, если нужно, JSON-ответом API. Если же используете headless-браузер, он по умолчанию загружает всё как обычный браузер — картинки, CSS, шрифты, трекеры — и вес страницы вырастает кратно. Отключение загрузки картинок и шрифтов в headless-браузере (это делается через перехват сетевых запросов) — одна из самых дешёвых оптимизаций, которая напрямую режет и трафик, и время на страницу.

Для прикидки стоимости трафика: возьмите замеренный на выборке средний вес страницы, умножьте на миллион, посмотрите тариф по трафику у вашего провайдера сервера — у большинства VPS/выделенных серверов есть безлимитный или большой встроенный пакет трафика в тариф, и для миллиона страниц (даже по 200-500 КБ на страницу — это 200-500 ГБ) часто хватает базового тарифа без доплаты. Отдельная статья про то, как считается цена гигабайта трафика у разных провайдеров — механика полезна, если ваш тариф трафик всё же ограничивает и доплата возможна.

Прокси и ротация IP: статья расхода, которую забывают посчитать заранее

Вот тут обычно и происходит промах в смете. Если целевой сайт не блокирует массовые запросы с одного IP — прокси не нужны вообще, и весь бюджет укладывается в сервер и трафик. Но большинство сайтов, которые интересно парсить в промышленных масштабах (маркетплейсы, агрегаторы, соцсети, поисковики), банят или ограничивают частоту запросов с одного адреса — по количеству запросов в минуту, по паттерну поведения, по капче после N обращений.

Тут методика такая, без выдумывания точных тарифов конкретных прокси-сервисов (они у разных провайдеров разные и часто меняются — смотрите актуальный прайс у выбранного сервиса перед закупкой):

• Тип прокси определяет и цену, и надёжность. Дата-центровые прокси (IP из облака/хостинга) — дешевле, но их легче спалить: диапазоны IP хостеров часто уже в чёрных списках у крупных сайтов. Резидентные прокси (IP реальных провайдеров, через партнёрские сети) — заметно дороже, но реже банятся. Мобильные прокси — обычно самые дорогие, но и самые «чистые» с точки зрения антибот-систем.
• Модель оплаты бывает по трафику ИЛИ по количеству IP/портов — у разных сервисов принципиально разная экономика. Прокси по трафику масштабируются вместе с объёмом парсинга (чем больше страниц — тем больше платите), прокси по портам/IP — фиксированная стоимость за пул адресов независимо от объёма трафика через них. Для миллиона страниц считать нужно оба варианта на реальных цифрах от провайдера и сравнивать, что выгоднее именно при вашем объёме.
• Частота ротации влияет на то, сколько IP реально нужно в пуле. Если сайт банит IP после условных 50 запросов подряд, а вы делаете миллион запросов — грубая прикидка: нужно IP в пуле ≈ (общее число запросов / порог бана на один IP) × запас на "отдых" забаненных адресов. Реальный порог бана заранее неизвестен — его надо аккуратно нащупать на небольшой выборке до того, как запускать парсинг миллиона страниц на всю катушку, иначе рискуете выжечь весь купленный пул проб и ошибок за первый час.
• Заложите бюджет на «спалённые» IP и капчи — часть прокси в любом пуле со временем банится безвозвратно, часть запросов упрётся в капчу, которую либо решает сервис распознавания капч (тоже платный, отдельная статья), либо запрос считается потерянным и уходит в повтор. И то, и другое увеличивает фактический трафик и количество нужных IP сверх «чистой» математики.

Практический совет по смете: возьмите 2-3 актуальных прайса от реальных прокси-провайдеров под нужную геолокацию и тип (резидентные/датацентровые), прогоните пробную выборку в несколько тысяч страниц через каждый, замерьте фактический процент банов/капч и реальный расход трафика на прокси — и только после этого экстраполируйте на миллион. Отдельно у нас есть статья про настройку прокси именно под парсинг и обход блокировок на сервере — там разобрана техническая сторона ротации, которая напрямую влияет на то, сколько прокси реально понадобится.

Хранение результата: сырой HTML против структурированных данных

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

Методика прикидки:

Вес результата ≈ кол-во страниц × вес одной извлечённой записи (замеренный на выборке)

Если с одной страницы весом 300 КБ вы извлекаете структуру на 1-2 КБ (типичное соотношение для карточки товара или профиля) — миллион записей займут условно 1-2 ГБ, что для любого VPS тривиально по месту на диске.

Отдельный вопрос — нужно ли хранить сырой HTML вообще. Если парсер написан и протестирован надёжно, сырой HTML можно не сохранять — распарсили, записали структуру, HTML выбросили. Это резко экономит место. Но если есть риск, что схема сайта изменится и придётся перепарсивать задним числом, или логика извлечения ещё не финализирована — разумно на первое время сохранять и сырой HTML тоже (можно сжатым — gzip или zstd на тексте даёт кратное уменьшение размера), а после стабилизации парсера — почистить архив.

Куда складывать структурированный результат — зависит от объёма и дальнейшего использования:

• Для действительно миллиона записей с простой структурой обычно достаточно PostgreSQL на том же сервере или соседнем — с этим неплохо разбирается статья про пошаговую установку PostgreSQL на Ubuntu.
• Если нужна именно аналитика по колонкам в больших объёмах (агрегации, фильтры по множеству полей) — стоит сравнить PostgreSQL с ClickHouse: разбор сделан в статье ClickHouse или PostgreSQL — что выбрать для сервера.
• Если планируете хранить и сырой HTML в архиве «на всякий случай» — учитывайте это отдельной строкой в требованиях к диску, здесь экономия на структуре уже не поможет.

Инструменты: от простого HTTP до headless-браузера

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

• Простой HTTP-клиент + парсер HTML (requests/httpx + BeautifulSoup/lxml, или Scrapy как готовый фреймворк с очередями и ретраями) — самый дешёвый вариант по CPU, RAM и трафику. Подходит, если нужные данные есть в исходном HTML-ответе без выполнения JavaScript.
• Headless-браузер (Playwright, Puppeteer, Selenium) — нужен, если контент подгружается JS-ом после загрузки страницы. Дороже по RAM (на порядок больше на один параллельный поток), дороже по трафику (грузит все ресурсы страницы, если не отключить это явно) и медленнее (страница должна отрендериться, а не просто скачаться).
• Готовые фреймворки для LLM-friendly парсинга (например, инструменты вроде Crawl4AI, которые сразу отдают контент в удобном для дальнейшей обработки виде) — снимают часть разработки, но сути расчёта стоимости не меняют: те же вычисления, трафик, прокси и хранение остаются актуальны. Установка одного из таких инструментов на сервер разобрана в статье про Crawl4AI на VPS.

Практический совет: проверьте вручную через вкладку Network в браузере, приходят ли нужные данные отдельным запросом к API (часто сайты подгружают данные через свой внутренний JSON-эндпоинт) — если да, можно дёргать напрямую этот эндпоинт вместо рендеринга всей страницы, что экономит и CPU, и RAM, и трафик разом. Это первое, что стоит проверить перед выбором инструмента, а не после того, как headless-кластер уже развёрнут.

Юридико-этическая сторона: что учесть до старта

Это не юридическая консультация (для конкретного кейса — к юристу), но три вещи стоит держать в голове на этапе планирования, потому что они влияют и на техническую архитектуру, и на бюджет:

• robots.txt сайта — файл с указаниями, какие разделы сайт просит не индексировать/не обходить автоматически. Это рекомендация, а не техническое препятствие, но её игнорирование — осознанный риск, который стоит учитывать.
• Условия использования (ToS) сайта — часть площадок прямо запрещает автоматический сбор данных в пользовательском соглашении. Это не техническое, а договорное ограничение, и его наличие стоит проверить до того, как вкладываться в инфраструктуру под конкретный сайт.
• Нагрузка на чужую инфраструктуру — даже без явного запрета, агрессивный парсинг (много параллельных запросов без пауз) создаёт реальную нагрузку на чужой сервер. Разумная практика — троттлинг (задержки между запросами с одного потока/IP) и парсинг в часы низкой нагрузки на целевой сайт, если это не критично по срокам.

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

Как собрать полную смету проекта

Собираем всё в одну методику пошагово:

1. Замерьте на выборке 100-1000 страниц: среднее время на страницу, средний вес страницы, средний вес извлечённой записи, процент ошибок/редиректов/капч без прокси (чтобы понять, нужны ли прокси вообще).
2. Посчитайте вычисления: нужное число воркеров = (кол-во страниц × время на страницу) / желаемый срок. Прикиньте RAM и CPU под это число воркеров (или под число параллельных инстансов браузера, если нужен рендеринг).
3. Посчитайте трафик: кол-во страниц × средний вес страницы = суммарный трафик. Сверьте с трафиком, включённым в тариф сервера.
4. Посчитайте прокси: если сайт банит по IP — возьмите реальные прайсы 2-3 провайдеров под нужный тип и гео, прогоните пробную выборку, посчитайте фактический процент бана/капчи и умножьте на полный объём.
5. Посчитайте хранение: кол-во страниц × вес извлечённой записи (плюс отдельно — вес архива сырого HTML, если решили его хранить).
6. Добавьте запас 20-30% на повторные попытки, изменение структуры сайта в процессе парсинга и на неизбежные простои при отладке — эта поправка почти никогда не оказывается лишней.

Пример свода (условные цифры для иллюстрации методики, не готовый тариф):

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

Частые вопросы