QuestDB untuk Algorithmic Trading: Arsitektur yang Berbicara dalam Bahasa Pasar

Bagian 1 dari 3 — tersedia juga dalam RU · ZH

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

Halo! Hari ini kita memulai seri tiga bagian tentang QuestDB — database time-series open-source yang secara diam-diam menjadi tulang punggung infrastruktur trading modern. Ini bukan artikel "10 database terbaik" biasa. Kita akan membahas secara teknis, karena itulah yang dituntut oleh algorithmic trading.

Jika Anda pernah berjuang dengan batas kardinitas InfluxDB, berperang melawan overhead TimescaleDB pada data tick, atau bertanya-tanya mengapa instance PostgreSQL Anda tidak mampu menangani satu juta insert per detik — seri ini untuk Anda.

Mengapa Database Time-Series Penting untuk Trading

Setiap sistem algorithmic trading — dari bot grid sederhana hingga mesin HFT penuh — memiliki ketergantungan mendasar yang sama: data. Khususnya, data yang berurutan berdasarkan waktu, tiba dengan kecepatan sangat tinggi, dan perlu dapat di-query secara real time.

Database relasional tradisional tidak dirancang untuk ini. Mereka unggul dalam transaksi ACID dan join kompleks di seluruh skema ternormalisasi, tetapi tersedak pada beban kerja append-heavy yang dipartisi berdasarkan waktu yang mendefinisikan pasar keuangan. Anda akhirnya berjuang melawan database alih-alih membiarkannya bekerja untuk Anda.

Database time-series membalik paradigma ini. Mereka mengasumsikan data Anda memiliki timestamp, bahwa data tersebut tiba kurang lebih secara berurutan, dan bahwa query Anda hampir selalu melibatkan rentang waktu. QuestDB melangkah lebih jauh dengan dirancang khusus dengan pasar modal dalam pikiran — tim rekayasanya berasal dari bank investasi Tier 1 (BoA, UBS, HSBC), dan hal ini terlihat dalam setiap keputusan desain.

Sekilas tentang QuestDB

QuestDB adalah database time-series open-source (Apache 2.0) yang ditulis dalam Java zero-GC, C++, dan Rust. Bagian "zero-GC" sangat krusial: mesin inti menghindari garbage collector Java sepenuhnya, mengelola memori secara manual untuk menghilangkan lonjakan latensi yang tidak dapat diprediksi yang menghantui sebagian besar sistem berbasis JVM.

Karakteristik performa utama yang perlu diperhatikan:

• Throughput ingestion jutaan baris per detik pada satu server
• Latensi query di bawah milidetik melalui eksekusi tervektorisasi dengan instruksi SIMD
• Timestamp presisi nanosecond native — esensial untuk data tick
• Arsitektur penyimpanan tiga tingkat yang dioptimalkan untuk data panas maupun dingin
• Antarmuka SQL dengan ekstensi time-series yang powerful

Namun angka mentah hanya menceritakan sebagian kisah. Yang membuat QuestDB benar-benar menarik untuk sistem trading adalah bagaimana ia menyimpan dan meng-query data.

Mesin Penyimpanan Tiga Tingkat

Di sinilah arsitektur QuestDB menjadi elegan. Data mengalir melalui tiga tingkat yang berbeda, masing-masing dioptimalkan untuk pola akses yang berbeda:

Tingkat 1: WAL (Write-Ahead Log)

Data yang masuk pertama kali mencapai Write-Ahead Log. Ini adalah lapisan append dengan latensi ultra-rendah. Setiap penulisan dibuat tahan lama sebelum pemrosesan apa pun terjadi — bertahan dari crash dan pemadaman listrik tanpa kehilangan data. WAL hanya menulis secara sekuensial, yang berarti bekerja sempurna dengan SSD modern dan drive NVMe.

Untuk sistem trading, ini berarti pipeline ingesti data pasar Anda dapat mengirimkan data ke QuestDB tanpa khawatir tentang write amplification atau lock contention. Baik Anda menerima pembaruan WebSocket dari 50 exchange kripto atau memproses aliran pesan FIX, WAL menyerapnya semua.

WAL juga dikirimkan secara asinkron ke object storage, memungkinkan replika baru untuk bootstrap dengan cepat dan membaca riwayat yang sama — properti krusial untuk pemulihan bencana di lingkungan trading produksi.

Tingkat 2: Penyimpanan Kolomar

Secara asinkron, data diurutkan berdasarkan waktu, dideduplikasi, dan ditulis ke dalam format kolomar native QuestDB. Format ini dipartisi berdasarkan waktu (per jam, hari, minggu, atau bulan tergantung volume data Anda) dan segera dapat di-query.

Tata letak kolomar inilah yang memungkinkan performa query QuestDB. Ketika Anda meminta harga rata-rata BTC-USD selama satu jam terakhir, mesin hanya membaca kolom price dari partisi waktu yang relevan — bukan seluruh baris. Dikombinasikan dengan eksekusi SIMD-tervektorisasi di berbagai core, ini menghasilkan waktu query di bawah milidetik yang membuat dashboard real-time dan kalkulasi strategi langsung menjadi layak.

Setiap tabel disimpan sebagai file terpisah per kolom, dengan tipe berukuran tetap mendapatkan satu file per kolom dan tipe berukuran variabel (seperti VARCHAR) menggunakan dua. Tata letak ini dirancang khusus untuk jenis pemindaian sekuensial yang mendominasi analitik time-series.

Tingkat 3: Object Storage (Parquet)

