TurboKV: atomik batch yazımı, range scan ve compaction destekli gömülü Rust key-value deposu

LSM tarzı bir motor ve ayırt edici bir detay

Rust ile yazılmış açık kaynaklı gömülü key-value deposu TurboKV, GitHub deposu (kingroryg/turbokv) üzerinden Hacker News ana sayfasına ulaştı. Projenin README'sine göre veritabanı tamamen asenkron, ayrı bir sunucu olarak değil process içinde çalışıyor ve atomik batch yazımları, sıralı range ve prefix scan'leri, ayarlanabilir dayanıklılığı, sıkıştırmayı ve arka plan compaction'ı bir arada sunuyor. Güncel sürüm 0.6 ve Tokio ile birlikte bir Cargo crate olarak kuruluyor.

Belgelenen bileşen seti tanıdık log-structured araç takımı: arka planda dönen ve flush edilen bellek içi memtable, çökme kurtarma için write-ahead log, diskte değişmez SSTable'lar, bir manifest ve sıkıştırılmamış bloklar için block cache. Compaction arka planda gerçekleşiyor. Alışılmadık bir detay ise donanım AES talimatlarına yaslanan kalıcı Bloom-filter formatı; README, geliştiricilere x86 hedeflerinde AES ve SSE2'yi, ARM'da AES ve NEON'u etkinleştirmeyi ya da binary yalnızca aynı CPU ailesinde çalışacaksa target-cpu=native ile derlemeyi öneriyor.

Varsayılanlar iddialı. Her dayanıklılık preset'i 64 MiB memtable, 64 MiB block cache ve LZ4 sıkıştırmasıyla başlıyor; alternatif olarak Snappy, Zstd ve sıkıştırma yok seçenekleri var. Sıkıştırma yalnızca yeni yazılan SSTable'lara uygulanıyor; mevcut tablolar oluşturuldukları kodlamayı koruyor.

Üç dayanıklılık preset'i

Dayanıklılık, veritabanı açılırken seçiliyor ve README, onlarca ayardan oluşan bir duvar yerine üç adlandırılmış preset tanımlıyor:

• DbOptions::fast() yazımları bellekte görünür oldukları anda onaylıyor ve hiç WAL kullanmıyor. Cache'ler ve yeniden üretilebilir veriler için hedeflenmiş.
• DbOptions::durable(), önerilen varsayılan, her yazımda sync yapmadan WAL'a ekliyor ve process çökmelerinden kurtuluyor.
• DbOptions::paranoid() bir mutasyonu onaylamadan önce WAL grubunda tamamlanmış bir sync_all bekliyor. Bu en güçlü mod; garantiler dosya sistemi ve cihazın sınırlarıyla çerçeveleniyor.

Bireysel alanlar — wal_enabled, sync_writes, memtable_size, block_cache_size ve compression — yine ayarlanabiliyor ve WAL kapalıyken yazım sync'i istemek gibi çelişkili kombinasyonlar açılış anında reddediliyor.

Yazımlar ve atomikliğin buradaki gerçek anlamı

write_batch öne çıkan mutasyon API'si: okuyucular ya batch öncesi durumu ya da tamamen uygulanmış batch'i görüyor ve yinelenen anahtarlarda son işlem kazanıyor. Buna karşılık insert_many açıkça bir toplu kullanım kolaylığı API'si olarak etiketlenmiş, atomik bir görünürlük geçişi değil — birçok depanın belgelemediği bir ayrım.

Nokta işlemleri bayt odaklı semantiği izliyor. Anahtarlar ve değerler rastgele bayt dizileri, boş bir değer eksik anahtardan farklı olarak geçerli veri ve remove, var olmayan anahtarlar için bile tombstone yazıyor. README'deki iki uyarı öne çıkıyor: WAL etkinken tek bir kayıt veya batch, WAL'ın u32 payload uzunluğuna sığmalı; ayrıca başarısız veya iptal edilmiş bir mutasyon log'a ulaşmış olabilir, bu yüzden çağıranlar idempotent olmayan bir işlemi yeniden denemeden önce anahtarı kontrol etmeye veya veritabanını yeniden açmaya yönlendiriliyor.

Scan'ler, snapshot'lar ve iterator hijyeni

Anahtarlar ham baytlara göre leksikografik olarak sıralı. range ve scan_prefix gibi eager API'ler tüm sonucu baştan tahsis ederken, range_iter ve scan_prefix_iter streaming varyasyonları değerleri tembel yükleyen guard öğeleri üretiyor; bozulma, iterator ilerlerken hata olarak ortaya çıkıyor. Streaming arayüzü sayma, yalnızca anahtar toplama, çift toplama ve atlanan girdilerin memtable değerlerini kopyalamadan geçen offset/limit sayfalaması destekliyor.

README ayrıca gözden kaçırması kolay iki maliyeti belgeliyor: her scan tutarlı bir anlık snapshot yakalıyor, ancak bunun oluşturulması boş olmayan aktif bir memtable'ı dondurabiliyor; yani sık yapılan küçük scan'ler sonraki flush işini artırabilir. Ayrıca açık iterator'ler snapshot okuyucularını sabitliyor, bu yüzden derhal düşürülmeleri (drop) gerekiyor.

Sahiplik ve kapatma

Tek bir Db veya Engine, veri dizinini münhasıran sahiplenir ve bir handle'ı düşürmek açıkça temiz bir kapatma değildir. Çağıranlar close() veya close_with_status() kullanmalı; flush() ise bekleyen yazımları boşaltır ve yeni SSTable'lar ile manifest'i devreye alır.

Neden önemli

Gömülü depolar çoğu sunucu yazılımının tesisatıdır ve Rust ekosisteminde bu alanda zaten yerleşik seçenekler var. TurboKV'nun vaadi, tanınabilir bir LSM tasarımını alışılmadık derecede açık dayanıklılık sınırlarıyla — onlarca birbiriyle etkileşen bayrak yerine üç net adlandırılmış preset — birleştirmesi ve scan-snapshot semantiği ile kapatma sözleşmelerine özenle yaklaşmasıdır. Sürüm 0.6'da henüz genç ve README'nin kendisi WAL payload sınırları ve temiz olmayan handle düşürme gibi keskin kenarları işaret ediyor. Ayrı bir veritabanı process'i işletmeden sıralı scan'lere ve atomik batch'lere ihtiyaç duyan ekipler için bu uyarılar caydırıcı değil, dürüst mühendisliğin kanıtı olarak okunuyor; proje olgunlaştıkça izlenmeye değer.