QuestDB cho Giao Dịch Thuật Toán: Từ Sổ Lệnh đến Kiến Trúc Sản Xuất

Phần 3/3 — cũng có sẵn bằng RU · ZH

Tuyên bố miễn trách: Thông tin được cung cấp trong bài viết này chỉ dành cho mục đích giáo dục và thông tin, không cấu thành tư vấn tài chính, đầu tư hoặc giao dịch. Giao dịch tiền điện tử liên quan đến rủi ro thua lỗ đáng kể.

Chào mừng đến với phần cuối của loạt bài về QuestDB. Trong Phần 1, chúng tôi đã đề cập đến kiến trúc lưu trữ. Trong Phần 2, chúng tôi đã khám phá các tiện ích mở rộng SQL. Bây giờ hãy tổng hợp tất cả lại: materialized views cho phân tích theo thời gian thực, lưu trữ sổ lệnh gốc với mảng 2D, và kiến trúc tham chiếu cho nền tảng giao dịch thuật toán trong môi trường sản xuất.

Materialized Views: Phân Tích Được Tính Toán Trước ở Tốc Độ Đường Truyền

Materialized views xếp tầng: dữ liệu tick thô chảy qua các lớp tổng hợp ngày càng thô hơn, mỗi cấp độ xử lý một tập dữ liệu nhỏ hơn đáng kể

Nếu SAMPLE BY là truy vấn được dùng nhiều nhất trong QuestDB, thì materialized views là tối ưu hóa có tác động lớn nhất. Khái niệm rất đơn giản: thay vì tính toán các tổng hợp OHLCV mỗi lần làm mới bảng điều khiển hoặc gọi API, hãy tính toán trước một lần và giữ kết quả được cập nhật liên tục.

Materialized View OHLC Cơ Bản

CREATE MATERIALIZED VIEW trades_OHLC_15m
  WITH BASE 'trades'
  REFRESH IMMEDIATE
AS
SELECT timestamp, symbol,
  first(price) AS open,
  max(price) AS high,
  min(price) AS low,
  last(price) AS close,
  sum(quantity) AS volume
FROM trades
SAMPLE BY 15m;

Đó là toàn bộ định nghĩa. Mỗi khi các hàng mới được chèn vào bảng trades, QuestDB tự động và tăng dần làm mới view này. Không phải tính toán lại toàn bộ — chỉ các nhóm thời gian bị ảnh hưởng mới được cập nhật. Các truy vấn đối với trades_OHLC_15m trở thành các tra cứu đơn giản trên tập dữ liệu nhỏ hơn nhiều, đã được tổng hợp trước.

Sự khác biệt về hiệu suất rất đáng kể. Trên một bảng có hàng tỷ hàng, truy vấn bảng gốc để lấy dữ liệu OHLC có thể mất 200ms. Materialized view trả về kết quả tương tự trong chưa đến 5ms. Với nhiều người dùng bảng điều khiển đồng thời, đây không chỉ là tối ưu hóa — đây là sự khác biệt giữa một hệ thống phản hồi nhanh và một hệ thống bị sụp đổ.

Views Xếp Tầng: Đa Khung Thời Gian từ Một Nguồn Duy Nhất

Đây là lúc materialized views trở nên tinh tế về mặt kiến trúc. Bạn có thể kết nối chúng theo chuỗi — mỗi view cung cấp cho view tiếp theo, tạo ra một hệ thống phân cấp các cấp độ tổng hợp từ một nguồn dữ liệu thô duy nhất:

-- Nến 1 giây từ giao dịch thô
CREATE MATERIALIZED VIEW ohlc_1s AS
SELECT timestamp, symbol,
  first(price) AS open, max(price) AS high,
  min(price) AS low, last(price) AS close,
  sum(quantity) AS volume
FROM trades
SAMPLE BY 1s;

-- Nến 5 giây từ nến 1 giây
CREATE MATERIALIZED VIEW ohlc_5s AS
SELECT timestamp, symbol,
  first(open) AS open, max(high) AS high,
  min(low) AS low, last(close) AS close,
  sum(volume) AS volume
FROM ohlc_1s
SAMPLE BY 5s;