Di sinilah manajemen biaya bertemu interoperabilitas. Partisi yang lebih lama secara otomatis dikonversi ke format Apache Parquet dan dikirim ke object storage (S3, Azure Blob, GCS). Namun — dan ini adalah inovasi kuncinya — Anda masih dapat meng-query-nya secara transparan melalui antarmuka SQL QuestDB. Query planner mencakup ketiga tingkat secara mulus.

Bagi algorithmic trader, ini berarti Anda dapat menyimpan data tick historis selama bertahun-tahun yang dapat diakses untuk backtesting tanpa membayar terabyte penyimpanan SSD. Framework backtesting Python Anda dapat membaca file Parquet yang sama secara langsung melalui Polars, Pandas, atau Spark — tidak perlu ekspor database. Pipeline pelatihan ML Anda dapat mengakses data yang sama melalui Arrow/ADBC untuk pemrosesan in-memory. Zero vendor lock-in.

Ini adalah proposisi yang sangat berbeda dari format database proprietary yang menjebak data Anda di balik satu antarmuka query.

Desain Skema untuk Data Trading

Filosofi desain skema QuestDB berkisar pada beberapa konsep kritis yang selaras sempurna dengan data trading:

Designated Timestamp

Setiap tabel time-series membutuhkan kolom timestamp yang ditetapkan. Ini bukan sekadar metadata — ia menentukan urutan penyimpanan fisik dan memungkinkan partition pruning. Tanpanya, Anda kehilangan sebagian besar keuntungan performa QuestDB:

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

Tipe SYMBOL

Tipe SYMBOL adalah jawaban QuestDB untuk masalah string berkardinitas tinggi. Pasangan trading seperti "BTC-USD" atau "ETH-USDT" disimpan sebagai entri kamus yang diindeks dengan integer. Filtering dan grouping pada kolom SYMBOL jauh lebih cepat dibandingkan pada VARCHAR — QuestDB menyelesaikan perbandingan string menjadi perbandingan integer pada waktu kompilasi.

Jika Anda mengingesti data dari 100+ exchange dengan ribuan pasangan trading, optimisasi ini saja bisa menjadi perbedaan antara query yang memakan waktu 5ms dan 500ms.

Strategi Partisi

Ukuran partisi harus sesuai dengan volume data Anda. Data tick frekuensi tinggi (jutaan baris per hari per simbol) harus menggunakan PARTITION BY HOUR. Data end-of-day dengan volume lebih rendah bekerja baik dengan PARTITION BY MONTH. Tujuannya adalah menjaga partisi individual tetap terkelola sambil memungkinkan pruning yang efisien:

-- Data tick volume tinggi
CREATE TABLE ticks (...) TIMESTAMP(ts) PARTITION BY HOUR;

-- Harga harian volume lebih rendah
CREATE TABLE eod_prices (...) TIMESTAMP(ts) PARTITION BY MONTH;

Deduplikasi Data

Dalam sistem trading dunia nyata, data duplikat tidak dapat dihindari. Retransmisi jaringan, koneksi exchange redundan untuk keandalan, pemutaran ulang data historis selama pemulihan — semua ini menghasilkan duplikat. QuestDB menangani ini secara native: ketika diaktifkan, deduplikasi menggantikan baris yang cocok dengan versi baru, dan hanya baris yang benar-benar baru yang disisipkan.

Dampak performa bergantung pada pola data Anda. Jika timestamp sebagian besar unik di seluruh baris, overheadnya minimal. Kasus paling menuntut adalah ketika banyak baris berbagi timestamp yang sama dan membutuhkan deduplikasi pada kolom tambahan — umum dalam snapshot order book di mana beberapa level harga diperbarui secara bersamaan.

Pertimbangan Deployment Produksi

Klien produksi QuestDB mencakup B3 (bursa saham terbesar Amerika Latin), One Trading (exchange kripto teregulasi yang mengingesti hingga 4 juta baris per detik), Laser Digital (Nomura Group), serta berbagai bank Tier 1 dan hedge fund.

Beberapa catatan deployment praktis:

• QuestDB mendukung protokol wire PostgreSQL, sehingga sebagian besar library klien PG bekerja langsung
• Untuk ingestion throughput tinggi, InfluxDB Line Protocol (ILP) melalui HTTP atau TCP adalah jalur yang direkomendasikan
• Protocol Version 2 (dari QuestDB 9.0+) menambahkan encoding biner untuk array dan double, secara signifikan mengurangi bandwidth dan overhead pemrosesan sisi server
• Pembuatan skema otomatis dan perubahan skema secara bersamaan memungkinkan Anda menangani beberapa aliran data dengan modifikasi on-the-fly

Edisi Enterprise menambahkan RBAC (termasuk izin tingkat kolom), enkripsi TLS, replikasi dan failover otomatis, penyimpanan bertingkat ke cloud object store, serta dukungan khusus dengan SLA. Untuk lingkungan teregulasi, ini adalah persyaratan dasar.

Apa yang Akan Datang di Bagian 2 dan 3

Di Bagian 2, kita akan menyelami ekstensi SQL time-series QuestDB secara mendalam — SAMPLE BY, ASOF JOIN, HORIZON JOIN, WINDOW JOIN, dan LATEST ON — dengan contoh trading dunia nyata. Ini bukan peningkatan inkremental dari SQL standar; ini adalah alat yang pada dasarnya berbeda yang menghilangkan seluruh kategori query kompleks.

Di Bagian 3, kita akan membahas aplikasi trading praktis: materialized view untuk OHLC real-time, array 2D untuk analitik order book, dan arsitektur lengkap platform algorithmic trading bertenaga QuestDB.

Nantikan.

Kutipan

@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/id/blog/post/questdb-algotrading-architecture},
  version = {0.1.0},
  description = {Selami arsitektur penyimpanan tiga tingkat QuestDB dan desain skema untuk sistem algorithmic trading.}
}