QuestDB untuk Dagangan Algoritmik: Seni Bina yang Bertutur dalam Bahasa Pasaran

Bahagian 1 daripada 3 — tersedia juga 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. Dagangan mata wang kripto melibatkan risiko kerugian yang signifikan.

Hai! Hari ini kita memulakan penerokaan mendalam tiga bahagian tentang QuestDB — pangkalan data siri masa sumber terbuka yang secara senyap menjadi tulang belakang infrastruktur dagangan moden. Ini bukan senarai "10 pangkalan data terbaik" biasa. Kita akan masuk ke aspek teknikal, kerana itulah yang dituntut oleh dagangan algoritmik.

Jika anda pernah berjuang dengan had kardinaliti InfluxDB, bersengketa dengan overhed TimescaleDB pada data tick, atau tertanya-tanya mengapa instans PostgreSQL anda tidak dapat mengekalkan sejuta sisipan sesaat — siri ini adalah untuk anda.

Mengapa Pangkalan Data Siri Masa Penting untuk Dagangan

Setiap sistem dagangan algoritmik — dari bot grid mudah hingga enjin HFT penuh — mempunyai kebergantungan asas yang sama: data. Khususnya, data bertertib masa yang tiba pada halaju yang luar biasa dan perlu boleh ditanya dalam masa nyata.

Pangkalan data hubungan tradisional tidak direka bentuk untuk ini. Mereka cemerlang dalam transaksi ACID dan cantuman kompleks merentas skema yang dinormalkan, tetapi mereka tersumbat pada beban kerja yang berat pada penambahan dan dipartisi mengikut masa yang menentukan pasaran kewangan. Anda akhirnya berjuang melawan pangkalan data dan bukannya membiarkannya bekerja untuk anda.

Pangkalan data siri masa membalikkan paradigma ini. Mereka menganggap data anda mempunyai cap masa, bahawa ia tiba lebih kurang mengikut urutan, dan bahawa pertanyaan anda hampir selalu melibatkan julat masa. QuestDB membawa ini lebih jauh dengan direka bentuk khusus dengan pasaran modal dalam fikiran — pasukan kejuruteraannya berasal dari bank pelaburan Peringkat 1 (BoA, UBS, HSBC), dan ia ketara dalam setiap keputusan reka bentuk.

QuestDB Sekilas Pandang

QuestDB adalah pangkalan data siri masa sumber terbuka (Apache 2.0) yang ditulis dalam Java zero-GC, C++, dan Rust. Bahagian "zero-GC" adalah kritikal: enjin teras mengelakkan pemungut sampah Java sepenuhnya, mengurus memori secara manual untuk menghapuskan lonjakan kependaman yang tidak dapat diramal yang menjangkiti kebanyakan sistem berasaskan JVM.

Ciri-ciri prestasi utama yang patut diperhatikan:

• Daya pengeluaran pengingesan berjuta baris sesaat pada satu pelayan
• Kependaman pertanyaan di bawah milisaat melalui pelaksanaan yang divektorkan dengan arahan SIMD
• Cap masa kepersisan nanosaat asli — penting untuk data tick
• Seni bina storan tiga peringkat yang dioptimumkan untuk data panas dan sejuk
• Antara muka SQL dengan sambungan siri masa yang berkuasa

Tetapi angka mentah hanya menceritakan sebahagian daripada kisah. Apa yang menjadikan QuestDB benar-benar menarik untuk sistem dagangan adalah cara ia menyimpan dan menanyakan data.

Enjin Storan Tiga Peringkat

Di sinilah seni bina QuestDB menjadi elegan. Data mengalir melalui tiga peringkat berbeza, masing-masing dioptimumkan untuk corak akses yang berbeza:

Peringkat 1: WAL (Log Tulis-Dahulu)

Data masuk pertama kali menghit Log Tulis-Dahulu. Ini adalah lapisan tambahan anda dengan kependaman ultra-rendah. Setiap penulisan dijadikan tahan lama sebelum sebarang pemprosesan berlaku — bertahan daripada ranap dan kegagalan kuasa tanpa kehilangan data. WAL adalah tulisan berjujukan sahaja, yang bermaksud ia berfungsi dengan sempurna dengan SSD moden dan pemacu NVMe.