-- Nến 1 phút từ nến 5 giây
CREATE MATERIALIZED VIEW ohlc_1m AS
SELECT timestamp, symbol,
  first(open) AS open, max(high) AS high,
  min(low) AS low, last(close) AS close,
  sum(volume) AS volume
FROM ohlc_5s
SAMPLE BY 1m;

Mỗi cấp độ xử lý một tập dữ liệu nhỏ hơn đáng kể so với cấp trước. View 1 phút không quét các giao dịch thô — nó chỉ đọc các nến 5 giây đã được tổng hợp trước. Mô hình xếp tầng này có thể mở rộng sang bất kỳ số khung thời gian nào: 1s → 5s → 1m → 5m → 15m → 1h → 4h → 1d.

Đối với nền tảng dữ liệu crypto thu thập từ 100+ sàn giao dịch, đây là xương sống của toàn bộ pipeline phân phối OHLC.

Chiến Lược Làm Mới

QuestDB cung cấp ba chế độ làm mới, mỗi chế độ phù hợp với các khối lượng công việc khác nhau:

REFRESH IMMEDIATE kích hoạt làm mới không đồng bộ sau mỗi giao dịch bảng gốc. Tốt nhất cho bảng điều khiển theo thời gian thực khi độ trễ dưới giây rất quan trọng.

REFRESH EVERY 1h (dựa trên bộ đếm giờ) gom các cập nhật vào các lần làm mới định kỳ. Tốt hơn cho việc nhập dữ liệu thông lượng cao khi kích hoạt làm mới trên mỗi micro-batch sẽ tạo ra chi phí phụ.

REFRESH PERIOD (LENGTH 1d TIME ZONE 'Europe/London' DELAY 2h) xác định các khoảng thời gian căn chỉnh theo lịch. "Độ trễ" tính đến dữ liệu đến muộn — rất quan trọng đối với các thị trường có thể gửi dữ liệu hiệu chỉnh nhiều giờ sau phiên giao dịch.

REFRESH MANUAL cho phép kiểm soát hoàn toàn. View chỉ cập nhật khi bạn chạy lệnh REFRESH một cách rõ ràng — hữu ích cho các quy trình đối chiếu cuối ngày.

Mô Hình Tăng Tốc LATEST ON

Một trong những mô hình mạnh mẽ nhất kết hợp materialized views với LATEST ON để có ảnh chụp nhanh danh mục đầu tư tức thì. Quét 1,3 tỷ hàng thô để lấy giá mới nhất của mỗi ký hiệu mất vài giây. Nhưng với view được tổng hợp trước theo ngày:

CREATE MATERIALIZED VIEW trades_latest_1d AS
SELECT timestamp, symbol, side,
  last(price) AS price,
  last(quantity) AS quantity,
  last(timestamp) AS latest
FROM trades
SAMPLE BY 1d;

Truy vấn LATEST ON quét khoảng 25.000 hàng đã được tổng hợp trước thay vì hàng tỷ hàng:

SELECT symbol, side, price, quantity, latest AS timestamp
FROM (
  trades_latest_1d
  LATEST ON timestamp PARTITION BY symbol, side
)
ORDER BY timestamp DESC;

Từ vài giây xuống còn mili giây. Đây là cách các bảng điều khiển giao dịch sản xuất đạt được khả năng phản hồi theo thời gian thực trên các tập dữ liệu khổng lồ.

TTL: Vòng Đời Dữ Liệu Tự Động

Materialized views hỗ trợ các chính sách TTL (time-to-live) để tự động hết hạn dữ liệu:

CREATE MATERIALIZED VIEW ohlc_1h AS (
  SELECT timestamp, symbol,
    avg(price) AS avg_price
  FROM trades
  SAMPLE BY 1h
) PARTITION BY WEEK TTL 8 WEEKS;

Điều này giữ 8 tuần dữ liệu theo giờ, tự động xóa các phân vùng cũ hơn. Kết hợp với công cụ lưu trữ ba tầng, bạn có được vòng đời dữ liệu tự nhiên: các tick thô chảy qua WAL → lưu trữ cột → Parquet trên object storage, trong khi materialized views duy trì các bản tóm tắt đã được tổng hợp trước mà các ứng dụng của bạn thực sự truy vấn.

Mảng 2D: Phân Tích Sổ Lệnh Gốc

