開發者程式設計11 min read

KDB+/Q：tick 資料庫的語言

華爾街如何儲存與查詢數十億條市場資料

分享文章

一分鐘看懂 KDB+ 與 Q

KDB+ 是一款面向列的時序資料庫；Q 是它的向量語言。賣方和買方機構用它來做 tick 資料儲存、表連線，以及滾動分析——在這些場景下，按列掃描比逐行迴圈更快。

它的效能來自列式佈局、對記憶體對映的激進運用，以及貼近底層實現的向量原語。它並不是通用 OLTP 的替代品；它專為以追加為主的時序資料調優。

表就是列向量；分析沿著列與時間做過濾和聚合。

Q 簡潔，且從右向左求值。向量是原生型別；迴圈雖然存在，但熱點路徑會避開它們。表是列的字典，這正好契合 tick 資料的儲存方式。

prices: 100.5 101.2 99.8
avg prices
deltas prices

可讀的 Q 程式碼來自小函式和註釋——在共享程式碼庫裡，單純追求程式碼密度並不是優點。

一種常見的模式：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 的使用者如果能拿到伺服器時間戳和序列識別符號，就應該把它們記錄下來——做關聯遠勝於靠猜。