DuckDB 2.0 alpha ofrece lecturas S3 más rápidas y consultas recursivas

El equipo de DuckDB ha lanzado la versión alpha de DuckDB 2.0, marcando un paso significativo hacia adelante en el rendimiento para cargas de trabajo analíticas. Esta actualización se centra en tres mejoras arquitectónicas principales: entrada/salida asincrónica para almacenamiento en la nube, un motor reescrito para expresiones comunes de tabla (CTE) recursivas y un nuevo tipo de datos nativo para manejar datos semiestructurados. Estos cambios buscan reducir los tiempos de consulta y los costos de almacenamiento para ingenieros que construyen pipelines de datos en portátiles o en la nube.

Qué ocurrió

La ganancia de rendimiento más inmediata proviene de cómo DuckDB 2.0 maneja los datos almacenados remotamente, como en Amazon S3. En versiones anteriores, los hilos de trabajo debían alternar entre descargar bloques de datos y procesarlos, dejando recursos de CPU inactivos durante las esperas de red. La nueva versión introduce un grupo separado de hilos dedicado exclusivamente a descargar datos por adelantado. Esto permite al sistema mantener tanto la conexión de red como la CPU ocupadas simultáneamente, reduciendo significativamente el tiempo total requerido para leer archivos Parquet o CSV grandes desde el almacenamiento de objetos.

Más allá de la velocidad bruta, la versión aborda patrones de consulta complejos que involucran datos jerárquicos. Las expresiones comunes de tabla (CTE) recursivas, utilizadas a menudo para recorrer organigramas o árboles de dependencias, han sido completamente rediseñadas. Anteriormente, cada nivel de recursión requería un escaneo completo de la tabla fuente, haciendo que las jerarquías profundas fueran prohibitivamente lentas. El nuevo motor lee la tabla una sola vez y construye una estructura interna de búsqueda, lo que le permite saltar directamente a las filas relevantes para cada nivel subsiguiente de recursión. Este cambio transforma operaciones que antes tardaban segundos o minutos en tareas de menos de un segundo.

La tercera adición importante es el tipo de datos VARIANT, diseñado para manejar JSON y otros formatos semiestructurados de manera más eficiente. En lugar de almacenar JSON como una cadena de texto simple, DuckDB 2.0 analiza los datos durante las operaciones de escritura. Identifica campos que aparecen consistentemente con el mismo tipo de datos en la mayoría de las filas y los almacena como columnas separadas y optimizadas. Solo los campos irregulares o raros permanecen en un blob binario. Este proceso, conocido como shredding (fragmentación), reduce la huella de almacenamiento y acelera las consultas que filtran o agregan sobre esos campos consistentes.

Detalles clave

• La E/S asincrónica mejora las velocidades de lectura de S3 entre dos y tres veces sin requerir cambios en las consultas SQL existentes.
• La configuración read_ahead_depth controla cuántos grupos de filas se obtienen por adelantado, con un valor predeterminado de dimensionamiento automático basado en el número de hilos.
• El rendimiento de las CTE recursivas mejoró drásticamente en pruebas, pasando de hasta 16 segundos a 0,10 segundos para un recorrido del historial de git de 20.000 commits.
• El nuevo tipo VARIANT reduce los requisitos de almacenamiento aproximadamente 2,7 veces en comparación con almacenar JSON como cadenas de texto.
• Las consultas que filtran sobre campos VARIANT fragmentados se ejecutan aproximadamente seis veces más rápido que el análisis de texto JSON y se acercan a la velocidad de las columnas tipadas nativas.
• Las operaciones de lista dentro de los datos VARIANT actualmente tienen un rendimiento inferior al acceso a campos, lo que sugiere que los usuarios deben evitar convertir listas en rutas de consulta críticas.

Contexto