Độ sâu sổ lệnh 3D: các mức giá mua và bán được lưu trữ dưới dạng mảng 2D gốc, cho phép tính toán spread được tối ưu hóa SIMD và phân tích thanh khoản

QuestDB 9.0 đã giới thiệu mảng N chiều — các mảng có hình dạng và bước đi thực sự giống NumPy xử lý các thao tác phổ biến (cắt lát, hoán vị) mà không cần sao chép. Đối với giao dịch, ứng dụng nổi bật là lưu trữ sổ lệnh.

Vấn Đề Truyền Thống

Về mặt lịch sử, việc lưu trữ ảnh chụp nhanh sổ lệnh trong cơ sở dữ liệu quan hệ rất khó khăn. Bạn có hai lựa chọn: một hàng mỗi mức giá (bùng nổ số hàng, tốn kém khi truy vấn độ sâu), hoặc số cột cố định như bid1_price, bid1_size, bid2_price, bid2_size, v.v. (cứng nhắc, lãng phí, và xấu xí).

Mảng 2D của QuestDB loại bỏ cả hai vấn đề:

CREATE TABLE market_data (
  timestamp TIMESTAMP,
  symbol SYMBOL,
  bids DOUBLE[][],
  asks DOUBLE[][]
) TIMESTAMP(timestamp) PARTITION BY HOUR;

Mỗi cột bids và asks lưu trữ một mảng 2D trong đó hàng đầu tiên chứa giá và hàng thứ hai chứa khối lượng ở mỗi mức. Sổ lệnh 20 mức là một mảng nhỏ gọn duy nhất, không phải 40 cột riêng biệt.

Phân Tích Sổ Lệnh trong SQL

Tính spread — chỉ số cơ bản nhất và được tính toán thường xuyên nhất:

SELECT timestamp,
  spread(bids[1][1], asks[1][1]) AS spread
FROM market_data
WHERE symbol = 'EURUSD'
  AND timestamp IN today();

Hàm spread() là hàm tích hợp tính toán sự chênh lệch giữa giá mua tốt nhất và giá bán tốt nhất. bids[1][1] truy cập phần tử đầu tiên (giá tốt nhất) của hàng đầu tiên (giá) trong mảng bids.

Để phân tích tinh vi hơn — độ sâu thanh khoản, mất cân bằng sổ lệnh, xác suất thực thi tại một mức giá nhất định — việc cắt lát mảng và các thao tác vector hóa làm cho các truy vấn phức tạp trước đây trở nên đơn giản:

-- Tìm mức mà giá mục tiêu sẽ bị chạm
-- và tổng tất cả khối lượng lên đến mức đó
DECLARE @target := bids[1][1] * 1.01;
SELECT timestamp,
  array_sum(asks[2][1:level_idx]) AS volume_to_fill
FROM market_data
WHERE symbol = 'EURUSD';

Các thao tác mảng được tối ưu hóa SIMD có nghĩa là các tính toán này chạy ở tốc độ gần phần cứng, ngay cả trên hàng triệu ảnh chụp nhanh.

Nhập Dữ Liệu Mảng

Các thư viện client của QuestDB hỗ trợ nhập mảng gốc. Client Python tích hợp trực tiếp với mảng NumPy:

import numpy as np
from questdb.ingress import Sender

bids = np.array([[9.3, 9.2, 9.1], [100, 200, 150]])  # prices, volumes
asks = np.array([[9.5, 9.6, 9.7], [80, 160, 120]])

with Sender.from_conf("http::addr=localhost:9000;") as sender:
    sender.row(
        'market_data',
        symbols={'symbol': 'EURUSD'},
        columns={'bids': bids, 'asks': asks},
        at=timestamp
    )

Protocol Version 2 mã hóa mảng ở dạng nhị phân, giảm đáng kể băng thông và chi phí phân tích cú pháp phía máy chủ so với các giao thức dựa trên văn bản. Đối với việc nhập sổ lệnh tần suất cao — khi bạn có thể nhận hàng nghìn ảnh chụp nhanh mỗi giây cho mỗi ký hiệu — hiệu quả này rất quan trọng.

Các client C/C++ sử dụng mảng phẳng theo hàng với các bộ mô tả hình dạng, cho phép nhập không sao chép từ các cấu trúc dữ liệu hệ thống giao dịch hiện có.

