Greenfinger 2.0: un crawler distribuido para la JVM que indexa en una pasada
Rastreador web distribuido para la JVM: cada nodo ejecuta el mismo jar, sin coordinador ni base de datos, y una pasada deja ficheros, índice y vectores listos para buscar.
Greenfinger 2.0 es un rastreador web distribuido para la JVM que se distribuye desde el repositorio. Cada nodo ejecuta el mismo jar, no hay coordinador que desplegar y el primer rastreo no pide base de datos, servidor de búsqueda ni clave de API. Una sola pasada deja tres cosas: los ficheros tal cual se descargaron, un índice de texto completo y una colección de vectores.
El autor lo presenta como una reconstrucción en marcha: la versión 1 sigue respondiendo búsquedas mientras se escribe la 2, y cada nodo informa de lo que ha traído.
Una pasada, tres salidas
La capa de ficheros siempre está activa y admite disco local, MinIO o cualquier almacén S3. Cambiar de destino son tres variables de entorno, y las claves de objeto son idénticas a las rutas locales. AWS S3 y Google Cloud Storage publican endpoints compatibles con S3, aunque lo que viene probado en la matriz de tests es MinIO.
Encima van dos capas más: índice (Lucene embebido o Elasticsearch) y vectorial (Lucene, Qdrant, Weaviate o Elasticsearch). Como la base de datos solo guarda metadatos, ambas se reconstruyen desde los ficheros con un comando de replay, sin volver a rastrear el sitio. Eso cubre casos como una caída de Elasticsearch, un cambio de analizador o decidir seis meses después que sí quieres embeddings.
Sin coordinador en el camino de la descarga
No hay proceso central ni planificador. Una URL despachada es una llamada a otro nodo, que la descarga, encuentra enlaces nuevos y los devuelve a quien corresponda. Los nodos entran y salen con el rastreo ya en marcha. La frontera vive en disco, así que un proceso muerto en la página 40.000 se reanuda donde estaba en vez de empezar de cero. La finalización la decide cualquiera: cada nodo compara los contadores compartidos con maxFetchSize y fetchDuration, y el primero que lo nota escribe el motivo.
Hay dos reglas de frontera que no se pueden desactivar: mismo dominio registrable y por debajo de la URL de inicio. La deduplicación usa SHA-256 o SimHash, y el ruido de navegación y los avisos de cookies se descartan por densidad de enlaces, sin modelo ni diccionario, en cualquier idioma. Las imágenes se recogen de img, srcset, picture y og:image con filtros de tamaño, tipo y bytes, y los bytes idénticos se guardan una sola vez aunque los referencien mil páginas. De serie se leen text, markdown y csv; pdf, Word y Excel exigen declarar un bean aparte, porque cada uno arrastra dependencia y licencia propias.
El transporte es NIO, con Netty como recambio y activado por defecto. La demo incluida rastrea books.toscrape.com: 1.000 páginas conservadas de 28.411 URLs vistas, 3.204 imágenes, 4 minutos y 12 segundos. El arranque son un git clone, mvn clean install y ./run-local.sh, que levanta los nodos y una interfaz web en localhost:9700 con el usuario admin.
Falta ver cómo se comporta con sitios grandes y con varios nodos reales, y qué licencia acompaña al repositorio: el anuncio no lo aclara. Tampoco hay comparación con rastreadores ya asentados. Lo que sí queda claro es para quién es: quien tenga que montar un archivo buscable y no quiera operar una cola, un planificador y un clúster de búsqueda solo para eso.