Untuk sistem dagangan, ini bermakna saluran pengingesan data pasaran anda boleh menghantarkan data ke QuestDB tanpa bimbang tentang penguatan tulis atau pertikaian kunci. Sama ada anda menerima kemas kini WebSocket dari 50 bursa kripto atau memproses sejambak mesej FIX, WAL menyerap semuanya.

WAL juga dihantar secara asinkronan ke storan objek, membolehkan replika baru bootstrap dengan cepat dan membaca sejarah yang sama — sifat yang kritikal untuk pemulihan bencana dalam persekitaran dagangan pengeluaran.

Peringkat 2: Storan Lajur

Secara asinkronan, data diisih mengikut masa, dideduplicatekan, dan ditulis ke dalam format lajur asli QuestDB. Format ini dipartisi mengikut masa (mengikut jam, hari, minggu, atau bulan bergantung pada jumlah data anda) dan boleh ditanya dengan segera.

Susun atur lajur inilah yang membolehkan prestasi pertanyaan QuestDB. Apabila anda meminta harga purata BTC-USD sepanjang jam lepas, enjin hanya membaca lajur price dari partisi masa yang relevan — bukan keseluruhan baris. Digabungkan dengan pelaksanaan yang divektorkan SIMD merentas berbilang teras, ini menghasilkan masa pertanyaan di bawah milisaat yang menjadikan papan pemuka masa nyata dan pengiraan strategi langsung dapat dilaksanakan.

Setiap jadual disimpan sebagai fail berasingan per lajur, dengan jenis saiz tetap mendapat satu fail per lajur dan jenis saiz berubah (seperti VARCHAR) menggunakan dua. Susun atur ini dibina khusus untuk jenis imbasan berjujukan yang mendominasi analitik siri masa.

Peringkat 3: Storan Objek (Parquet)

Di sinilah pengurusan kos bertemu dengan kebolehoperasian. Partisi lama secara automatik ditukar ke format Apache Parquet dan dihantar ke storan objek (S3, Azure Blob, GCS). Tetapi — dan inilah inovasi utamanya — anda masih boleh menanyakannya secara telus melalui antara muka SQL QuestDB. Perancang pertanyaan merangkumi ketiga-tiga peringkat dengan lancar.

Untuk pedagang algoritmik, ini bermakna anda boleh menyimpan data tick sejarah bertahun-tahun yang boleh diakses untuk backtesting tanpa membayar untuk terabait storan SSD. Rangka kerja backtesting Python anda boleh membaca fail Parquet yang sama secara langsung melalui Polars, Pandas, atau Spark — tiada eksport pangkalan data diperlukan. Saluran latihan ML anda boleh mengakses data yang sama melalui Arrow/ADBC untuk pemprosesan dalam memori. Tiada penguncian vendor.

Ini adalah cadangan yang jauh berbeza daripada format pangkalan data proprietari yang memerangkap data anda di sebalik satu antara muka pertanyaan tunggal.

Reka Bentuk Skema untuk Data Dagangan

Falsafah reka bentuk skema QuestDB berkisar sekitar beberapa konsep kritikal yang sejajar dengan sempurna dengan data dagangan:

Cap Masa yang Ditetapkan

Setiap jadual siri masa memerlukan lajur cap masa yang ditetapkan. Ini bukan sekadar metadata — ia menentukan susunan storan fizikal dan membolehkan pemotongan partisi. Tanpanya, anda kehilangan sebahagian besar faedah prestasi QuestDB:

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

Jenis SYMBOL

Jenis SYMBOL adalah jawapan QuestDB kepada masalah rentetan kardinaliti tinggi. Pasangan dagangan seperti "BTC-USD" atau "ETH-USDT" disimpan sebagai entri kamus yang diindeks oleh integer. Penapisan dan pengelompokan pada lajur SYMBOL jauh lebih pantas berbanding VARCHAR — QuestDB menyelesaikan perbandingan rentetan kepada perbandingan integer pada masa kompilasi.