Tổng Hợp Tất Cả Lại: Kiến Trúc Tham Chiếu

Kiến trúc tham chiếu: các đầu nối sàn giao dịch, lõi cơ sở dữ liệu cột, lớp phân tích, công cụ chiến lược, và bảng điều khiển giám sát — tất cả được kết nối với nhau

Hãy thiết kế một nền tảng giao dịch thuật toán hoàn chỉnh được hỗ trợ bởi QuestDB cho thị trường crypto. Kiến trúc này xử lý việc nhập dữ liệu từ nhiều sàn giao dịch, phân tích theo thời gian thực, kiểm thử lịch sử và thực thi chiến lược.

Lớp Nhập Dữ Liệu

Nhập dữ liệu: nhiều đầu nối sàn giao dịch cung cấp dữ liệu thị trường theo thời gian thực qua các pipeline WebSocket vào QuestDB thông qua ILP

Nhiều kết nối WebSocket đến các sàn giao dịch (Binance, Bybit, OKX, v.v.) cung cấp dữ liệu thị trường thô vào QuestDB qua ILP qua HTTP. Mỗi đầu nối sàn giao dịch là một tiến trình riêng biệt, cung cấp sự cô lập và khả năng chịu lỗi.

Các luồng dữ liệu bao gồm: giao dịch (timestamp, symbol, side, price, quantity), ảnh chụp nhanh sổ lệnh (timestamp, symbol, bids[][], asks[][]), và tỷ lệ tài trợ/thanh lý như các luồng phụ trợ.

Mục tiêu thông lượng nhập: hàng triệu hàng mỗi giây trên tất cả các sàn giao dịch kết hợp. WAL của QuestDB xử lý điều này thoải mái, với tính năng khử trùng lặp bắt các bản sao không thể tránh khỏi từ các kết nối sàn giao dịch dư thừa.

Lớp Phân Tích Theo Thời Gian Thực

Materialized views tạo thành lõi của lớp phân tích:

Raw trades → ohlc_1s → ohlc_5s → ohlc_1m → ohlc_5m → ohlc_15m → ohlc_1h → ohlc_1d

Mỗi cấp độ làm mới tăng dần. Bảng điều khiển Grafana được kết nối qua plugin gốc của QuestDB truy vấn các view này cho biểu đồ nến, với thời gian phản hồi dưới 5ms bất kể lượng dữ liệu lịch sử tồn tại.

Các materialized view bổ sung tính toán: VWAP (giá trung bình theo trọng số khối lượng) mỗi ký hiệu mỗi ngày, ước tính biến động cuộn, và giám sát spread xuyên sàn.

Các truy vấn LATEST ON đối với các view đã được tổng hợp trước hỗ trợ bảng điều khiển danh mục đầu tư theo thời gian thực — hiển thị các vị thế hiện tại, P&L chưa thực hiện, và mức độ phơi nhiễm theo từng sàn.

Công Cụ Chiến Lược

Công cụ chiến lược: tính toán chỉ báo theo thời gian thực cung cấp cho việc ra quyết định theo thuật toán, với các đường dẫn thực thi mua/bán được tối ưu hóa bởi materialized views

Các chiến lược giao dịch truy vấn QuestDB để biết trạng thái thị trường hiện tại và các mô hình lịch sử. Giao thức PG wire của QuestDB có nghĩa là bất kỳ ngôn ngữ nào có driver PostgreSQL đều có thể kết nối: Python cho các chiến lược nghiên cứu, Rust hoặc C++ cho việc thực thi nhạy cảm với độ trễ.

Các mô hình truy vấn chính cho chiến lược: ASOF JOIN để khớp các lệnh thực thi với điều kiện thị trường tại thời điểm lệnh được điền, WINDOW JOIN để tính toán các chỉ số ngắn hạn xung quanh mỗi sự kiện, và các hàm cửa sổ để tính toán chỉ báo theo thời gian thực (RSI, Bollinger Bands, ATR).

Đối với các chiến lược nhạy cảm với độ trễ, các materialized view được tính toán trước giảm thiểu thời gian truy vấn. Một grid bot theo dõi 50 ký hiệu không cần tính toán 50 đường trung bình động riêng biệt trên mỗi tick — nó đọc chúng từ materialized view.

