QuestDB untuk Dagangan Algoritma: Dari Buku Pesanan hingga Seni Bina Pengeluaran

Bahagian 3 daripada 3 — juga tersedia dalam RU · ZH

Penafian: Maklumat yang disediakan dalam artikel ini adalah untuk tujuan pendidikan dan maklumat sahaja dan tidak merupakan nasihat kewangan, pelaburan, atau dagangan. Perdagangan mata wang kripto melibatkan risiko kerugian yang ketara.

Selamat datang ke bahagian terakhir siri QuestDB kami. Dalam Bahagian 1, kami membincangkan seni bina storan. Dalam Bahagian 2, kami meneroka sambungan SQL. Sekarang mari kita satukan semuanya: pandangan terwujud untuk analitik masa nyata, storan buku pesanan asli dengan tatasusunan 2D, dan seni bina rujukan untuk platform dagangan algoritma pengeluaran.

Pandangan Terwujud: Analitik Pra-Kira pada Kelajuan Wayar

Pandangan terwujud beranting: data tik mentah mengalir melalui lapisan pengagregatan yang semakin kasar, setiap peringkat memproses set data yang jauh lebih kecil

Jika SAMPLE BY adalah pertanyaan paling kerap digunakan QuestDB, maka pandangan terwujud adalah pengoptimuman yang paling memberi impak. Konsepnya mudah: daripada mengira pengagregatan OHLCV pada setiap penyegaran papan pemuka atau panggilan API, kira ia sekali dan teruskan hasilnya dikemas kini secara berterusan.

Pandangan Terwujud OHLC Asas

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;

Itulah keseluruhan definisi. Setiap kali baris baru dimasukkan ke dalam jadual trades, QuestDB secara automatik dan bertambah menyegarkan pandangan ini. Bukan pengiraan semula penuh — hanya baldi masa yang terjejas yang dikemas kini. Pertanyaan terhadap trades_OHLC_15m menjadi carian mudah pada set data yang jauh lebih kecil dan telah diagregatkan terlebih dahulu.

Perbezaan prestasi adalah ketara. Pada jadual dengan berbilion baris, pertanyaan jadual asas untuk data OHLC mungkin mengambil masa 200ms. Pandangan terwujud mengembalikan hasil yang sama dalam masa kurang dari 5ms. Dengan berbilang pengguna papan pemuka serentak, ini bukan sekadar pengoptimuman — ia adalah perbezaan antara sistem yang responsif dan sistem yang gagal.

Pandangan Beranting: Berbilang Jangka Masa dari Satu Sumber

Di sinilah pandangan terwujud menjadi elegan dari segi seni bina. Anda boleh merantaikannya — setiap pandangan menyuap yang seterusnya, mewujudkan hierarki peringkat pengagregatan dari satu sumber data mentah:

-- bar 1-saat dari dagangan mentah
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;

-- bar 5-saat dari bar 1-saat
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;

-- bar 1-minit dari bar 5-saat
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;

Setiap peringkat memproses set data yang jauh lebih kecil daripada peringkat sebelumnya. Pandangan 1-minit tidak mengimbas dagangan mentah — ia hanya membaca bar 5-saat yang telah diagregatkan terlebih dahulu. Corak beranting ini berskala kepada sebarang bilangan jangka masa: 1s → 5s → 1m → 5m → 15m → 1h → 4h → 1d.

Untuk platform data kripto yang menelan dari 100+ bursa, ini adalah tulang belakang seluruh saluran paip penghantaran OHLC.

Strategi Penyegaran

QuestDB menawarkan tiga mod penyegaran, setiap satu sesuai untuk beban kerja yang berbeza:

REFRESH IMMEDIATE mencetuskan penyegaran tak segerak selepas setiap transaksi jadual asas. Terbaik untuk papan pemuka masa nyata di mana kependaman sub-saat penting.

REFRESH EVERY 1h (berasaskan pemasa) mengelompokkan kemas kini ke dalam penyegaran berkala. Lebih baik untuk pengingesan throughput tinggi di mana mencetuskan penyegaran pada setiap mikro-kumpulan akan mencipta overhead.

