GaiaEx AcademyGaiaEx Academy
KDB+/Q : le langage des bases de données tick
DéveloppeurProgrammation11 min read

KDB+/Q : le langage des bases de données tick

Comment Wall Street stocke et interroge des milliards de points de données de marché

Partager les articles

KDB+ et Q en une minute

KDB+ est une base de données de séries temporelles orientée colonnes ; Q est son langage vectoriel. Les entreprises côté vendeur (sell-side) et côté acheteur (buy-side) l'ont adopté pour le stockage de ticks, les jointures et l'analytique glissante là où le balayage de colonnes surpasse les boucles ligne par ligne.

La performance vient de la disposition en colonnes, d'un usage intensif de la projection mémoire (memory mapping), et de primitives vectorielles implémentées près du métal. Ce n'est pas un remplacement OLTP généraliste ; c'est optimisé pour des séries temporelles à ajout intensif.

Disposition en colonnes (conceptuel) sym A A B time t₁ t₂ t₃ price p₁ p₂ p₃ Les opérations vectorielles touchent des tableaux contigus → balayages cache-friendly Le schéma et les types comptent toujours : de mauvaises listes sym coûtent de l'espace
Les tables sont des vecteurs de colonnes ; l'analytique filtre et agrège le long des colonnes et du temps.

Bases de Q

Q est concis et s'évalue de droite à gauche. Les vecteurs sont natifs ; les boucles existent mais les chemins critiques les évitent. Les tables sont des dictionnaires de colonnes, ce qui correspond à la façon dont les données de tick sont stockées.

prices: 100.5 101.2 99.8
avg prices
deltas prices

Un Q lisible vient de petites fonctions et de commentaires — la densité seule n'est pas une vertu dans des bases de code partagées.

Tickerplant, RDB, HDB

Un schéma courant : un tickerplant ingère les flux et les diffuse vers des abonnés ; une base de données temps réel (RDB) détient la session en cours ; une base de données historique (HDB) stocke l'historique partitionné sur disque. Les processus de fin de journée basculent le RT vers les partitions HDB.

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

La crypto ne ferme jamais, donc les limites de « session » sont des choix opérationnels, pas des cloches de bourse.

Pipeline de ticks (trio classique) Gestionnaires de flux Normalisent les symboles Horodatage à la frontière Tickerplant Journal + pub/sub Pas de stockage long terme RDB + HDB Intrajournalier vs historique Partitionné par date La récupération des lacunes utilise les journaux ; vérifiez les trous de flux et corrections tardives Les flux crypto peuvent connaître des pics : dimensionnez tampons et contre-pression
La séparation entre temps réel et historique garde les chemins critiques légers et les requêtes prévisibles.

Où on le rencontre

Les entreprises utilisent KDB+ pour les tableaux de bord de surveillance, l'analytique de cotations, et les jeux de données de recherche. Les noms et déploiements varient ; le schéma est un découpage et une analyse rapides des ticks et des ordres.

Les plateformes crypto génèrent des données continues — planifiez la rétention, la relecture (replay) et l'export de conformité en amont.

Coût de licence et alternatives

Les licences commerciales et le recrutement spécialisé représentent des coûts réels. Les alternatives ouvertes (ClickHouse, Timescale, QuestDB, DuckDB sur Parquet) échangent l'adéquation à l'écosystème contre le prix. Benchmarkez sur votre propre mix de requêtes, pas sur les présentations des fournisseurs.

Piles de données de tick pour la crypto

De nombreuses équipes associent Kafka ou Redpanda à un stockage en colonnes et des moteurs SQL. L'invariant de KDB+ s'applique toujours : partitionnez par le temps, gardez des schémas stricts, et mesurez le décalage de bout en bout entre l'horodatage de la plateforme et le résultat de la requête.

Les consommateurs de l'API GaiaEx devraient journaliser les horodatages serveur et les identifiants de séquence si exposés — la corrélation vaut mieux que la supposition.