Algoritmik Trading için QuestDB: Piyasaların Dilini Konuşan Mimari

3'lü serinin 1. Bölümü — ayrıca şu dillerde mevcuttur: RU · ZH

Uyarı: Bu makalede sunulan bilgiler yalnızca eğitim ve bilgilendirme amacıyla sağlanmakta olup finansal, yatırım veya trading tavsiyesi niteliği taşımamaktadır. Kripto para ticareti önemli kayıp riskleri içermektedir.

Merhaba! Bugün QuestDB'ye üç bölümlük derinlemesine bir dalışa başlıyoruz — modern trading altyapısının sessiz sedasız omurgası haline gelen açık kaynaklı bir zaman serisi veritabanı. Bu, bir "en iyi 10 veritabanı" listesi yazısı değil. Teknik detaylara gireceğiz, çünkü algoritmik trading bunu gerektiriyor.

InfluxDB'nin kardinalite sınırlarıyla boğuştunuz, TimescaleDB'nin tick verisi üzerindeki ek yüklerle mücadele ettiniz ya da PostgreSQL örneğinizin neden saniyede bir milyon ekleme yapamadığını merak ettiniz ise — bu seri tam size göre.

Zaman Serisi Veritabanları Trading İçin Neden Önemlidir

Her algoritmik trading sistemi — basit bir ızgara botundan tam kapsamlı bir HFT motoruna kadar — aynı temel bağımlılığa sahiptir: veri. Özelde, son derece yüksek hızda gelen ve gerçek zamanlı olarak sorgulanabilmesi gereken zaman sıralı veri.

Geleneksel ilişkisel veritabanları bunun için tasarlanmadı. ACID işlemleri ve normalleştirilmiş şemalar üzerinde karmaşık birleştirmelerde başarılıdırlar, ancak finansal piyasaları tanımlayan, eklemeler ağırlıklı, zaman bölümlü iş yüklerinde tıkanırlar. Veritabanının sizin için çalışmasına izin vermek yerine onunla savaşmak zorunda kalırsınız.

Zaman serisi veritabanları bu paradigmayı tersine çevirir. Verilerinizin bir zaman damgasına sahip olduğunu, yaklaşık olarak sıralı geldiğini ve sorgularınızın neredeyse her zaman zaman aralıklarını içereceğini varsayarlar. QuestDB bunu bir adım öteye taşıyarak özellikle sermaye piyasaları göz önünde bulundurularak tasarlanmıştır — mühendislik ekibi Tier 1 yatırım bankalarından (BoA, UBS, HSBC) gelmektedir ve bu durum her tasarım kararına yansımaktadır.

QuestDB'ye Genel Bakış

QuestDB, sıfır-GC Java, C++ ve Rust ile yazılmış açık kaynaklı (Apache 2.0) bir zaman serisi veritabanıdır. "Sıfır-GC" kısmı kritiktir: çekirdek motor, JVM tabanlı sistemlerin büyük çoğunluğunu etkileyen öngörülemeyen gecikme artışlarını ortadan kaldırmak için Java'nın çöp toplayıcısından tamamen kaçınarak belleği manuel olarak yönetir.

Dikkat çekmeye değer temel performans özellikleri:

• Tek bir sunucuda saniyede milyonlarca satır alma kapasitesi
• SIMD talimatlarıyla vektörleştirilmiş yürütme sayesinde milisaniyenin altında sorgu gecikmesi
• Yerel nanosaniye hassasiyetinde zaman damgaları — tick verisi için zorunlu
• Hem sıcak hem de soğuk veri için optimize edilmiş üç katmanlı depolama mimarisi
• Güçlü zaman serisi uzantılarına sahip SQL arayüzü

Ancak ham sayılar hikayenin yalnızca bir bölümünü anlatır. QuestDB'yi trading sistemleri için gerçekten ilginç kılan şey, verileri nasıl depolayıp sorguladığıdır.

Üç Katmanlı Depolama Motoru

QuestDB'nin mimarisi burada zarafetini ortaya koyar. Veriler, her biri farklı bir erişim modeli için optimize edilmiş üç ayrı katmandan geçer:

Katman 1: WAL (Write-Ahead Log)

Gelen veriler önce Write-Ahead Log'a düşer. Bu, ultra düşük gecikmeli ekleme katmanınızdır. Her yazma işlemi, herhangi bir işlem gerçekleşmeden önce kalıcı hale getirilir — çökmeler ve güç kesintilerinde veri kaybı olmadan hayatta kalır. WAL yalnızca sıralı yazma yapılabilir şekilde tasarlanmıştır, bu da modern SSD'ler ve NVMe sürücülerle mükemmel uyum sağlar.

