QuestDB untuk Algorithmic Trading: Dari Order Book hingga Arsitektur Produksi

Bagian 3 dari 3 — tersedia juga dalam RU · ZH

Penafian: Informasi yang disajikan dalam artikel ini hanya untuk tujuan edukasi dan informasi, dan tidak merupakan nasihat keuangan, investasi, atau perdagangan. Perdagangan mata uang kripto melibatkan risiko kerugian yang signifikan.

Selamat datang di bagian terakhir dari seri QuestDB kami. Pada Bagian 1, kami membahas arsitektur penyimpanan. Pada Bagian 2, kami menjelajahi ekstensi SQL. Sekarang mari kita satukan semuanya: materialized view untuk analitik real-time, penyimpanan order book native dengan array 2D, dan arsitektur referensi untuk platform algorithmic trading produksi.

Materialized View: Analitik Pra-Komputasi pada Kecepatan Jaringan

Materialized view berjenjang: data tick mentah mengalir melalui lapisan agregasi yang semakin kasar, setiap level memproses dataset yang jauh lebih kecil

Jika SAMPLE BY adalah query yang paling sering digunakan di QuestDB, maka materialized view adalah optimasi yang paling berdampak. Konsepnya sederhana: daripada menghitung agregasi OHLCV setiap kali dasbor diperbarui atau API dipanggil, hitung sekali dan biarkan hasilnya terus diperbarui secara otomatis.

Materialized View OHLC Dasar

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 seluruh definisinya. Setiap kali baris baru dimasukkan ke tabel trades, QuestDB secara otomatis dan inkremental merefresh view ini. Bukan komputasi ulang penuh — hanya bucket waktu yang terpengaruh yang diperbarui. Query terhadap trades_OHLC_15m menjadi pencarian sederhana pada dataset yang jauh lebih kecil dan sudah teragregasi.

Perbedaan performa sangat dramatis. Pada tabel dengan miliaran baris, query data OHLC pada tabel dasar mungkin memakan waktu 200ms. Materialized view mengembalikan hasil yang sama dalam waktu kurang dari 5ms. Dengan beberapa pengguna dasbor secara bersamaan, ini bukan sekadar optimasi — ini adalah perbedaan antara sistem yang responsif dan sistem yang runtuh.

View Berjenjang: Multi-Timeframe dari Satu Sumber

Di sinilah materialized view menjadi elegan secara arsitektur. Anda dapat merantainya — setiap view memberi makan view berikutnya, menciptakan hierarki level agregasi dari satu sumber data mentah:

-- Bar 1 detik dari trade 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 detik dari bar 1 detik
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 menit dari bar 5 detik
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 level memproses dataset yang jauh lebih kecil dari level sebelumnya. View 1 menit tidak memindai trade mentah — hanya membaca bar 5 detik yang sudah teragregasi. Pola berjenjang ini dapat diskalakan ke jumlah timeframe berapa pun: 1s → 5s → 1m → 5m → 15m → 1h → 4h → 1d.

Untuk platform data kripto yang menyerap data dari 100+ exchange, ini adalah tulang punggung seluruh pipeline pengiriman OHLC.

Strategi Refresh

QuestDB menawarkan tiga mode refresh, masing-masing cocok untuk beban kerja yang berbeda:

REFRESH IMMEDIATE memicu refresh asinkron setelah setiap transaksi tabel dasar. Terbaik untuk dasbor real-time di mana latensi sub-detik sangat penting.

REFRESH EVERY 1h (berbasis timer) mengelompokkan pembaruan menjadi refresh berkala. Lebih baik untuk ingesti throughput tinggi di mana memicu refresh pada setiap micro-batch akan menimbulkan overhead.

REFRESH PERIOD (LENGTH 1d TIME ZONE 'Europe/London' DELAY 2h) mendefinisikan periode yang diselaraskan dengan kalender. "Delay" memperhitungkan data yang datang terlambat — kritis untuk pasar yang mungkin mengirimkan feed koreksi berjam-jam setelah sesi perdagangan.

REFRESH MANUAL memberikan kontrol penuh. View hanya diperbarui ketika Anda secara eksplisit menjalankan perintah REFRESH — berguna untuk alur kerja rekonsiliasi akhir hari.

Pola Akselerasi LATEST ON

Salah satu pola paling kuat menggabungkan materialized view dengan LATEST ON untuk snapshot portofolio secara instan. Memindai 1,3 miliar baris mentah untuk mendapatkan harga terkini setiap simbol memakan waktu beberapa detik. Namun dengan view pra-agregasi 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;