REFRESH PERIOD (LENGTH 1d TIME ZONE 'Europe/London' DELAY 2h) mentakrifkan tempoh sejajar kalendar. "Kelewatan" mengambil kira data yang tiba lewat — kritikal untuk pasaran yang mungkin menghantar suapan pembetulan berjam-jam selepas sesi dagangan.

REFRESH MANUAL memberikan kawalan penuh. Pandangan hanya dikemas kini apabila anda menjalankan arahan REFRESH secara eksplisit — berguna untuk aliran kerja penyelarasan akhir hari.

Corak Pecutan LATEST ON

Salah satu corak paling berkuasa menggabungkan pandangan terwujud dengan LATEST ON untuk syot kilat portfolio segera. Mengimbas 1.3 bilion baris mentah untuk harga terkini setiap simbol mengambil masa beberapa saat. Tetapi dengan pandangan pra-agregat harian:

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;

Pertanyaan LATEST ON mengimbas kira-kira 25,000 baris pra-agregat dan bukannya berbilion:

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

Dari saat ke milisaat. Inilah cara papan pemuka dagangan pengeluaran mencapai responsiviti masa nyata ke atas set data yang besar.

TTL: Kitaran Hayat Data Automatik

Pandangan terwujud menyokong dasar TTL (masa untuk hidup) untuk tamat tempoh data automatik:

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;

Ini mengekalkan 8 minggu data setiap jam, menjatuhkan partisi yang lebih lama secara automatik. Digabungkan dengan enjin storan tiga peringkat, anda mendapat kitaran hayat data semula jadi: tik mentah mengalir melalui WAL → storan lajur → Parquet pada storan objek, sementara pandangan terwujud mengekalkan ringkasan pra-agregat yang sebenarnya ditanya oleh aplikasi anda.

Tatasusunan 2D: Analitik Buku Pesanan Asli

Kedalaman buku pesanan 3D: peringkat bida dan tanya disimpan sebagai tatasusunan 2D asli, membolehkan pengiraan spread yang dioptimumkan SIMD dan analisis kecairan

QuestDB 9.0 memperkenalkan tatasusunan N-dimensi — tatasusunan berbentuk dan bergelangsar sebenar, seperti NumPy, yang mengendalikan operasi biasa (penghirisan, transposisi) dengan sifar penyalinan. Untuk dagangan, aplikasi pembunuh adalah storan buku pesanan.

Masalah Tradisional

Secara historis, menyimpan syot kilat buku pesanan dalam pangkalan data relasional adalah menyusahkan. Anda mempunyai dua pilihan: satu baris setiap peringkat harga (letupan baris, mahal untuk menanya kedalaman), atau bilangan lajur tetap seperti bid1_price, bid1_size, bid2_price, bid2_size, dsb. (tegar, membazir, dan hodoh).

Tatasusunan 2D QuestDB menghapuskan kedua-dua masalah:

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

Setiap lajur bids dan asks menyimpan tatasusunan 2D di mana baris pertama mengandungi harga dan baris kedua mengandungi volum pada setiap peringkat. Buku pesanan 20 peringkat adalah satu tatasusunan padat tunggal, bukan 40 lajur berasingan.

Analitik Buku Pesanan dalam SQL

Pengiraan spread — metrik paling asas dan paling kerap dikira:

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

Fungsi spread() adalah fungsi terbina dalam yang mengira perbezaan antara tanya terbaik dan bida terbaik. bids[1][1] mengakses elemen pertama (harga terbaik) baris pertama (harga) dalam tatasusunan bida.

Untuk analitik yang lebih canggih — kedalaman kecairan, ketidakseimbangan buku pesanan, kebarangkalian pelaksanaan pada peringkat harga tertentu — penghirisan tatasusunan dan operasi tervektorkan menjadikan pertanyaan yang sebelum ini kompleks lebih mudah:

-- Cari peringkat di mana harga sasaran akan dicapai
-- dan jumlahkan semua volum sehingga peringkat tersebut
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';