Para entender estas mejoras, ayuda saber cómo las bases de datos analíticas procesan típicamente los datos. Los motores tradicionales a menudo tratan la latencia de red y el procesamiento de CPU como pasos secuenciales. Al leer desde el almacenamiento en la nube, la base de datos debe esperar a que lleguen los datos antes de poder comenzar el cómputo. La E/S asincrónica desacopla estas tareas, permitiendo a la base de datos precargar datos mientras procesa simultáneamente los bloques previamente obtenidos. Esto es similar a cómo un reproductor de video bufferiza las próximas escenas mientras ves la actual.

Las CTE recursivas son una función de SQL utilizada para consultar estructuras jerárquicas, como líneas de reporte de empleados o árboles de directorios de archivos. En implementaciones antiguas, la base de datos escaneaba repetidamente toda la tabla para encontrar el siguiente nivel de la jerarquía. Si un árbol tenía diez niveles de profundidad, la tabla se escaneaba diez veces. El nuevo enfoque construye una estructura similar a un índice en memoria después del primer escaneo, permitiendo a la base de datos localizar registros hijos instantáneamente sin releer los datos fuente. Esto cambia el costo de ser proporcional a la profundidad del árbol multiplicada por el tamaño de la tabla, a ser proporcional solo al número de filas realmente visitadas.

Por qué importa

Para equipos que gestionan su propia infraestructura de datos, estos cambios reducen la necesidad de herramientas especializadas. Anteriormente, las consultas jerárquicas profundas podrían haber requerido exportar datos a una base de datos de grafos o escribir código de aplicación personalizado para gestionar el recorrido. Con DuckDB 2.0, estas operaciones se vuelven viables dentro de SQL estándar, simplificando la pila tecnológica. De igual manera, el mejor rendimiento de S3 significa que mantener datos en almacenamiento de objetos de bajo costo es más viable para el análisis interactivo, reduciendo la presión de mover todo a almacenamiento de bloques de alto rendimiento y costoso.

El tipo VARIANT ofrece un punto medio práctico para manejar datos del mundo real desordenados. Los ingenieros a menudo luchan con la elección entre esquemas rígidos, que se rompen cuando cambian los formatos de datos, y cadenas JSON flexibles, que son lentas de consultar. Al optimizar automáticamente las partes consistentes de los datos JSON mientras preserva la flexibilidad para el resto, DuckDB 2.0 permite a los equipos ingerir logs semiestructurados o datos de eventos sin sacrificar el rendimiento de las consultas. Esto reduce el esfuerzo de ingeniería requerido para limpiar y modelar los datos antes de que puedan ser analizados.

Sin embargo, estos beneficios vienen con responsabilidades de modelado. El rendimiento de VARIANT depende fuertemente de la consistencia de los datos. Si un campo a veces contiene un número y a veces una cadena, no puede ser fragmentado efectivamente y permanecerá en el almacenamiento binario más lento. Los equipos deben asegurarse de que sus pipelines de datos produzcan tipos consistentes para los campos clave para realizar las ganancias de rendimiento. Además, aunque la E/S asincrónica ayuda con archivos grandes, no resuelve la latencia inherente de acceder a miles de archivos diminutos, reforzando la mejor práctica de consolidar conjuntos de datos pequeños en particiones más grandes.

Qué puedes hacer

• Prueba la versión alpha en tu máquina local usando el script de instalación proporcionado para evaluar tus cargas de trabajo específicas.
• Revisa tus consultas basadas en S3 para asegurar que estás leyendo archivos Parquet grandes en lugar de muchos pequeños, para maximizar los beneficios de la E/S asincrónica.
• Identifica consultas recursivas en tu base de código, como recorridos de organigramas o expansiones de listas de materiales, y vuelve a ejecutarlas para medir la nueva línea base de rendimiento.
• Audita tus tablas intensivas en JSON buscando campos con tipos de datos consistentes y considera convertirlos al tipo VARIANT para reducir el almacenamiento y mejorar la velocidad de filtrado.
• Evita convertir listas VARIANT a arrays en consultas críticas para el rendimiento hasta que futuras actualizaciones optimicen esta operación.
• Monitorea la configuración read_ahead_depth si experimentas presión de memoria, aunque la configuración automática predeterminada debería adecuarse a la mayoría de los entornos.