Query LATEST ON memindai sekitar 25.000 baris pra-agregasi alih-alih miliaran baris:

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

Dari detik menjadi milidetik. Inilah cara dasbor trading produksi mencapai responsivitas real-time atas dataset yang sangat besar.

TTL: Siklus Hidup Data Otomatis

Materialized view mendukung kebijakan TTL (time-to-live) untuk kedaluwarsa data secara otomatis:

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 menyimpan 8 minggu data per jam, secara otomatis menghapus partisi yang lebih lama. Dikombinasikan dengan mesin penyimpanan tiga tingkat, Anda mendapatkan siklus hidup data yang alami: tick mentah mengalir melalui WAL → penyimpanan kolumnar → Parquet pada object storage, sementara materialized view mempertahankan ringkasan pra-agregasi yang benar-benar dikueri oleh aplikasi Anda.

Array 2D: Analitik Order Book Native

Kedalaman order book 3D: level bid dan ask disimpan sebagai array 2D native, memungkinkan perhitungan spread yang dioptimalkan SIMD dan analisis likuiditas

QuestDB 9.0 memperkenalkan array N-dimensi — array berbentuk dan berstrida sejati, mirip NumPy, yang menangani operasi umum (slicing, transposing) tanpa penyalinan. Untuk trading, aplikasi utamanya adalah penyimpanan order book.

Masalah Tradisional

Secara historis, menyimpan snapshot order book dalam database relasional sangat menyulitkan. Anda memiliki dua pilihan: satu baris per level harga (ledakan baris, query kedalaman yang mahal), atau sejumlah kolom tetap seperti bid1_price, bid1_size, bid2_price, bid2_size, dll. (kaku, boros, dan tidak elegan).

Array 2D QuestDB menghilangkan kedua masalah tersebut:

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

Setiap kolom bids dan asks menyimpan array 2D di mana baris pertama berisi harga dan baris kedua berisi volume pada setiap level. Order book 20 level adalah satu array kompak, bukan 40 kolom terpisah.

Analitik Order Book dalam SQL

Perhitungan spread — metrik paling dasar dan paling sering dihitung:

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 bawaan yang menghitung selisih antara ask terbaik dan bid terbaik. bids[1][1] mengakses elemen pertama (harga terbaik) dari baris pertama (harga) dalam array bids.

Untuk analitik yang lebih canggih — kedalaman likuiditas, ketidakseimbangan order book, probabilitas eksekusi pada level harga tertentu — slicing array dan operasi yang divektorisasi membuat query yang sebelumnya kompleks menjadi mudah:

-- Temukan level di mana harga target akan tercapai
-- dan jumlahkan semua volume hingga level 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 array yang dioptimalkan SIMD berarti perhitungan ini berjalan mendekati kecepatan hardware, bahkan atas jutaan snapshot.

Ingesti Data Array

Library klien QuestDB mendukung ingesti array native. Klien Python terintegrasi langsung dengan array NumPy:

import numpy as np
from questdb.ingress import Sender

bids = np.array([[9.3, 9.2, 9.1], [100, 200, 150]])  # harga, volume
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 mengodekan array dalam bentuk biner, secara dramatis mengurangi bandwidth dan overhead parsing sisi server dibandingkan dengan protokol berbasis teks. Untuk ingesti order book frekuensi tinggi — di mana Anda mungkin menerima ribuan snapshot per detik per simbol — efisiensi ini sangat penting.

Klien C/C++ menggunakan array flat row-major dengan deskriptor bentuk, memungkinkan ingesti zero-copy dari struktur data sistem trading yang sudah ada.

Menyatukan Semuanya: Arsitektur Referensi

Arsitektur referensi: konektor exchange, inti database kolumnar, lapisan analitik, mesin strategi, dan dasbor pemantauan — semua saling terhubung

Mari kita rancang platform algorithmic trading berbasis QuestDB yang lengkap untuk pasar kripto. Arsitektur ini menangani ingesti dari beberapa exchange, analitik real-time, backtesting, dan eksekusi strategi.

Lapisan Ingesti Data

Ingesti data: beberapa konektor exchange mengumpankan data pasar real-time melalui pipeline WebSocket ke QuestDB via ILP

Beberapa koneksi WebSocket ke exchange (Binance, Bybit, OKX, dll.) mengumpankan data pasar mentah ke QuestDB via ILP melalui HTTP. Setiap konektor exchange adalah proses terpisah, memberikan isolasi dan toleransi kesalahan.

