KDB+/Q：tick 数据库的语言

KDB+ 是一款面向列的时序数据库；Q 是它的向量语言。卖方和买方机构用它来做 tick 数据存储、表连接，以及滚动分析——在这些场景下，按列扫描比逐行循环更快。

它的性能来自列式布局、对内存映射的激进运用，以及贴近底层实现的向量原语。它并不是通用 OLTP 的替代品；它专为以追加为主的时序数据调优。

Q 简洁，且从右向左求值。向量是原生类型；循环虽然存在，但热点路径会避开它们。表是列的字典，这正好契合 tick 数据的存储方式。

prices: 100.5 101.2 99.8
avg prices
deltas prices

一种常见的模式：tickerplant 负责接入行情并分发给订阅者；实时数据库（RDB）保存当前交易时段的数据；历史数据库（HDB）在磁盘上以分区方式存储历史数据。日终流程会把实时数据滚入 HDB 分区。

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

加密市场从不收盘，所以「交易时段」的边界是运维上的选择，而不是交易所的开收盘铃声。

各家机构用 KDB+ 来做监控看板、报价分析和研究数据集。具体名称和部署方式各不相同，但模式都一样：对 tick 和订单做快速切片与多维分析。

加密交易场所会持续产生数据——请提前规划好数据保留、回放和合规导出。

商业许可和专业人才招聘都是实打实的成本。开源替代方案（ClickHouse、Timescale、QuestDB、基于 Parquet 的 DuckDB）用生态契合度换来更低的价格。请基于你自己的查询组合来做基准测试，而不是看厂商的宣传幻灯片。

许多团队把 Kafka 或 Redpanda 与列式存储和 SQL 引擎搭配使用。KDB+ 时代的那条不变法则依然适用：按时间分区、保持 schema 严格，并测量从交易所时间戳到查询结果的端到端延迟。

GaiaEx API 的使用者如果能拿到服务器时间戳和序列标识符，就应该把它们记录下来——做关联远胜于靠猜。