Парсинг на Go (Golang): когда Python слишком медленный

Python давно стал “языком по умолчанию” для парсинга. Причина понятная: входной порог низкий, библиотек много, MVP собирается быстро, а команда data/backend почти наверняка уже умеет на нем работать. Но в какой-то момент у части проектов появляется ощущение, что Python “перестал тянуть”: воркеров становится слишком много, память растет, throughput упирается в потолок, а стоимость инфраструктуры начинает раздражать сильнее, чем сам код.

В этот момент обычно возникает идея: “может, пора переписать всё на Go?” Иногда — да. Но не всегда. Проблема может быть не в языке, а в архитектуре, очередях, retry logic, записи в БД или просто в том, что никто не мерил bottleneck как следует.

Почему Python вообще стал стандартом

Python идеально попал в потребности рынка парсинга. На нем удобно быстро собирать скрипты, прототипы, ETL-джобы и даже довольно серьезные production-пайплайны. У него сильная экосистема для HTML/API scraping, асинхронщины, data processing, NLP и аналитики. Для команды это часто означает одно: можно не разделять стек между “скачать”, “распарсить”, “очистить”, “проанализировать” и “отдать в BI”.

Именно поэтому Python почти всегда остается лучшим языком на старте.

Но дальше включается экономика масштаба. Пока у вас десятки тысяч URL в день — все ок. Когда появляются миллионы URL, long-running воркеры, огромные очереди, агрессивный I/O и требования к предсказуемой утилизации ресурсов, Python может начать обходиться слишком дорого.

Важно: это не “Python плохой”. Это означает, что профиль нагрузки изменился.

Когда Python действительно становится узким местом

Ниже — ситуации, где “переписать hot path на Go” уже выглядит не как фанатизм, а как разумная инженерная гипотеза.

1. Сотни тысяч и миллионы URL

Когда scraper перестает быть “скриптом” и превращается в постоянную систему доставки данных, упираешься не в красоту кода, а в стоимость одного запроса, число конкурентных задач и стабильность на длинной дистанции.

2. Очень много конкурентных сетевых задач

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

3. Память начинает расти слишком быстро

Один из типичных симптомов: вроде CPU еще не умер, но RAM заканчивается раньше, чем хотелось бы. Особенно это заметно, когда приходится поднимать много процессов/воркеров ради throughput.

4. CPU-bound куски внутри одного пайплайна

Парсинг не всегда purely I/O-bound. Часто в одном процессе сидят:

• распаковка контента,
• HTML parsing,
• нормализация,
• дедупликация,
• regex-heavy постобработка,
• сериализация,
• enrichment.

И вот здесь Python начинает чувствовать себя менее комфортно, особенно когда хочется все это делать быстро и массово.

5. Слишком много worker’ов ради нормальной пропускной способности

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

6. Нужен long-running сервис, а не набор скриптов

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

7. Инфраструктурные затраты растут быстрее, чем команда

Иногда проще и дешевле один раз переписать критический сетевой слой, чем бесконечно покупать еще CPU, RAM и дополнительные инстансы.

8. Нужен низкий latency и ровный throughput

Если у вас требования не просто “в среднем быстро”, а “ровно и стабильно под нагрузкой”, то Go часто дает более комфортную эксплуатацию.

I/O-bound и CPU-bound — это разные разговоры

Очень важно не смешивать два типа задач.

Если задача I/O-bound

То есть вы в основном ждете сеть, ответы API, загрузку HTML, редиректы, таймауты — Python с asyncio может быть более чем достаточным. Иногда проблема не в языке, а в:

• плохом connection pooling,
• отсутствии лимитов,
• неверных retry,
• медленной записи в БД,
• неудачной работе с прокси.

Если задача CPU-bound

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

Где Python всё еще отлично подходит

Python не надо “хоронить” — это и есть самая важная честная часть разговора.

Он отлично подходит для:

• MVP и быстрых прототипов,
• небольших и средних объемов,
• ETL-задач,
• enrichment и постобработки,
• проектов, где важно быстро тестировать гипотезы,
• задач, сильно завязанных на pandas, NLP, ML, data science,
• команд, где Python — основной стек.

Если проект живет в зоне “важнее быстрее выпустить, чем выжать максимум из железа”, Python обычно выигрывает.

Иногда лучший следующий шаг — не переход на Go, а:

• вынести блокирующие операции,
• исправить архитектуру,
• перейти на asyncio,
• добавить очередь,
• убрать синхронную запись в БД,
• нормализовать retry/backoff,
• включить дедуп URL и кеш.