Stream data meliputi: trade (timestamp, symbol, side, price, quantity), snapshot order book (timestamp, symbol, bids[][], asks[][]), dan funding rate/likuidasi sebagai stream tambahan.

Target throughput ingesti: jutaan baris per detik di semua exchange. WAL QuestDB menangani ini dengan nyaman, dengan deduplication menangkap duplikat yang tak terhindarkan dari koneksi exchange yang berlebihan.

Lapisan Analitik Real-Time

Materialized view membentuk inti lapisan analitik:

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

Setiap level direfresh secara inkremental. Dasbor Grafana yang terhubung melalui plugin native QuestDB mengquery view ini untuk grafik candlestick, dengan waktu respons di bawah 5ms terlepas dari berapa banyak data historis yang ada.

Materialized view tambahan menghitung: VWAP (harga rata-rata tertimbang volume) per simbol per hari, estimasi volatilitas bergulir, dan pemantauan spread lintas exchange.

Query LATEST ON terhadap view pra-agregasi mendukung dasbor portofolio real-time — menampilkan posisi saat ini, unrealized P&L, dan eksposur per exchange.

Mesin Strategi

Mesin strategi: komputasi indikator real-time mendukung pengambilan keputusan algoritmik, dengan jalur eksekusi beli/jual yang dioptimalkan oleh materialized view

Strategi trading mengquery QuestDB untuk status pasar saat ini dan pola historis. Protokol PG wire QuestDB berarti bahasa apa pun dengan driver PostgreSQL dapat terhubung: Python untuk strategi riset, Rust atau C++ untuk eksekusi yang sensitif terhadap latensi.

Pola query utama untuk strategi: ASOF JOIN untuk mencocokkan fill eksekusi dengan kondisi pasar pada saat fill, WINDOW JOIN untuk menghitung metrik horizon pendek di sekitar setiap event, dan fungsi window untuk komputasi indikator real-time (RSI, Bollinger Bands, ATR).

Untuk strategi yang kritis terhadap latensi, materialized view yang sudah dihitung sebelumnya meminimalkan waktu query. Bot grid yang memantau 50 simbol tidak perlu menghitung 50 moving average terpisah pada setiap tick — cukup membacanya dari materialized view.

Pipeline Backtesting

Data historis berada di Parquet pada object storage. QuestDB mengquerynya secara transparan, tetapi untuk beban kerja backtesting yang berat, data juga dapat dibaca langsung oleh Polars, Pandas, atau DuckDB — melewati database sama sekali.

Pola akses ganda ini powerful: strategi live menggunakan antarmuka SQL QuestDB untuk keputusan real-time, sementara framework backtesting membaca data yang sama melalui Parquet/Arrow untuk pemrosesan batch. Data yang sama, dua jalur akses yang dioptimalkan.

Pemantauan dan Analisis Pasca-Trade

HORIZON JOIN mendukung pipeline analisis pasca-trade:

• Analisis slippage: Bandingkan harga eksekusi dengan harga mid pada saat fill
• Kurva markout: Lacak evolusi harga 1d, 5d, 30d, 60d setelah setiap fill
• Implementation shortfall: Uraikan biaya eksekusi menjadi spread, dampak sementara, dan dampak permanen
• Penilaian venue: Bandingkan kualitas fill di seluruh exchange untuk mengoptimalkan routing order

Analisis-analisis ini berjalan sebagai query terjadwal, menulis hasil ke tabel khusus yang memberi makan dasbor pemantauan. Aturan alert dipicu pada anomali — lonjakan slippage mendadak, pola markout yang tidak biasa, atau kualitas fill yang menurun di venue tertentu.

Pertimbangan Performa

Penyetelan performa produksi: pemantauan latensi, throughput, dan memori bersama siklus hidup data hot-warm-cold

Beberapa catatan praktis dari deployment produksi:

Ukuran partisi: Untuk data tick kripto dengan jutaan baris per hari, PARTITION BY HOUR biasanya optimal. Ini menjaga partisi individual tetap dapat dikelola untuk performa penyimpanan dan query.

Kaskade materialized view: Jangan membuat terlalu banyak level perantara. Setiap level menambah latensi refresh. Untuk sebagian besar kasus penggunaan, 3-4 level (1s → 1m → 15m → 1d) memberikan keseimbangan yang baik antara performa query dan kesegaran data.

