QuestDB 演算法交易實戰：讀懂市場語言的架構設計

第 1 篇，共 3 篇 — 也可閱讀 RU · EN

免責聲明：本文內容僅供教育和參考目的，不構成任何財務、投資或交易建議。加密貨幣交易存在重大虧損風險。

大家好！今天我們開啟一個關於 QuestDB 的三篇系列深度解析——QuestDB 是一款開源時序資料庫，正在悄然成為現代交易基礎設施的核心支柱。這不是又一篇"十大數據庫"的盤點文章，我們將深入技術細節，因為演算法交易就是這樣要求的。

如果你曾為 InfluxDB 的高基數限制所困擾，在 TimescaleDB 處理 tick 資料時的效能開銷上吃過虧，或者疑惑為何 PostgreSQL 無法跟上每秒百萬級寫入的速度——這個系列正是為你而寫。

為何時序資料庫對交易至關重要

每一個演算法交易系統——從簡單的網格機器人到完整的高頻交易引擎——都有同一個根本依賴：資料。具體而言，是以極高速度到達、需要即時查詢的時間有序資料。

傳統關係型資料庫並非為此而生。它們擅長 ACID 事務和跨規範化模式的複雜連線，但面對金融市場所特有的大量追加寫入、按時間分割槽的工作負載，卻力不從心。結果是你在與資料庫搏鬥，而非讓它為你服務。

時序資料庫顛覆了這一範式。它們假定你的資料帶有時間戳，資料大致按順序到達，並且查詢幾乎總是涉及時間範圍。QuestDB 在此基礎上更進一步——它是專門針對資本市場設計的。其工程團隊來自一線投資銀行（美國銀行、瑞銀、滙豐），這一點在每一個設計決策中都有所體現。

QuestDB 概覽

QuestDB 是一款採用零 GC Java、C++ 和 Rust 編寫的開源（Apache 2.0）時序資料庫。"零 GC"至關重要：核心引擎完全繞過 Java 的垃圾回收器，手動管理記憶體，從而消除了大多數 JVM 系統中令人頭痛的不可預測延遲抖動。

值得關注的關鍵效能特徵：

• 單臺伺服器每秒數百萬行的寫入吞吐量
• 通過 SIMD 指令向量化執行，實現亞毫秒級查詢延遲
• 原生納秒精度時間戳——對 tick 資料至關重要
• 針對冷熱資料最佳化的三層儲存架構
• 具備強大時序擴充的 SQL 介面

但原始數字只揭示了故事的一部分。QuestDB 對交易系統真正令人著迷的地方在於它如何儲存和查詢資料。

三層儲存引擎

這正是 QuestDB 架構優雅之處所在。資料流經三個不同的層次，每層針對不同的訪問模式進行最佳化：

第一層：WAL（預寫日誌）

寫入的資料首先進入預寫日誌（Write-Ahead Log）。這是超低延遲的追加寫入層。每次寫入在任何處理發生之前都會被持久化——在崩潰和斷電情況下保證資料不丟失。WAL 是純順序寫入的，這使其與現代 SSD 和 NVMe 驅動器完美契合。

對於交易系統，這意味著你的行情資料寫入管道可以毫無顧慮地向 QuestDB 高速寫入資料，無需擔心寫入放大或鎖爭用。無論是接收來自 50 家加密交易所的 WebSocket 更新，還是處理海量 FIX 訊息，WAL 都能全部吸納。

WAL 還會非同步地將資料傳送至物件儲存，使新副本能夠快速啟動並讀取相同的歷史記錄——這對於生產交易環境中的災難恢復至關重要。

第二層：列式儲存

非同步地，資料會被按時間排序、去重，並寫入 QuestDB 的原生列式格式。該格式按時間分割槽（根據資料量按小時、天、周或月分割槽），並可立即查詢。

列式佈局正是 QuestDB 查詢效能的關鍵所在。當你查詢過去一小時內 BTC-USD 的平均價格時，引擎只讀取相關時間分割槽中的 price 列，而非整行資料。結合跨多核的 SIMD 向量化執行，這帶來了亞毫秒級的查詢時間，使即時儀表板和即時策略計算成為可能。

每張表按列分別儲存為獨立檔案，固定大小型別每列一個檔案，可變大小型別（如 VARCHAR）使用兩個檔案。這種佈局專門針對時序分析中佔主導地位的順序掃描而設計。

第三層：物件儲存（Parquet）

這是成本管理與互操作性的交匯點。較舊的分割槽會自動轉換為 Apache Parquet 格式並傳送至物件儲存（S3、Azure Blob、GCS）。但——這是關鍵的創新——你仍然可以通過 QuestDB 的 SQL 介面透明地查詢它們。查詢規劃器無縫跨越三個層次。