То есть сначала стоит честно проверить: мы действительно уперлись в язык или просто в плохой pipeline?

Почему Go выигрывает в высоконагруженном парсинге

1. Легковесная конкурентность

Goroutines — одна из главных причин, почему Go любят для сетевых задач. Масштабировать конкурентные операции в Go обычно проще и дешевле по памяти, чем раздувать парк процессов.

2. Удобная модель для long-running сервисов

Go хорошо чувствует себя там, где нужен не “скрипт”, а постоянно работающий сервис: downloader, queue-consumer, gateway, fetcher, scheduler.

3. Ниже потребление памяти на высококонкурентных задачах

Это не магия, а очень практичный плюс. Когда у вас много параллельных операций, разница в memory footprint начинает чувствоваться буквально в счетах за инфраструктуру.

4. Предсказуемый деплой

Собранный бинарник, минимальная возня с окружением, меньше сюрпризов с зависимостями. Для production-команды это часто значит более спокойный rollout.

5. Хорошая производительность на сетевом I/O

Для сервисов, которые в основном качают, маршрутизируют, ограничивают, ретраят, буферизуют и отдают дальше, Go очень естественен.

6. Удобство для инфраструктурных компонентов

Downloader, proxy layer, distributed worker, task dispatcher, ingestion service — это прямо родная территория Go.

Где у Go есть минусы

Go не волшебная таблетка.

1. Медленнее стартовая разработка

Если задача не очень большая, MVP на Python вы соберете быстрее.

2. Меньше комфорта в “грязных” data-задачах

Когда нужно на лету делать много ad-hoc трансформаций, играться с табличками, статистикой, текстами и небольшими экспериментами — Python обычно удобнее.

3. Быстрые прототипы в Go делать тяжелее

Не потому что Go плохой, а потому что Python проще для короткого цикла “написал — запустил — попробовал — изменил”.

4. Не все проблемы решаются сменой языка

Если bottleneck в:

• сети,
• антиботе,
• прокси-пуле,
• медленной БД,
• плохой очереди,
• неверной архитектуре,

то Go сам по себе ничего чудесного не сделает.

5. Headless/browser automation не становится “легкой”

Если основная боль — тяжелый браузерный рендеринг, Playwright/Chrome и антибот-логика, то смена Python на Go может почти не дать ожидаемого выигрыша.

Python vs Go по сценариям

Критерий	Python	Go	Когда выбирать
Скорость прототипирования	Очень высокая	Средняя	Python для MVP
High-load производительность	Средняя	Высокая	Go для прод-нагрузки
Конкурентность	Хорошая с asyncio	Очень сильная	Go при massive concurrency
Потребление памяти	Часто выше	Часто ниже	Go при дорогой RAM
Удобство деплоя	Нормальное	Очень удобное	Go для daemon/service
Экосистема scraping	Сильная	Достаточная	Python, если много готовых инструментов
Экосистема data processing	Очень сильная	Слабее	Python для ETL/analytics
Поддержка long-running сервисов	Нормально	Очень хорошо	Go для fetcher/gateway
Onboarding команды	Чаще проще	Зависит от команды	Python, если стек уже есть
CLI / worker / daemon	Хорошо	Отлично	Go для системных компонентов
Микросервисы	Хорошо	Очень хорошо	Go для сервисного слоя
Цена ошибки в архитектуре	Часто маскируется масштабированием	Быстрее видна	В обоих важна архитектура

 

Проблема не всегда в языке

Это самый важный технический раздел.

Парсинг тормозит не только из-за Python. Часто система “проседает” потому что:

• нет очередей и backpressure,
• retry logic ведет к лавине запросов,
• отсутствует нормальный rate limiting,
• URL не дедуплируются,
• каждый воркер делает всё подряд,
• синхронная запись в БД блокирует pipeline,
• downloader, parser, transformer и storage живут в одном процессе,
• нет observability,
• тяжелые шаги не вынесены отдельно.

Типичный монолитный воркер выглядит так:

скачал → распарсил → нормализовал → обогатил → сохранил → отправил дальше

На маленьких объемах это работает. На больших — начинает разваливаться.

Гораздо устойчивее выглядит пайплайн, где:

• downloader отдельно,
• parser отдельно,
• storage отдельно,
• queue отдельно,
• observability отдельно.

И вот в такой архитектуре уже можно честно понять:

• сетевой слой лучше делать на Go?
• parser оставить на Python?
• post-processing оставить на Python?
• critical path вынести в Go?

