La mayor característica de DuckDB también era su mayor cuello de botella
DuckDB se ganó su reputación como una potente base de datos analítica basada en archivos. Al igual que SQLite, se ejecuta integrada en una aplicación, lo que elimina la necesidad de configurar un servidor independiente. Este diseño la hizo muy atractiva para cargas de trabajo analíticas ligeras y en proceso.
Sin embargo, esta naturaleza integrada tenía un inconveniente importante: la concurrencia. Cada proceso de aplicación mantiene en memoria su propio estado en caché de la base de datos. Aunque es eficiente para un solo proceso, esta arquitectura implica que solo un proceso puede escribir en un archivo de base de datos a la vez. DuckDB no podía mantener sincronizados los estados en caché de varios procesos.
Imagine un equipo que ejecuta varios servicios, paneles y aplicaciones, todos con la necesidad de acceder a los mismos datos analíticos y actualizarlos. Con el DuckDB tradicional, se enfrentaban a un dilema: construir por su cuenta una compleja capa de uso compartido para coordinar las escrituras, o elegir una base de datos completamente distinta.
Este cuello de botella obligó a muchos a esquivar los puntos fuertes de DuckDB. Algunos usuarios incluso recurrieron a ejecutar DuckDB dentro de PostgreSQLQL para lograr acceso compartido. La característica que hacía a DuckDB tan accesible, su naturaleza integrada y sin servidor, se convirtió en su mayor limitación para entornos colaborativos.
Quack da a DuckDB una puerta de entrada, no un nuevo motor de almacenamiento
Quack, presentado por primera vez de forma experimental en mayo, da a DuckDB una puerta de entrada. Una instancia de DuckDB abre el archivo de la base de datos y actúa como servidor. Otras instancias de DuckDB se conectan a ella mediante HTTP simple y le envían sus lecturas y escrituras. Esto permite que varias aplicaciones interactúen con la base de datos de forma concurrente.
Es fundamental que el servidor siga siendo el único proceso que toca directamente el archivo de la base de datos. Esta arquitectura evita los problemas de la escritura multiproceso sin restricciones en el archivo, donde las cachés concurrentes podrían provocar corrupción. En su lugar, los clientes comparten el acceso a través de un coordinador, lo que garantiza la integridad de los datos y amplía la accesibilidad.
El equipo de DuckDB señaló que muchos usuarios ya estaban creando envoltorios personalizados o incluso ejecutando DuckDB dentro de PostgreSQLQL para lograr un acceso compartido ligero. Quack, que ahora es una función pulida en DuckDB 2.0, ofrece una solución nativa y con soporte oficial para este caso de uso habitual. Permite a los desarrolladores habilitar el acceso de varios clientes sin recurrir a soluciones alternativas a medida, a menudo frágiles.
Esta nueva capacidad de servidor no cambia la identidad central de DuckDB como base de datos analítica basada en archivos. Simplemente añade una opción nativa y robusta de acceso coordinado. Por ejemplo, DuckDB puede transferir 60 millones de filas entre dos máquinas en menos de 5 segundos usando Quack, superando con claridad al protocolo de PostgreSQLQL, que tardó más de 2,5 minutos en la misma tarea. Aunque las escrituras diminutas se estabilizan en torno a 5.500 por segundo con 8 hilos, esto es más que suficiente para varios servicios que comparten un panel.
Sesenta millones de filas en cinco segundos es lo que llama la atención
La demostración más llamativa de Quack tiene que ver con la velocidad de transferencia de datos. En un vídeo de Better Stack, el equipo de DuckDB envió 60 millones de filas entre dos máquinas en menos de cinco segundos usando Quack. A modo de comparación, el protocolo de PostgreSQLQL tardó más de dos minutos y medio (más de 150 segundos) en la misma operación.
Este benchmark pone de relieve la ventaja de Quack en cargas de trabajo analíticas. A diferencia de los protocolos tradicionales de bases de datos orientados a filas, Quack transfiere directamente por HTTP cargas de vectores de columnas nativas de DuckDB. Así evita la considerable sobrecarga de convertir datos orientados a columnas en formatos fila por fila y luego volver a convertirlos, algo habitual en muchos protocolos de red de bases de datos.
La mejora de velocidad es significativa en transferencias analíticas, donde mover grandes conjuntos de datos de forma eficiente es fundamental. Aunque es impresionante, recuerde que se trata de un benchmark reportado. El rendimiento en entornos reales puede variar según:
- Su carga de trabajo específica
- Las condiciones de red
- Las configuraciones de hardware
- Los tipos de consulta
Para profundizar en cómo Quack logra esto, incluidos sus principios de diseño, puede consultar la documentación oficial en Quack: The DuckDB Client-Server Protocol. Este protocolo supone un cambio radical, pero es esencial comprender sus fortalezas y limitaciones específicas para su caso de uso.
¿Te está gustando? Recibe uno así en tu bandeja cada mañana.
un correo al día · date de baja en dos clics · sin rastreadores de terceros
El techo de 5.500 escrituras indica cuándo detenerse
Quack destaca moviendo grandes conjuntos de datos analíticos, pero es fundamental entender sus límites en cargas transaccionales. Los benchmarks muestran que el modo servidor de DuckDB supera a PostgreSQLQL en escrituras pequeñas hasta aproximadamente ocho hilos concurrentes. A partir de ahí, el rendimiento se estabiliza cerca de las 5.500 escrituras por segundo.
Este techo existe porque el servidor de DuckDB, aunque admite varios clientes, sigue dependiendo de un único proceso para gestionar todas las escrituras en el archivo. Piense en un único cajero muy eficiente que atiende a muchos clientes: solo puede procesar un determinado número de transacciones por segundo.
Esta arquitectura es ideal para analítica compartida, paneles y servicios que se benefician de un centro DuckDB central y sencillo, especialmente cuando se prioriza el movimiento rápido de datos en bloque. Agiliza la ingesta de datos y las consultas complejas entre aplicaciones.
Sin embargo, los sistemas transaccionales de alta frecuencia, en los que cada escritura debe procesarse al instante y de forma concurrente, encontrarán limitante este cuello de botella de proceso único. Para esos escenarios exigentes de OLTP (procesamiento de transacciones en línea), PostgreSQLQL u otra base de datos OLTP dedicada sigue siendo la opción más adecuada. DuckDB 2.0 también incluye otras mejoras de almacenamiento y consultas, pero el diseño de Quack es la consideración clave para las escrituras concurrentes.
Preguntas frecuentes
¿Qué es Quack en DuckDB 2.0?
Quack es el protocolo cliente-servidor de DuckDB. Permite que las instancias cliente envíen consultas y escrituras por HTTP a un proceso de DuckDB que es propietario del archivo de la base de datos.
¿Pueden varias aplicaciones escribir en la misma base de datos de DuckDB?
Sí. Con Quack, varios clientes pueden enviar trabajo a una única instancia de servidor, que es el único proceso que accede directamente al archivo de la base de datos.
¿DuckDB 2.0 reemplaza a PostgreSQL?
No. El modo servidor de DuckDB es adecuado para analítica compartida y cargas de escritura moderadas; PostgreSQL suele ser más apropiado para cargas transaccionales exigentes y de alta concurrencia.
¿Qué tan rápido es DuckDB Quack?
El vídeo informa de la transferencia de 60 millones de filas entre dos máquinas en menos de cinco segundos. Según se indica, el rendimiento de escrituras pequeñas se estabiliza en torno a 5.500 escrituras por segundo.