Trading sistemleri için bu, piyasa verisi alım hattınızın yazma amplifikasyonu veya kilit çakışması konusunda endişelenmeden QuestDB'ye veri gönderebileceği anlamına gelir. İster 50 kripto borsasından WebSocket güncellemeleri alıyor olun ister FIX mesajları akışını işliyor olun, WAL hepsini emer.

WAL ayrıca nesne depolamaya asenkron olarak aktarılır; bu sayede yeni replikaların hızla başlaması ve aynı geçmişi okuması mümkün olur — üretim trading ortamlarında felaket kurtarma için kritik bir özelliktir.

Katman 2: Sütunsal Depolama

Asenkron olarak veriler zaman sırasına konulur, tekilleştirilir ve QuestDB'nin yerel sütunsal formatında yazılır. Bu format, zaman bölümlüdür (veri hacminize bağlı olarak saate, güne, haftaya veya aya göre) ve anında sorgulanabilir.

Sütunsal düzen, QuestDB'nin sorgu performansını mümkün kılan şeydir. Son bir saatteki BTC-USD ortalama fiyatını sorduğunuzda, motor tüm satırları değil yalnızca ilgili zaman bölümlerinden price sütununu okur. Birden fazla çekirdekte SIMD-vektörleştirilmiş yürütmeyle birleştiğinde, gerçek zamanlı gösterge panellerini ve canlı strateji hesaplamalarını mümkün kılan milisaniyenin altındaki sorgu süreleri elde edilir.

Her tablo, sabit boyutlu tipler için sütun başına bir dosya ve değişken boyutlu tipler (VARCHAR gibi) için iki dosya olmak üzere sütun başına ayrı dosyalar olarak depolanır. Bu düzen, zaman serisi analitiğinde baskın olan sıralı taramalar için özel olarak tasarlanmıştır.

Katman 3: Nesne Depolama (Parquet)

İşte maliyet yönetiminin birlikte çalışabilirlikle buluştuğu yer. Eski bölümler otomatik olarak Apache Parquet formatına dönüştürülür ve nesne depolamaya (S3, Azure Blob, GCS) aktarılır. Ancak — ve bu temel yeniliktir — bunları QuestDB'nin SQL arayüzü üzerinden şeffaf bir şekilde sorgulamaya devam edebilirsiniz. Sorgu planlayıcısı üç katmanı da sorunsuz biçimde kapsar.

Algoritmik traderlar için bu, terabaytlarca SSD depolama için ödeme yapmaksızın yıllarca geriye dönük test için erişilebilir geçmiş tick verisi tutabileceğiniz anlamına gelir. Python geriye dönük test çerçeveniz, herhangi bir veritabanı dışa aktarımı gerekmeksizin Polars, Pandas veya Spark aracılığıyla aynı Parquet dosyalarını doğrudan okuyabilir. ML eğitim hattınız, bellek içi işleme için Arrow/ADBC aracılığıyla aynı verilere erişebilir. Sıfır tedarikçi bağımlılığı.

Bu, verilerinizi tek bir sorgu arayüzünün arkasına hapseden tescilli veritabanı formatlarından köklü biçimde farklı bir tekliftir.

Trading Verisi İçin Şema Tasarımı

QuestDB'nin şema tasarım felsefesi, trading verisiyle mükemmel örtüşen birkaç kritik kavram etrafında şekillenir:

Belirlenmiş Zaman Damgası

Her zaman serisi tablosunun belirlenmiş bir zaman damgası sütununa ihtiyacı vardır. Bu yalnızca meta veri değildir — fiziksel depolama sırasını belirler ve bölüm budamasını mümkün kılar. Olmadan QuestDB'nin performans avantajlarının büyük bölümünü kaybedersiniz:

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

SYMBOL Tipi

SYMBOL tipi, QuestDB'nin yüksek kardinaliteli dize sorununa yanıtıdır. "BTC-USD" veya "ETH-USDT" gibi işlem çiftleri tam sayı indeksli sözlük girdileri olarak depolanır. SYMBOL sütunlarında filtreleme ve gruplama, VARCHAR'a kıyasla çok daha hızlıdır — QuestDB derleme zamanında dize karşılaştırmalarını tam sayı karşılaştırmalarına çevirir.