Operasi tatasusunan yang dioptimumkan SIMD bermakna pengiraan ini berjalan pada kelajuan hampir perkakasan, walaupun pada jutaan syot kilat.

Pengingesan Data Tatasusunan

Perpustakaan klien QuestDB menyokong pengingesan tatasusunan asli. Klien Python berintegrasi terus dengan tatasusunan NumPy:

import numpy as np
from questdb.ingress import Sender

bids = np.array([[9.3, 9.2, 9.1], [100, 200, 150]])  # harga, volum
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
    )

Protokol Versi 2 mengekod tatasusunan dalam bentuk binari, mengurangkan lebar jalur dan overhead penghuraian sisi pelayan secara dramatik berbanding protokol berasaskan teks. Untuk pengingesan buku pesanan frekuensi tinggi — di mana anda mungkin menerima ribuan syot kilat sesaat setiap simbol — kecekapan ini penting.

Klien C/C++ menggunakan tatasusunan rata baris-utama dengan deskriptor bentuk, membolehkan pengingesan sifar-salin dari struktur data sistem dagangan sedia ada.

Menyatukan Semuanya: Seni Bina Rujukan

Seni bina rujukan: penyambung bursa, teras pangkalan data lajur, lapisan analitik, enjin strategi, dan papan pemuka pemantauan — semua saling berhubung

Mari kita reka platform dagangan algoritma berasaskan QuestDB yang lengkap untuk pasaran kripto. Seni bina ini mengendalikan pengingesan dari berbilang bursa, analitik masa nyata, ujian belakang, dan pelaksanaan strategi.

Lapisan Pengingesan Data

Pengingesan data: berbilang penyambung bursa menyuap data pasaran masa nyata melalui saluran paip WebSocket ke QuestDB melalui ILP

Berbilang sambungan WebSocket ke bursa (Binance, Bybit, OKX, dsb.) menyuap data pasaran mentah ke QuestDB melalui ILP over HTTP. Setiap penyambung bursa adalah proses berasingan, menyediakan pengasingan dan toleransi kesalahan.

Aliran data termasuk: dagangan (cap masa, simbol, sisi, harga, kuantiti), syot kilat buku pesanan (cap masa, simbol, bids[][], asks[][]), dan kadar pembiayaan/likuidasi sebagai aliran tambahan.

Sasaran throughput pengingesan: jutaan baris sesaat merentas semua bursa digabungkan. WAL QuestDB mengendalikan ini dengan selesa, dengan penyahduplikatan menangkap pendua yang tidak dapat dielakkan dari sambungan bursa berlebihan.

Lapisan Analitik Masa Nyata

Pandangan terwujud membentuk teras lapisan analitik:

Dagangan mentah → ohlc_1s → ohlc_5s → ohlc_1m → ohlc_5m → ohlc_15m → ohlc_1h → ohlc_1d

Setiap peringkat disegar secara bertambah. Papan pemuka Grafana yang disambungkan melalui pemalam asli QuestDB menanya pandangan ini untuk carta kandil lilin, dengan masa tindak balas sub-5ms tanpa mengira berapa banyak data sejarah yang wujud.

Pandangan terwujud tambahan mengira: VWAP (harga purata berwajaran volum) setiap simbol setiap hari, anggaran kemeruapan bergolek, dan pemantauan spread merentas bursa.

Pertanyaan LATEST ON terhadap pandangan pra-agregat menyokong papan pemuka portfolio masa nyata — menunjukkan kedudukan semasa, P&L tidak direalisasikan, dan pendedahan setiap bursa.

Enjin Strategi

Enjin strategi: pengiraan penunjuk masa nyata menyuap pembuatan keputusan algoritma, dengan laluan pelaksanaan beli/jual yang dioptimumkan oleh pandangan terwujud

Strategi dagangan menanya QuestDB untuk keadaan pasaran semasa dan corak sejarah. Protokol wayar PG QuestDB bermakna mana-mana bahasa dengan pemacu PostgreSQL boleh disambungkan: Python untuk strategi penyelidikan, Rust atau C++ untuk pelaksanaan sensitif kependaman.

