GaiaEx AcademyGaiaEx Academy
KDB+/Q: el lenguaje de las bases de datos de ticks
DesarrolladorProgramación11 min read

KDB+/Q: el lenguaje de las bases de datos de ticks

Cómo Wall Street almacena y consulta miles de millones de datos de mercado

Compartir Publicaciones

KDB+ y Q en un minuto

KDB+ es una base de datos de series temporales orientada a columnas; Q es su lenguaje vectorial. Las firmas del sell-side y del buy-side lo adoptaron para el almacenamiento de ticks, los joins y la analítica en ventana móvil (rolling), donde escanear columnas gana a los bucles fila por fila.

El rendimiento viene de la organización columnar, un uso agresivo del mapeo de memoria y primitivas vectoriales implementadas muy cerca del hardware. No es un sustituto general de OLTP; está optimizado para series temporales con muchas inserciones (append-heavy).

Organización columnar (conceptual) sym A A B time t₁ t₂ t₃ price p₁ p₂ p₃ Las operaciones vectoriales tocan arrays contiguos → escaneos favorables a la caché El esquema y los tipos siguen importando: listas de sym mal hechas cuestan espacio
Las tablas son vectores de columnas; la analítica filtra y agrega a lo largo de columnas y del tiempo.

Fundamentos de Q

Q es conciso y se evalúa de derecha a izquierda. Los vectores son nativos; existen bucles, pero las rutas críticas los evitan. Las tablas son diccionarios de columnas, lo cual encaja con la forma en que se almacenan los datos de ticks.

prices: 100.5 101.2 99.8
avg prices
deltas prices

Un Q legible viene de funciones pequeñas y comentarios: la densidad por sí sola no es una virtud en bases de código compartidas.

Tickerplant, RDB, HDB

Un patrón habitual: un tickerplant ingesta los feeds y los distribuye a los suscriptores; una base de datos en tiempo real (RDB) guarda la sesión actual; una base de datos histórica (HDB) almacena el histórico particionado en disco. Los procesos de fin de día trasladan (roll) los datos de la RDB a las particiones de la HDB.

select last price by sym from trades where time > .z.t - 00:05

Las criptomonedas no cierran nunca, así que los límites de «sesión» son decisiones operativas, no campanas de un exchange.

Pipeline de ticks (el clásico de tres piezas) Manejadores de feed Normalizan los símbolos Marca de tiempo en el límite Tickerplant Registro + publicación/suscripción Sin almacenamiento a largo plazo RDB + HDB Intradía frente a histórico Particionado por fecha La recuperación de huecos usa los registros; verifica los huecos del feed y las correcciones tardías Los feeds de cripto pueden ir a rachas: dimensiona buffers y contrapresión (back-pressure)
Separar lo que es en tiempo real de lo histórico mantiene las rutas críticas pequeñas y las consultas predecibles.

Dónde aparece

Las firmas usan KDB+ para paneles de vigilancia, analítica de cotizaciones y conjuntos de datos de investigación. Los nombres y despliegues varían; el patrón es la segmentación y el análisis rápido (slice-and-dice) sobre ticks y órdenes.

Los mercados de cripto generan datos continuos: planifica la retención, la reproducción (replay) y la exportación para cumplimiento normativo desde el principio.

Coste de licencia y alternativas

La licencia comercial y la contratación de personal especializado son costes reales. Las alternativas abiertas (ClickHouse, Timescale, QuestDB, DuckDB sobre Parquet) cambian ajuste al ecosistema por precio. Haz el benchmark sobre tu propia mezcla de consultas, no sobre las presentaciones de los proveedores.

Stacks de ticks en cripto

Muchos equipos combinan Kafka o Redpanda con almacenamiento columnar y motores SQL. El invariante de KDB+ sigue aplicando: particiona por tiempo, mantén los esquemas estrictos y mide el retraso (lag) de extremo a extremo desde la marca de tiempo del exchange hasta el resultado de la consulta.

Los usuarios de la API de GaiaEx deberían registrar las marcas de tiempo del servidor y los identificadores de secuencia si están expuestos: la correlación gana a la especulación.