對於演算法交易者，這意味著你可以在不支付 TB 級 SSD 儲存費用的情況下，讓多年的歷史 tick 資料隨時可用於回測。你的 Python 回測框架可以通過 Polars、Pandas 或 Spark 直接讀取相同的 Parquet 檔案，無需匯出資料庫。你的機器學習訓練管道可以通過 Arrow/ADBC 訪問相同資料進行記憶體處理。零供應商鎖定。

這與將資料鎖定在單一查詢介面背後的專有資料庫格式相比，是一個截然不同的價值主張。

交易資料的模式設計

QuestDB 的模式設計理念圍繞幾個與交易資料高度契合的關鍵概念展開：

指定時間戳

每張時序表都需要一個指定的時間戳列。這不僅僅是後設資料——它決定了物理儲存順序並支援分割槽裁剪。沒有它，你將失去 QuestDB 的大部分效能優勢：

CREATE TABLE trades (
  timestamp TIMESTAMP,
  symbol SYMBOL,
  side SYMBOL,
  price DOUBLE,
  quantity DOUBLE
) TIMESTAMP(timestamp) PARTITION BY DAY;

SYMBOL 型別

SYMBOL 型別是 QuestDB 對高基數字串問題的解答。"BTC-USD"或"ETH-USDT"等交易對以整數索引字典條目的形式儲存。在 SYMBOL 列上的過濾和分組比在 VARCHAR 上快得多——QuestDB 在編譯時將字串比較解析為整數比較。

如果你在從 100 多家交易所寫入數以千計交易對的資料，僅這一最佳化就可能是查詢耗時 5 毫秒與 500 毫秒之間的差距。

分割槽策略

分割槽大小應與資料量相匹配。高頻 tick 資料（每天每個交易對數百萬行）應使用 PARTITION BY HOUR。低量的日終資料則使用 PARTITION BY MONTH 即可。目標是在保持單個分割槽可管理的同時實現高效裁剪：

-- 高频 tick 数据
CREATE TABLE ticks (...) TIMESTAMP(ts) PARTITION BY HOUR;

-- 低量日线价格
CREATE TABLE eod_prices (...) TIMESTAMP(ts) PARTITION BY MONTH;

資料去重

在真實的交易系統中，重複資料是不可避免的。網路重傳、為提高可靠性而建立的冗餘交易所連線、恢復期間歷史資料的重放——所有這些都會產生重複資料。QuestDB 原生處理這一問題：啟用後，去重會用新版本替換匹配的行，只有真正的新行才會被插入。

效能影響取決於你的資料模式。如果各行的時間戳大多唯一，開銷很小。最苛刻的情況是許多行共享相同時間戳並需要基於額外列進行去重——這在多個價格級別同時更新的訂單簿快照中很常見。

生產部署注意事項

QuestDB 的生產客戶包括 B3（拉丁美洲最大的證券交易所）、One Trading（受監管的加密交易所，每秒寫入量高達 400 萬行）、Laser Digital（野村集團），以及眾多一線銀行和對沖基金。

一些實際部署說明：

• QuestDB 支援 PostgreSQL 協議，大多數 PG 客戶端庫開箱即用
• 對於高吞吐量寫入，推薦通過 HTTP 或 TCP 使用 InfluxDB Line Protocol (ILP)
• 協議第 2 版（QuestDB 9.0+）為陣列和雙精度浮點數添加了二進位制編碼，顯著降低了頻寬和伺服器端處理開銷
• 自動建立表結構和併發模式變更，讓你能夠即時處理多個數據流並在執行中修改

企業版新增了 RBAC（包括列級許可權）、TLS 加密、自動複製和故障轉移、分級儲存到雲物件儲存，以及帶 SLA 的專屬支援。對於受監管的環境，這些是必備條件。

第 2 篇與第 3 篇預告

在第 2 篇中，我們將深入探討 QuestDB 的時序 SQL 擴充——SAMPLE BY、ASOF JOIN、HORIZON JOIN、WINDOW JOIN 和 LATEST ON——並附上真實的交易示例。這些不是對標準 SQL 的漸進式改進，而是從根本上不同的工具，能夠消除整類複雜查詢。

在第 3 篇中，我們將介紹實際交易應用：用於即時 OHLC 的物化檢視、用於訂單簿分析的 2D 陣列，以及基於 QuestDB 的演算法交易平臺完整架構。

敬請期待。

引用

@software{soloviov2025questdb_algotrading_p1,
  author = {Soloviov, Eugen},
  title = {QuestDB for Algorithmic Trading: Architecture That Speaks the Language of Markets},
  year = {2025},
  url = {https://marketmaker.cc/en/blog/post/questdb-algotrading-architecture},
  version = {0.1.0},
  description = {Deep dive into QuestDB's three-tier storage architecture and schema design for algorithmic trading systems.}
}