Corak pertanyaan utama untuk strategi: ASOF JOIN untuk memadankan pengisian pelaksanaan dengan keadaan pasaran pada masa pengisian, WINDOW JOIN untuk mengira metrik cakrawala pendek di sekitar setiap peristiwa, dan fungsi tetingkap untuk pengiraan penunjuk masa nyata (RSI, Bollinger Bands, ATR).

Untuk strategi kritikal kependaman, pandangan terwujud pra-dikira meminimumkan masa pertanyaan. Bot grid yang memantau 50 simbol tidak perlu mengira 50 purata bergerak berasingan pada setiap tik — ia membacanya dari pandangan terwujud.

Saluran Paip Ujian Belakang

Data sejarah terletak dalam Parquet pada storan objek. QuestDB menanyanya secara telus, tetapi untuk beban kerja ujian belakang yang berat, data juga boleh dibaca terus oleh Polars, Pandas, atau DuckDB — memintas pangkalan data sepenuhnya.

Corak akses dua laluan ini berkuasa: strategi langsung menggunakan antara muka SQL QuestDB untuk keputusan masa nyata, sementara rangka kerja ujian belakang membaca data yang sama melalui Parquet/Arrow untuk pemprosesan kelompok. Data yang sama, dua laluan akses yang dioptimumkan.

Pemantauan dan Analisis Pasca-Dagangan

HORIZON JOIN menyokong saluran paip analisis pasca-dagangan:

• Analisis gelinciran: Bandingkan harga pelaksanaan dengan harga pertengahan pada masa pengisian
• Keluk markout: Jejak evolusi harga 1s, 5s, 30s, 60s selepas setiap pengisian
• Kekurangan pelaksanaan: Uraikan kos pelaksanaan kepada spread, impak sementara, dan impak kekal
• Pemarkahan tempat: Bandingkan kualiti pengisian merentas bursa untuk mengoptimumkan penghala pesanan

Analisis ini berjalan sebagai pertanyaan berjadual, menulis hasil ke jadual khusus yang menyuap papan pemuka pemantauan. Peraturan amaran mencetuskan anomali — lonjakan gelinciran tiba-tiba, corak markout luar biasa, atau kualiti pengisian yang merosot pada tempat tertentu.

Pertimbangan Prestasi

Penalaan prestasi pengeluaran: pemantauan kependaman, throughput, dan memori bersama kitaran hayat data panas-suam-sejuk

Beberapa nota praktikal dari penempatan pengeluaran:

Penyasaran partisi: Untuk data tik kripto dengan jutaan baris sehari, PARTITION BY HOUR biasanya optimum. Ini mengekalkan partisi individu yang boleh diurus untuk kedua-dua storan dan prestasi pertanyaan.

Beranting pandangan terwujud: Jangan buat terlalu banyak peringkat pertengahan. Setiap peringkat menambah kependaman penyegaran. Untuk kebanyakan kes penggunaan, 3-4 peringkat (1s → 1m → 15m → 1d) memberikan keseimbangan yang baik antara prestasi pertanyaan dan kesegaran data.

Overhead penyahduplikatan: Aktifkan penyahduplikatan pada jadual dengan sumber data berlebihan. Kos adalah minimum untuk data cap masa unik tetapi meningkat dengan banyak baris cap masa yang sama yang memerlukan penyahduplikatan peringkat lajur.

Peruntukan memori: Enjin sifar-GC QuestDB adalah cekap, tetapi peruntukkan memori yang mencukupi untuk partisi panas dan cache tulis. Pantau melalui titik akhir metrik terbina dalam.

Pilihan protokol klien: Gunakan ILP over HTTP untuk pengingesan (dengan percubaan semula automatik dan pemeriksaan kesihatan). Gunakan wayar PG untuk pertanyaan. ILP Protokol Versi 2 (pengekodan binari) jauh lebih cekap untuk data tatasusunan dan nilai berganda throughput tinggi.

QuestDB vs. Alternatif

