Este artículo de Andrew Chan detalla la construcción y ejecución de un rastreador web a gran escala, capaz de indexar mil millones de páginas web en poco más de 24 horas con un presupuesto de alrededor de $462. El objetivo era modernizar el conocimiento existente sobre rastreo web, que data principalmente de 2012, considerando los avances significativos en hardware y la evolución de la web.
¿Cómo funciona? El rastreador se basa en un diseño distribuido con una docena de nodos independientes. Cada nodo contiene toda la funcionalidad del rastreador y maneja una porción de los dominios. Utiliza Redis para almacenar el estado del rastreo, incluyendo colas de URLs a rastrear, información sobre el tiempo de espera entre solicitudes a un mismo dominio (para evitar ataques de denegación de servicio), y datos sobre las URLs visitadas (usando un Bloom filter para optimizar la detección de duplicados). El proceso se divide en fetchers (que descargan las páginas) y parsers (que extraen los enlaces). Los fetchers utilizan asyncio para manejar una alta concurrencia (hasta 7000 'workers' por núcleo), mientras que los parsers, limitados por la capacidad de procesamiento de la CPU, utilizan 80 workers. Un aspecto crucial es la política de 'politeness', que implica respetar el archivo robots.txt, usar un agente de usuario informativo y limitar la frecuencia de las solicitudes a cada dominio.
¿Para qué sirve? Este tipo de rastreador es útil para construir índices web a gran escala, bases de datos de contenido web, o para realizar análisis de la web. Podría ser utilizado por empresas de motores de búsqueda, empresas de análisis de datos, o investigadores que necesiten acceder a grandes cantidades de información de la web.
Consideraciones: El rastreador solo procesa HTML, ignorando JavaScript, lo que limita su capacidad para indexar contenido dinámico. Aunque esto permite una comparación con rastreadores más antiguos, también significa que no captura la totalidad de la web moderna. El uso de almacenamiento en instancia para los datos (en lugar de S3) fue una decisión clave para mantener los costos bajos, aunque implica una menor durabilidad de los datos. El diseño, aunque optimizado para el presupuesto y el tiempo, podría ser mejorado con una arquitectura más modular y escalable para cargas de trabajo aún mayores.