Когда переход на Go реально оправдан

Вот признаки, что разговор о Go уже предметный:

1. У вас есть замеры, а не просто ощущение “кажется медленно”.
2. Bottleneck действительно в runtime/конкурентности/памяти, а не в БД или сети.
3. Инфраструктурные затраты растут заметно быстрее, чем стоимость переписывания.
4. Нужен стабильный long-running scraper service.
5. Требуется высокий throughput и предсказуемый memory footprint.
6. Проект стал production-critical.
7. Нужны миллионы задач в сутки и постоянная нагрузка.
8. Команда умеет в Go или готова системно инвестировать в стек.
9. Есть смысл переписать хотя бы hot path, а не весь проект.
10. Архитектура уже относительно здорова, и язык правда остался последним крупным ограничением.

Когда переход на Go — преждевременная оптимизация

Не стоит бежать переписывать проект, если:

• нет профилирования,
• объемы пока небольшие,
• основная боль в антиботе, а не в runtime,
• bottleneck в БД или прокси,
• команда вообще не умеет в Go,
• фичи важнее throughput,
• проект еще не вышел из стадии эксперимента,
• Python-код можно сильно улучшить без rewrite.

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

Таблица №2: симптом → причина → что делать

Симптом	Возможная причина	Что делать
RAM растет слишком быстро	слишком много процессов/воркеров	оптимизировать Python или вынести downloader в Go
CPU упирается в потолок	heavy parsing/transformation	профилировать, вынести hot path
Слишком много worker’ов	архитектурная компенсация throughput	пересобрать pipeline, подумать о Go
Нестабильный throughput	плохие retry/queue/backpressure	сначала чинить архитектуру
Дорогая инфраструктура	высокий memory footprint	считать TCO, возможно переходить на Go
Деплой слишком хрупкий	сложное Python-окружение	вынести сервисный слой на Go
Long-running сервис “течет”	накопление state / неудачная модель воркеров	перепроектировать сервис, Go может помочь
Очередь перегружается	downloader и parser слиты	разделить этапы
Много времени уходит на постобработку	CPU-bound трансформации	оставить Python или вынести часть на Go/отдельные сервисы
Хотят переписать всё	нет понимания bottleneck	сначала профилирование

 

Гибридный подход: лучшее из двух миров

Очень часто лучший выбор для бизнеса — не “Python или Go”, а “Python и Go”.

Рабочая схема может быть такой:

• Go — downloader, сетевой слой, конкурентные воркеры, API gateway, queue consumer.
• Python — parsing logic, ETL, enrichment, аналитика, NLP/ML, data cleanup.

То есть:

Go собирает сырье → Python обрабатывает данные

Это очень практичный компромисс:

• сетевой hot path становится быстрее и дешевле,
• команда сохраняет Python-экосистему для data-задач,
• rewrite ограничивается критическим участком,
• migration риск ниже.

Мини-кейсы

Кейс 1: Python упирался в RAM

Парсер работал на большом количестве одновременных задач и требовал всё больше процессов для throughput. После выноса downloader-слоя в Go удалось заметно снизить память и количество инстансов, а Python оставить только на parsing + enrichment.

Кейс 2: Python оставили, Go добавили точечно

Команда не хотела переписывать бизнес-логику и трансформации. В итоге Go использовали как high-concurrency fetcher, а Python — как downstream processing layer. Это дало хороший баланс между производительностью и скоростью разработки.

Кейс 3: rewrite отменили после профилирования

Сначала казалось, что Python “слишком медленный”. После замеров выяснилось, что основная проблема — синхронная запись в БД и слишком агрессивные retry. Архитектуру поправили, и необходимость полного перехода на Go исчезла.

Чек-лист перед решением “переписываем на Go”

1. Есть ли профилирование CPU / RAM / latency?
2. Понимаем ли мы bottleneck точно?
3. Проблема в языке или в архитектуре?
4. Что упирается: CPU, RAM, I/O, БД, очередь, прокси?
5. Сколько стоит текущая инфраструктура?
6. Сколько будет стоить rewrite?
7. Есть ли в команде опыт Go?
8. Нужен ли полный rewrite или только hot path?
9. Какие SLA и throughput реально нужны?
10. Как будет выглядеть observability после миграции?
11. Как будем выкатывать migration?
12. Что делать с backward compatibility?
13. Можно ли сначала сделать гибридный вариант?
14. Даст ли это выигрыш бизнесу, а не только инженерам?
15. Не пытаемся ли мы лечить сменой языка проблему в БД или retry?