Landskap kompetitif: QuestDB diposisikan berbanding TimescaleDB, ClickHouse, InfluxDB, dan kdb+ merentas dimensi keupayaan utama

Pemposisian ringkas berbanding pangkalan data yang biasa digunakan dalam dagangan:

vs. TimescaleDB: TimescaleDB adalah PostgreSQL dengan sambungan siri masa. Ia mewarisi keumuman PG tetapi juga overheadnya. Enjin lajur asli QuestDB dan pelaksanaan SIMD memberikan prestasi pertanyaan yang jauh lebih baik pada beban kerja siri masa, dan ciri seperti ASOF JOIN tidak mempunyai padanan langsung TimescaleDB.

vs. ClickHouse: ClickHouse cemerlang dalam pertanyaan analitik ke atas set data yang besar. Tetapi ia tidak direka untuk siri masa khususnya — tiada ASOF JOIN asli, tiada SAMPLE BY dengan FILL, tiada tatasusunan 2D untuk buku pesanan. Untuk beban kerja OLAP + siri masa campuran, ClickHouse mungkin menang; untuk data dagangan tulen, QuestDB lebih ergonomik.

vs. InfluxDB: InfluxDB mempunyai had kardinaliti tinggi yang menyusahkan untuk data kripto berbilang bursa. Bahasa pertanyaannya (Flux, kini ditamatkan; InfluxQL) kekurangan ekspresiviti sambungan SQL QuestDB. Prestasi pada pertanyaan sejarah yang besar secara amnya lebih buruk.

vs. kdb+/q: Piawaian emas untuk HFT. kdb+ lebih pantas untuk operasi vektor benang tunggal tertentu dan bahasa q-nya sangat ringkas. Tetapi ia proprietari, mahal, dan mempunyai keluk pembelajaran yang curam. QuestDB menawarkan 80-90% keupayaan pada sebahagian kecil kos, dengan SQL standard dan pelesenan sumber terbuka.

Kesimpulan: Pangkalan Data yang Memahami Dagangan

Dalam tiga artikel ini, kami telah membincangkan seni bina QuestDB (storan tiga peringkat dengan WAL, lajur, dan Parquet), sambungan SQL-nya (SAMPLE BY, ASOF JOIN, HORIZON JOIN, WINDOW JOIN, LATEST ON, TWAP), dan aplikasi praktikalnya (pandangan terwujud, tatasusunan buku pesanan, seni bina rujukan).

Tema yang konsisten adalah: QuestDB direka untuk tepat beban kerja yang dihasilkan oleh dagangan algoritma. Ia tidak memaksa anda bekerja mengelilingi pangkalan data — sebaliknya, primitifnya memetakan terus ke konsep dagangan. Pengagregatan OHLC adalah satu baris kod. Penjajaran dagangan-ke-sebut harga adalah satu JOIN tunggal. Analisis pasca-dagangan adalah HORIZON JOIN, bukan prosedur PL/SQL berbilang halaman.

Untuk pasukan yang membina infrastruktur dagangan — sama ada platform data pasaran kripto, persekitaran penyelidikan kuantitatif, atau enjin dagangan algoritma penuh — QuestDB patut dievaluasi dengan serius. Versi sumber terbuka merangkumi kebanyakan kes penggunaan, dan edisi Enterprise mengisi jurang untuk persekitaran terkawal.

Landskap infrastruktur data kewangan sedang berkembang dengan pesat. Pangkalan data yang berbahasa pasaran akan menang. QuestDB fasih.

Selamat berdagang, dan semoga kependaman anda sentiasa rendah.

Rujukan

@software{soloviov2025questdb_algotrading_p3,
  author = {Soloviov, Eugen},
  title = {QuestDB for Algorithmic Trading: From Order Books to Production Architecture},
  year = {2025},
  url = {https://marketmaker.cc/ms/blog/post/questdb-algotrading-production},
  version = {0.1.0},
  description = {Pandangan terwujud, analitik buku pesanan tatasusunan 2D, dan seni bina rujukan untuk platform dagangan algoritma berasaskan QuestDB.}
}