Jika anda menginges data dari 100+ bursa dengan ribuan pasangan dagangan, pengoptimuman ini sahaja boleh menjadi perbezaan antara pertanyaan yang mengambil masa 5ms dan 500ms.

Strategi Partisi

Saiz partisi harus sepadan dengan jumlah data anda. Data tick frekuensi tinggi (berjuta baris sehari per simbol) harus menggunakan PARTITION BY HOUR. Data harga penghujung hari dengan volum lebih rendah berfungsi baik dengan PARTITION BY MONTH. Matlamatnya adalah untuk memastikan partisi individu boleh diurus sambil membolehkan pemotongan yang cekap:

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

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

Deduplicasi Data

Dalam sistem dagangan dunia sebenar, data pendua adalah tidak dapat dielakkan. Penghantaran semula rangkaian, sambungan bursa berlebihan untuk kebolehpercayaan, ulangan data sejarah semasa pemulihan — semua ini menghasilkan pendua. QuestDB menangani ini secara asli: apabila didayakan, deduplicasi menggantikan baris yang sepadan dengan versi baru, dan hanya baris yang benar-benar baru yang disisipkan.

Kesan prestasi bergantung pada corak data anda. Jika cap masa kebanyakannya unik merentas baris, overhed adalah minimum. Kes yang paling menuntut adalah apabila banyak baris berkongsi cap masa yang sama dan memerlukan deduplicasi pada lajur tambahan — biasa dalam syot kilat buku pesanan di mana berbilang tahap harga dikemas kini serentak.

Pertimbangan Penempatan Pengeluaran

Klien pengeluaran QuestDB termasuk B3 (bursa saham terbesar Amerika Latin), One Trading (bursa kripto dikawal yang menginges sehingga 4 juta baris sesaat), Laser Digital (Kumpulan Nomura), dan banyak bank Peringkat 1 dan dana lindung nilai.

Beberapa nota penempatan praktikal:

• QuestDB menyokong protokol wayar PostgreSQL, jadi kebanyakan perpustakaan klien PG berfungsi tanpa konfigurasi tambahan
• Untuk pengingesan daya pengeluaran tinggi, Protokol Garisan InfluxDB (ILP) melalui HTTP atau TCP adalah laluan yang disyorkan
• Versi Protokol 2 (dari QuestDB 9.0+) menambahkan pengekodan binari untuk tatasusunan dan double, mengurangkan lebar jalur dan overhed pemprosesan sisi pelayan secara signifikan
• Penciptaan skema automatik dan perubahan skema serentak membolehkan anda mengendalikan berbilang aliran data dengan pengubahsuaian semasa-semasa

Edisi Enterprise menambah RBAC (termasuk kebenaran peringkat lajur), penyulitan TLS, replikasi dan failover automatik, storan bertingkat ke gedung objek awan, dan sokongan khusus dengan SLA. Untuk persekitaran yang dikawal selia, ini adalah keperluan asas.

Apa yang Akan Datang dalam Bahagian 2 dan 3

Dalam Bahagian 2, kita akan menyelami sambungan SQL siri masa QuestDB secara mendalam — SAMPLE BY, ASOF JOIN, HORIZON JOIN, WINDOW JOIN, dan LATEST ON — dengan contoh dagangan dunia sebenar. Ini bukan penambahbaikan berperingkat ke atas SQL standard; ia adalah alat yang berbeza secara asasnya yang menghapuskan seluruh kategori pertanyaan yang kompleks.

Dalam Bahagian 3, kita akan merangkumi aplikasi dagangan praktikal: pandangan termaterai untuk OHLC masa nyata, tatasusunan 2D untuk analitik buku pesanan, dan seni bina penuh platform dagangan algoritmik berkuasa QuestDB.

Nantikan.

Rujukan

@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/ms/blog/post/questdb-algotrading-architecture},
  version = {0.1.0},
  description = {Penerokaan mendalam ke dalam seni bina storan tiga peringkat QuestDB dan reka bentuk skema untuk sistem dagangan algoritmik.}
}