Overhead deduplication: Aktifkan deduplication pada tabel dengan sumber data yang berlebihan. Biayanya minimal untuk data dengan timestamp unik tetapi meningkat dengan banyak baris dengan timestamp yang sama yang memerlukan deduplication tingkat kolom.

Alokasi memori: Mesin zero-GC QuestDB efisien, tetapi alokasikan memori yang cukup untuk partisi hot dan write cache. Pantau melalui endpoint metrik bawaan.

Pilihan protokol klien: Gunakan ILP melalui HTTP untuk ingesti (dengan retry otomatis dan health check). Gunakan PG wire untuk query. ILP Protocol Version 2 (encoding biner) jauh lebih efisien untuk data array dan nilai double throughput tinggi.

QuestDB vs. Alternatif Lainnya

Lanskap kompetitif: QuestDB diposisikan terhadap TimescaleDB, ClickHouse, InfluxDB, dan kdb+ di berbagai dimensi kemampuan utama

Perbandingan singkat terhadap database yang umum digunakan dalam trading:

vs. TimescaleDB: TimescaleDB adalah PostgreSQL dengan ekstensi time-series. Ia mewarisi generalitas PG tetapi juga overheadnya. Mesin kolumnar native dan eksekusi SIMD QuestDB memberikan performa query yang jauh lebih baik pada beban kerja time-series, dan fitur seperti ASOF JOIN tidak memiliki padanan langsung di TimescaleDB.

vs. ClickHouse: ClickHouse unggul dalam query analitik atas dataset besar. Namun tidak dirancang khusus untuk time-series — tidak ada ASOF JOIN native, tidak ada SAMPLE BY dengan FILL, tidak ada array 2D untuk order book. Untuk beban kerja OLAP + time-series campuran, ClickHouse mungkin menang; untuk data trading murni, QuestDB lebih ergonomis.

vs. InfluxDB: InfluxDB memiliki keterbatasan high-cardinality yang menyulitkan untuk data kripto multi-exchange. Bahasa querynya (Flux, kini sudah deprecated; InfluxQL) kurang ekspresif dibandingkan ekstensi SQL QuestDB. Performa pada query historis yang besar umumnya lebih buruk.

vs. kdb+/q: Standar emas untuk HFT. kdb+ lebih cepat untuk operasi vektor single-thread tertentu dan bahasa q-nya sangat ringkas. Namun bersifat proprietary, mahal, dan memiliki kurva pembelajaran yang curam. QuestDB menawarkan 80-90% kemampuan dengan sebagian kecil biaya, dengan SQL standar dan lisensi open-source.

Kesimpulan: Database yang Memahami Trading

Dalam tiga artikel ini, kami telah membahas arsitektur QuestDB (penyimpanan tiga tingkat dengan WAL, kolumnar, dan Parquet), ekstensi SQL-nya (SAMPLE BY, ASOF JOIN, HORIZON JOIN, WINDOW JOIN, LATEST ON, TWAP), dan aplikasi praktisnya (materialized view, array order book, arsitektur referensi).

Benang merahnya konsisten: QuestDB dirancang khusus untuk beban kerja yang dihasilkan oleh algorithmic trading. Ia tidak memaksa Anda untuk bekerja di sekitar database — sebaliknya, primitifnya dipetakan langsung ke konsep trading. Agregasi OHLC adalah satu baris. Penyelarasan trade-ke-kuotasi adalah satu JOIN. Analisis pasca-trade adalah HORIZON JOIN, bukan prosedur PL/SQL berlipat-lipat halaman.

Bagi tim yang membangun infrastruktur trading — baik itu platform data pasar kripto, lingkungan riset kuantitatif, atau mesin algorithmic trading lengkap — QuestDB layak dievaluasi dengan serius. Versi open-source mencakup sebagian besar kasus penggunaan, dan edisi Enterprise mengisi celah untuk lingkungan yang diregulasi.

Lanskap infrastruktur data keuangan berkembang pesat. Database yang berbicara dalam bahasa pasar akan menang. QuestDB fasih berbicara bahasa itu.

Selamat trading, dan semoga latensi Anda selalu rendah.

Sitasi

@software{soloviov2025questdb_algotrading_p3,
  author = {Soloviov, Eugen},
  title = {QuestDB for Algorithmic Trading: From Order Books to Production Architecture},
  year = {2025},
  url = {https://marketmaker.cc/id/blog/post/questdb-algotrading-production},
  version = {0.1.0},
  description = {Materialized view, analitik order book array 2D, dan arsitektur referensi untuk platform algorithmic trading berbasis QuestDB.}
}