DuckDB acelera las consultas remotas hasta 3,7 veces con I/O asíncrono
Asynchronous I/O in DuckDB: Work, Thread, Work
A partir de la v2.0, DuckDB soporta lecturas asíncronas de archivos Parquet y CSV, lo que permite saturar el ancho de banda en configuraciones de computación y almacenamiento separados, como EC2 y S3. En pruebas con TPC-H Query 6, el tiempo de ejecución bajó de 8,23 segundos a 2,84 segundos, y con ajustes adicionales, a 2,23 segundos. La implementación incluye un pool de hilos ASYNC, una cola de lectura anticipada y gestión de memoria para evitar problemas de OOM.
Si no podemos emitir suficientes solicitudes concurrentes para usar el ancho de banda de red disponible, el rendimiento puede sufrir drásticamente, con hilos pasando gran parte de su tiempo esperando lecturas remotas en lugar de procesar datos.
- diarrhea
¿Funciona bien que el pool de trabajadores tenga tantos hilos como núcleos junto con el pool asíncrono? Básicamente está sobresuscrito por diseño.
Una vez construí un sistema que tenía (esto es Rust) un pool de hilos de trabajo Rayon de 4 hilos y un pool asíncrono de Tokio de 2 (runtime multihilo). En un sistema de 6 vCPU. Esto terminó funcionando bien. Tokio no estaba hambriento, por lo que manejaba las solicitudes de red con baja latencia.
Una diferencia es que DuckDB es un cliente de red puro. Si uno de sus hilos asíncronos está hambriento, no es el fin del mundo (por ejemplo, k8s no mata tu pod por fallar al responder a los health checks).
- NorthSouthNorth
¿Los archivos CSV permiten nuevas líneas entre comillas? Si es así, ¿cuál es el truco para evitar revisar todo el archivo para descubrir si una nueva línea está entre comillas o es un separador de registros al leerla desde el medio en un hilo asíncrono?
- bburnett44
Usar 512 GB de RAM para un archivo remoto de 22 GB se siente un poco raro para un benchmark, pero quizás no pudieron obtener una gran cantidad de núcleos sin mucha memoria.