Pipeline Kiểm Thử Lịch Sử

Dữ liệu lịch sử sống trong Parquet trên object storage. QuestDB truy vấn nó một cách trong suốt, nhưng đối với các khối lượng công việc kiểm thử lịch sử nặng, dữ liệu cũng có thể được đọc trực tiếp bởi Polars, Pandas, hoặc DuckDB — bỏ qua cơ sở dữ liệu hoàn toàn.

Mô hình truy cập kép này rất mạnh mẽ: chiến lược trực tiếp sử dụng giao diện SQL của QuestDB cho các quyết định theo thời gian thực, trong khi khung kiểm thử lịch sử đọc cùng dữ liệu thông qua Parquet/Arrow để xử lý theo lô. Cùng một dữ liệu, hai đường dẫn truy cập được tối ưu hóa.

Giám Sát và Phân Tích Sau Giao Dịch

HORIZON JOIN hỗ trợ pipeline phân tích sau giao dịch:

• Phân tích trượt giá: So sánh giá thực thi với giá trung gian tại thời điểm lệnh được điền
• Đường cong markout: Theo dõi sự phát triển giá 1s, 5s, 30s, 60s sau mỗi lệnh được điền
• Thiếu hụt thực hiện: Phân tách chi phí thực thi thành spread, tác động tạm thời, và tác động vĩnh viễn
• Chấm điểm sàn: So sánh chất lượng lệnh được điền trên các sàn giao dịch để tối ưu hóa định tuyến lệnh

Các phân tích này chạy như các truy vấn theo lịch, ghi kết quả vào các bảng chuyên dụng cung cấp cho bảng điều khiển giám sát. Các quy tắc cảnh báo kích hoạt khi có bất thường — đột ngột tăng trượt giá, các mô hình markout bất thường, hoặc chất lượng lệnh được điền giảm sút trên các sàn cụ thể.

Cân Nhắc Hiệu Suất

Điều chỉnh hiệu suất sản xuất: giám sát độ trễ, thông lượng và bộ nhớ cùng với vòng đời dữ liệu hot-warm-cold

Một số ghi chú thực tế từ các triển khai sản xuất:

Kích thước phân vùng: Đối với dữ liệu tick crypto với hàng triệu hàng mỗi ngày, PARTITION BY HOUR thường là tối ưu. Điều này giữ các phân vùng riêng lẻ có thể quản lý được cho cả hiệu suất lưu trữ và truy vấn.

Xếp tầng materialized view: Đừng tạo quá nhiều cấp trung gian. Mỗi cấp thêm độ trễ làm mới. Đối với hầu hết các trường hợp sử dụng, 3-4 cấp (1s → 1m → 15m → 1d) cung cấp sự cân bằng tốt giữa hiệu suất truy vấn và độ tươi mới của dữ liệu.

Chi phí khử trùng lặp: Bật tính năng khử trùng lặp trên các bảng có nguồn dữ liệu dư thừa. Chi phí là tối thiểu cho dữ liệu có timestamp duy nhất nhưng tăng lên với nhiều hàng có cùng timestamp cần khử trùng lặp ở cấp độ cột.

Phân bổ bộ nhớ: Engine không GC của QuestDB hiệu quả, nhưng hãy phân bổ đủ bộ nhớ cho các phân vùng nóng và bộ đệm ghi. Giám sát qua endpoint metrics tích hợp.

Lựa chọn giao thức client: Sử dụng ILP qua HTTP để nhập dữ liệu (với các lần thử lại tự động và kiểm tra tình trạng). Sử dụng PG wire cho các truy vấn. ILP Protocol Version 2 (mã hóa nhị phân) hiệu quả hơn đáng kể cho dữ liệu mảng và các giá trị double thông lượng cao.

QuestDB so với Các Giải Pháp Thay Thế

Bối cảnh cạnh tranh: QuestDB được định vị so với TimescaleDB, ClickHouse, InfluxDB, và kdb+ trên các chiều năng lực chính

Một so sánh ngắn gọn với các cơ sở dữ liệu thường được sử dụng trong giao dịch:

