DuckDB 2.0 acelera las consultas sobre S3 hasta 3 veces sin tocar el código
Why DuckDB 2.0 is faster
DuckDB 2.0, cuya alpha ya está disponible, llega con mejoras notables: las consultas sobre S3 son de 2 a 3 veces más rápidas gracias al I/O asíncrono, los CTE recursivos en jerarquías profundas pasan de segundos a décimas de segundo, y el tipo VARIANT reduce el almacenamiento un 2,7x frente a JSON. El autor probó estas características en su portátil y contra S3, con números concretos y algunos hallazgos inesperados en los registros de commits.
En 2.0 un grupo separado de hilos solo descarga, manteniendo docenas de row groups en vuelo y almacenando los bytes en un búfer. Los workers solo decodifican, y siempre hay un row group listo para ellos. La red y la CPU están ocupadas al mismo tiempo.
- scythmic_waves
También me encantan las visualizaciones, pero la prosa me da fuertes vibraciones de LLM:
> Un solo ajuste impulsa esto,...
> El coste ahora depende de las filas que realmente tocas, no de rondas por tamaño de tabla.
Etc.
Me dan los "brain scramblies" [1] de intentar descifrar este estilo de escritura en el trabajo, así que odio verlo en otros sitios. Disculpas si me equivoco. Pero si no me equivoco, OP, no uses un LLM para escribir por ti. Es peligroso para la salud de tu lector [2].
[1]: https://www.youtube.com/watch?v=ipUJq-odt5Q
[2]: https://discourse.haskell.org/t/how-to-keep-enjoying-program...
- stacktraceyo
Gran visualización. Aparte, su nueva API de extensión de C++ también será más rápida desde la perspectiva del desarrollo / distribución de esas extensiones.
- robertclaus
Estaba de acuerdo con la escritura de la IA hasta que llegué al hecho de que añadieron Triggers en 2.0 y el artículo decidió que eso era meh comparado con optimizar los workers para el acceso a archivos S3 en conexiones lentas. No. Leeré las notas de la versión yo mismo.
- rumbledownunda
Voy a probarlo en mi próximo cuaderno de Jupyter.
- jiggawatts
Ojalá más motores de bases de datos usaran un diseño basado en tareas como Umbra / CedarDB.
La mayoría de los motores de BD que existen todavía parecen usar un paralelismo estilo "n-hilos" con operaciones de intercambio y una mala gestión de E/S asíncrona.
DuckDB está mejorando en este frente, pero en cierto sentido está alcanzando I+D (¡e implementación!) que ya tiene décadas.
Un "desafío retórico" que me gusta plantear a los desarrolladores de software que trabajan en sistemas como este es el siguiente: si te diera una computadora con 1.024 núcleos y un ancho de banda de red y almacenamiento a juego -- pero con latencia significativa -- ¿podrías mantener un sistema como este al 100% de utilización con una sola consulta?
La respuesta para casi todo el software es "no".
Por ejemplo, SQL Server se limita a 64 hilos de hardware para cualquier consulta individual: https://learn.microsoft.com/en-us/sql/database-engine/config...
Los códigos de GPU están empezando a llegar ahí, pero los códigos de CPU están muy atrás en esta frontera de la informática.
¡No son solo las bases de datos! ¿Puedes (des)comprimir un archivo en paralelo? ¿Verificar su hash en paralelo? ¿Subir/descargar desde el almacenamiento con paralelismo de tareas de CPU y E/S? ¿Puedes solapar todas estas operaciones para que nada esté nunca esperando a algo que no tiene que esperar?
¡Esto importa! Hice algunas pruebas con códigos de bioinformática y descubrí que la mayoría se quedaban atascados en pozos de alquitrán. Muchos no podían escalar a SSD modernos con millones de IOPS o redes modernas con cientos de gigabits de rendimiento, sin importar cuántos núcleos de CPU se les echara.
PD: Los procesadores EPYC 9006 de la era Zen 6 de AMD tendrán 51 […]