Motores analíticos en el cliente: consultar columnas en el navegador

Todas las familias vistas hasta aquí comparten una suposición tan arraigada que rara vez se enuncia: que la unidad de trabajo es el registro. Guardas registros, lees registros, recorres registros. Esa suposición es correcta para la inmensa mayoría de las aplicaciones, porque la inmensa mayoría de las aplicaciones manipulan entidades una a una. Pero existe una clase de trabajo con datos donde el registro es la unidad equivocada y donde razonar así condena a un rendimiento pésimo: aquella en la que la pregunta no es dame este documento sino cuánto suma esta columna agrupada por aquella otra. Para esa clase de trabajo existe una familia entera de motores construidos sobre una representación distinta, y desde hace años uno de ellos vive dentro del navegador. Conviene entender qué hace diferente, qué cuesta y, sobre todo, para qué aplicación tiene sentido pagar ese coste.

Qué cambia cuando el motor es columnar

La diferencia empieza en el disco y termina en la caché del procesador. Un motor orientado a registros guarda juntos todos los campos de una fila, de modo que leer una fila entera es barato y leer un solo campo de un millón de filas obliga a tocar el millón de filas completas. Un motor columnar guarda juntos todos los valores de una misma columna, con lo que la segunda operación toca únicamente los bytes que necesita, y además esos bytes son homogéneos —mismo tipo, valores parecidos— lo que los hace comprimibles con técnicas que un montón de registros heterogéneos no admite.

Encima de esa representación va un modelo de ejecución que la aprovecha. La documentación interna de DuckDB lo describe sin ambigüedad: el motor usa un modelo de ejecución vectorizado y todos sus operadores están optimizados para trabajar sobre vectores de tamaño fijo, con un tamaño estándar por defecto de 2048 tuplas. Los vectores admiten además varias representaciones físicas para los mismos datos lógicos —plana, constante, de diccionario, de secuencia— de manera que un valor repetido se almacena una sola vez y un segmento comprimido por diccionario puede seguir comprimido durante la ejecución de la consulta.

flowchart TB
A[Consulta con filtro y agregacion] --> B[Lectura solo de las columnas citadas]
B --> C[Vectores de tamano fijo]
C --> D[Operadores que procesan el vector entero]
D --> E[Resultado agregado]
B --> F[Columnas no citadas: nunca se tocan]
C --> G[Representaciones comprimidas que sobreviven a la ejecucion]
style C fill:#cba6f7,color:#11111b
style E fill:#a6e3a1,color:#11111b
style F fill:#89b4fa,color:#11111b

Ese último punto merece subrayarse porque es contraintuitivo y es donde se gana la mayor parte del rendimiento. En un sistema orientado a registros, la compresión es una técnica de almacenamiento: se comprime al escribir y se descomprime al leer, de modo que el motor siempre trabaja sobre datos expandidos. En un sistema columnar con representaciones físicas alternativas, un segmento comprimido por diccionario puede seguir comprimido mientras se ejecuta la consulta, con lo que la compresión deja de ser un ahorro de disco y pasa a ser un ahorro de trabajo: menos bytes que mover entre la memoria y el procesador, menos comparaciones que hacer, y una densidad de datos por línea de caché que un montón de registros heterogéneos no puede alcanzar. Es el mismo dato lógico, colocado de manera que la máquina real que lo procesa lo digiera mejor.

La consecuencia práctica es una inversión completa del perfil de coste. Recuperar un documento entero por su clave, que en un motor de registros es la operación más barata que existe, aquí es relativamente cara porque hay que reconstruir la fila desde columnas dispersas. Y sumar una columna de varios millones de valores con un filtro por otra, que en un motor de registros es una tragedia, aquí es la operación para la que la máquina fue diseñada. No es que uno sea mejor: es que resuelven preguntas opuestas.

El coste de entrada

Nada de esto es gratis, y las cifras hay que ponerlas encima de la mesa antes de decidir. La primera partida es el tamaño: un motor analítico completo compilado a WebAssembly no es una librería pequeña, y su descarga y compilación se pagan en el arranque, no en la primera consulta. La segunda es la memoria, y aquí la propia documentación de DuckDB es explícita al enumerar las limitaciones de su cliente WebAssembly: por defecto usa un único hilo, y WebAssembly limita la memoria disponible a cuatro gigabytes, límite que los navegadores pueden restringir todavía más. La tercera partida es la travesía de los datos entre el mundo de JavaScript y el montón lineal del módulo, que ya conoces de niveles anteriores y que aquí importa especialmente porque el volumen que se mueve es grande por definición.

Esa tercera partida es la que mejor se puede administrar, y la vía es no serializar. El cliente WebAssembly de DuckDB documenta un flujo en dos pasos: primero se registra el fichero en su sistema de ficheros virtual mediante funciones de registro, y después se importa con funciones de inserción o directamente desde una consulta.

