TarsDB İçinde Rust ve In-Memory Yönetimi

Geleneksel Çöplük Toplayıcı (GC) Problemi

Veritabanı dilleri genellikle C++ veya Java üzerinde yükselir. Java (ve türevleri) devasa bir Garbage Collector yükü taşır. TarsDB Sense kodlanırken asıl amacımız, veriyi işlemekten çok GC duraklamalarından kurtulmaktı.

Rust, ownership ve borrowing konsepti ile bize aradığımız harika anahtarı verdi.

Sıfır Kopya Mimarisi (Zero-Copy)

TarsDB'nin CSV veya Excel gibi devasa dosyalardan veri okuduğu pipeline'ı düşünün:

pub fn parse_columnar_data(buffer: &[u8]) -> Result<Vec<&[u8]>, EbpfError> {
    // Burada bellek kopyalanmaz, dilim (slice) olarak referans alınır.
    let mut columns = Vec::new();
    let mut current_pos = 0;
    
    while current_pos < buffer.len() {
        // ... Zero-copy okuma mantığı
    }
    
    Ok(columns)
}

Bu fonksiyon, TB'larca veriyi okurken bile RAM'de çılgınca bir artışa (spike) neden olmaz çünkü buffer kopyalanmamaktadır.

Associative Engine'in Rust ile Flörtü

Qlik Sense'ten ilham alınan Associative Logic, yeşil, beyaz ve gri tablo satırlarının sürekli bellekte haritalanması anlamına gelir. Rust'ın BTreeMap ve BitVec kütüphaneleri kullanılarak, satırların hangi state'te (Selected, Alternative, Excluded) olduğu O(1) hızında bulunur.

1. Yeşil (Selected): Aktif filtre.
2. Beyaz (Alternative): Seçilebilir diğer koşullar.
3. Gri (Excluded): Bu kümeye dahil olmayanlar.

Sonuç mu? TarsDB, "Nebula" vizyonunda pürüzsüz bir O(1) erişim zamanıyla ve tam bellek güvenliği ile devasa verileri frontend'e sızdırır.