vs. TimescaleDB: TimescaleDB là PostgreSQL với các tiện ích mở rộng time-series. Nó kế thừa tính tổng quát của PG nhưng cũng kế thừa chi phí của nó. Engine cột gốc của QuestDB và thực thi SIMD cung cấp hiệu suất truy vấn tốt hơn đáng kể trên các khối lượng công việc time-series, và các tính năng như ASOF JOIN không có tương đương trực tiếp trong TimescaleDB.

vs. ClickHouse: ClickHouse xuất sắc trong các truy vấn phân tích trên các tập dữ liệu lớn. Nhưng nó không được thiết kế đặc biệt cho time-series — không có ASOF JOIN gốc, không có SAMPLE BY với FILL, không có mảng 2D cho sổ lệnh. Đối với các khối lượng công việc OLAP + time-series hỗn hợp, ClickHouse có thể thắng; đối với dữ liệu giao dịch thuần túy, QuestDB tiện dụng hơn.

vs. InfluxDB: InfluxDB có các hạn chế về cardinality cao gây khó chịu cho dữ liệu crypto đa sàn. Ngôn ngữ truy vấn của nó (Flux, hiện đã bị loại bỏ; InfluxQL) thiếu tính biểu đạt của các tiện ích mở rộng SQL của QuestDB. Hiệu suất trên các truy vấn lịch sử lớn thường kém hơn.

vs. kdb+/q: Tiêu chuẩn vàng cho HFT. kdb+ nhanh hơn cho một số thao tác vector đơn luồng nhất định và ngôn ngữ q của nó cực kỳ súc tích. Nhưng nó là độc quyền, đắt tiền, và có đường cong học tập dốc. QuestDB cung cấp 80-90% khả năng với một phần chi phí, với SQL tiêu chuẩn và cấp phép mã nguồn mở.

Kết Luận: Cơ Sở Dữ Liệu Hiểu Giao Dịch

Qua ba bài viết này, chúng tôi đã đề cập đến kiến trúc của QuestDB (lưu trữ ba tầng với WAL, cột, và Parquet), các tiện ích mở rộng SQL của nó (SAMPLE BY, ASOF JOIN, HORIZON JOIN, WINDOW JOIN, LATEST ON, TWAP), và các ứng dụng thực tế của nó (materialized views, mảng sổ lệnh, kiến trúc tham chiếu).

Chủ đề xuyên suốt là nhất quán: QuestDB được thiết kế cho chính xác các khối lượng công việc mà giao dịch thuật toán tạo ra. Nó không buộc bạn phải làm việc xung quanh cơ sở dữ liệu — thay vào đó, các nguyên thủy của nó ánh xạ trực tiếp đến các khái niệm giao dịch. Tổng hợp OHLC chỉ là một dòng. Căn chỉnh giao dịch với báo giá là một JOIN duy nhất. Phân tích sau giao dịch là một HORIZON JOIN, không phải một thủ tục PL/SQL nhiều trang.

Đối với các nhóm xây dựng cơ sở hạ tầng giao dịch — dù là nền tảng dữ liệu thị trường crypto, môi trường nghiên cứu định lượng, hay công cụ giao dịch thuật toán đầy đủ — QuestDB xứng đáng được đánh giá nghiêm túc. Phiên bản mã nguồn mở bao gồm hầu hết các trường hợp sử dụng, và phiên bản Enterprise lấp đầy những khoảng trống cho các môi trường được quản lý.

Bối cảnh cơ sở hạ tầng dữ liệu tài chính đang phát triển nhanh chóng. Các cơ sở dữ liệu nói ngôn ngữ của thị trường sẽ thắng. QuestDB thành thạo ngôn ngữ đó.

Chúc giao dịch vui vẻ, và mong rằng độ trễ của bạn luôn thấp.

Trích Dẫn

@software{soloviov2025questdb_algotrading_p3,
  author = {Soloviov, Eugen},
  title = {QuestDB for Algorithmic Trading: From Order Books to Production Architecture},
  year = {2025},
  url = {https://marketmaker.cc/vi/blog/post/questdb-algotrading-production},
  version = {0.1.0},
  description = {Materialized views, phân tích sổ lệnh mảng 2D, và kiến trúc tham chiếu cho nền tảng giao dịch thuật toán được xây dựng trên QuestDB.}
}