// Ingestion desde Arrow: representacion columnar a ambos lados,
// sin convertir cada fila a objetos de JavaScript.
const c = await db.connect();
await c.insertArrowTable(tabla, { name: "eventos" });

// Un fichero elegido por el usuario, sin cargarlo entero en memoria.
await db.registerFileHandle(
  "local.parquet",
  ficheroElegido,
  DuckDBDataProtocol.BROWSER_FILEREADER,
  true,
);

await c.query(`CREATE TABLE hechos AS SELECT * FROM 'local.parquet'`);
await c.close(); // cerrar la conexion libera memoria

Merece la pena detenerse en por qué Arrow aparece aquí. Cuando el motor es columnar y el formato de intercambio también lo es, la ingestión deja de ser una traducción registro a registro y pasa a ser un traspaso de bloques de columnas. La travesía sigue existiendo, pero su coste deja de ser proporcional al número de campos y pasa a serlo al número de bytes, que es una función mucho más benigna. Elegir bien el formato de entrada suele mover el tiempo de carga más que cualquier ajuste posterior de la consulta.

Consultar lo que no has descargado

Hay una capacidad de esta familia que cambia la arquitectura más que el rendimiento, y es que la fuente de datos no tiene por qué estar en el dispositivo. La documentación del cliente WebAssembly describe una variante de su extensión de acceso por HTTP con la que se puede nombrar una dirección remota directamente en el texto de la consulta, y advierte de que si el fichero vive en un almacén de objetos habrá que configurar la cabecera de intercambio de recursos entre orígenes para que el navegador permita la lectura.

// La tabla no esta en el dispositivo: se consulta donde vive.
await c.query(`
  CREATE TABLE directa AS
    SELECT * FROM 'https://origen/remoto.parquet'
`);

// Y a partir de ahi, SQL analitico normal.
const r = await c.query(`
  SELECT categoria, count(*) AS n, sum(importe) AS total
  FROM directa
  WHERE fecha >= DATE '2026-01-01'
  GROUP BY categoria
  ORDER BY total DESC
`);

Lo interesante no es el ahorro de una descarga previa, sino lo que implica para el reparto de responsabilidades. La capa de análisis deja de necesitar un servicio que exponga un extremo por cada pregunta posible; basta con publicar ficheros en un formato columnar y dejar que el cliente formule las preguntas que quiera. Eso convierte una superficie de API que crecía con cada nueva vista en un artefacto estático que se regenera por lotes, y traslada al navegador el trabajo de agregar. Es un cambio de arquitectura de primer orden, y como todos los de su clase, no es gratis: quien puede formular cualquier pregunta también puede formular una carísima, y el límite de memoria del módulo es real.

Para qué aplicación tiene sentido

El perfil que justifica esta familia es reconocible y estrecho. Son aplicaciones donde el usuario explora: paneles de control interactivos, herramientas de análisis de registros, cuadernos de datos, exploradores de conjuntos publicados, cualquier cosa donde la siguiente pregunta la decide una persona mirando el resultado de la anterior. En ese régimen, el ida y vuelta al servidor no es solo latencia: es la diferencia entre explorar y consultar, porque una espera de un segundo entre pregunta y respuesta rompe el hilo de pensamiento que hace productiva la exploración. También son aplicaciones donde los datos son grandes, homogéneos y de solo lectura, y donde la privacidad puede ser una razón adicional de peso: analizar en el dispositivo significa que el conjunto no viaja.

El perfil que no lo justifica es todo lo demás, y en particular la aplicación de gestión que manipula entidades una a una, escribe con frecuencia y lee por clave. Ahí un motor analítico añade megabytes de descarga y una segunda copia del esquema a cambio de acelerar consultas que nunca vas a hacer.

Cuando una aplicación necesita ambas cosas —y muchas las necesitan— la forma sana no es buscar un motor que haga las dos bien, porque no existe, sino declarar dos piezas con responsabilidades disjuntas y un flujo explícito entre ellas.

// Pieza 1: el estado del usuario. Escrituras pequenas, lecturas por clave.
await almacen.guardar("pedidos", pedido);

// Pieza 2: el analisis. Solo lectura, reconstruible, vive en un worker.
// Se alimenta por lotes desde la pieza 1, nunca al reves.
async function refrescarAnalitica() {
  const filas = await almacen.exportarColumnar("pedidos");
  await analitica.reemplazarTabla("pedidos", filas);
}

// Y una propiedad de diseno que hay que preservar: si la pieza 2
// desaparece, la aplicacion sigue funcionando con menos vistas.

Esa última línea es el criterio que distingue una arquitectura de dos piezas de un acoplamiento con pasos extra. Si al borrar el motor analítico la aplicación deja de arrancar, no tienes dos piezas: tienes una sola con dos motores dentro, y has perdido la capacidad de degradar cuando el dispositivo no da para más.