Binlerce işlem çiftiyle 100'den fazla borsadan veri alıyorsanız, bu optimizasyon tek başına bir sorgunun 5ms mi yoksa 500ms mi süreceği arasındaki farkı yaratabilir.

Bölümleme Stratejisi

Bölüm boyutu, veri hacminizle eşleşmelidir. Yüksek frekanslı tick verisi (sembol başına günde milyonlarca satır) PARTITION BY HOUR kullanmalıdır. Düşük hacimli günlük kapanış fiyatı verisi PARTITION BY MONTH ile gayet iyi çalışır. Amaç, verimli budamayı mümkün kılarken ayrı bölümleri yönetilebilir tutmaktır:

-- Yüksek hacimli tick verisi
CREATE TABLE ticks (...) TIMESTAMP(ts) PARTITION BY HOUR;

-- Düşük hacimli günlük fiyatlar
CREATE TABLE eod_prices (...) TIMESTAMP(ts) PARTITION BY MONTH;

Veri Tekilleştirme

Gerçek dünya trading sistemlerinde yinelenen veri kaçınılmazdır. Ağ yeniden iletimleri, güvenilirlik için yedekli borsa bağlantıları, kurtarma sırasında geçmiş verilerin yeniden oynatılması — bunların hepsi yinelemeler üretir. QuestDB bunu yerel olarak işler: etkinleştirildiğinde, tekilleştirme eşleşen satırları yeni sürümlerle değiştirir ve yalnızca gerçekten yeni satırlar eklenir.

Performans etkisi, veri modelinize bağlıdır. Zaman damgaları satırlar arasında çoğunlukla benzersizse ek yük minimumdur. En zorlu durum, birçok satırın aynı zaman damgasını paylaştığı ve ek sütunlarda tekilleştirme gerektirdiği durumdur — birden fazla fiyat seviyesinin aynı anda güncellendiği emir defteri anlık görüntülerinde yaygındır.

Üretim Dağıtım Konuları

QuestDB'nin üretim kullanıcıları arasında B3 (Latin Amerika'nın en büyük borsası), One Trading (saniyede 4 milyona kadar satır alan düzenlenmiş kripto borsası), Laser Digital (Nomura Grubu) ve çok sayıda Tier 1 banka ve hedge fonu yer almaktadır.

Pratik dağıtım notları:

• QuestDB PostgreSQL wire protokolünü destekler, dolayısıyla çoğu PG istemci kütüphanesi kutudan çıktığı gibi çalışır
• Yüksek verimli alım için HTTP veya TCP üzerinden InfluxDB Line Protocol (ILP) önerilen yoldur
• Protokol Sürüm 2 (QuestDB 9.0+'dan itibaren) diziler ve double'lar için ikili kodlama ekler, bant genişliğini ve sunucu tarafı işlem yükünü önemli ölçüde azaltır
• Otomatik şema oluşturma ve eş zamanlı şema değişiklikleri, anında yapılan değişikliklerle birden fazla veri akışını yönetmenizi sağlar

Enterprise sürümü RBAC (sütun düzeyi izinler dahil), TLS şifreleme, otomatik replikasyon ve yük devretme, bulut nesne depolarına katmanlı depolama ve SLA'lı özel destek ekler. Düzenlenmiş ortamlar için bunlar olmazsa olmaz gereksinimlerdir.

2. ve 3. Bölümlerde Neler Var

2. Bölüm'de QuestDB'nin zaman serisi SQL uzantılarına — SAMPLE BY, ASOF JOIN, HORIZON JOIN, WINDOW JOIN ve LATEST ON — gerçek dünya trading örnekleriyle derinlemesine ineceğiz. Bunlar standart SQL'e göre artımlı iyileştirmeler değil; karmaşık sorguların tüm kategorilerini ortadan kaldıran temelden farklı araçlardır.

3. Bölüm'de pratik trading uygulamalarını ele alacağız: gerçek zamanlı OHLC için materyalize görünümler, emir defteri analitiği için 2D diziler ve QuestDB destekli bir algoritmik trading platformunun tam mimarisi.

Takipte kalın.

Atıf

@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/tr/blog/post/questdb-algotrading-architecture},
  version = {0.1.0},
  description = {QuestDB'nin üç katmanlı depolama mimarisi ve algoritmik trading sistemleri için şema tasarımı üzerine derinlemesine bir inceleme.}
}