Limbo - SQLite’ın Rust ile Baştan Sona Yeniden Yazımı

• Limbo, bellek güvenliği sağlayan Rust ile SQLite’ı yeniden uygulamayı amaçlayan deneysel bir proje
  • SQLite’ın gömülü yapısını beğeniyorlar, ancak daha açık bir geliştirme modeli istedikleri için libSQL projesini başlattılar
• SQLite’ı fork etme nedeni: yeni özellikleri kolayca entegre edebilmek ve mevcut kodla uyumluluğu koruyabilmek
  • Dezavantajı: SQLite’ın test paketi kapalı kaynak ve C ile yazılmış olduğu için kodun evrimi zorlaşıyor
• Yeni yaklaşım
  • Vektör arama özelliği eklerken SQLite’ın sınırlarıyla karşılaştılar
  • SQLite’ı sıfırdan yeniden yazarak, uyumluluğu korurken daha agresif özellik ekleme olasılıklarını araştırıyorlar
• Sonraki adımlar
  • Limbo’yu resmi bir Turso projesine dönüştürmek
  • SQLite ile aynı güvenilirliği korurken bellek güvenliği sunan yeni bir mimari kurmayı hedefliyorlar
• SQLite’ın güvenilirliğine meydan okumak
  • Deterministik simülasyon testleri (DST) ile yüksek güvenilirlik sağlıyorlar
  • Sistem seviyesinde bir DST çerçevesi kullanmak için Antithesis ile iş birliği yapıyorlar
• Mevcut durum
  • Tam asenkron I/O: Limbo tamamen asenkron bir tasarıma sahip ve SQLite’ın senkron arayüzündeki sorunları çözüyor
  • WASM için tasarım: WASM ortamlarında kullanım gözetilerek tasarlandı
  • Performans: Pek çok iş yükünde SQLite ile aynı seviyede veya daha hızlı performans
  • Sadelik: Modern ortamlarda daha az önemli olan özellikleri kaldırarak daha iyi bir kullanıcı deneyimi sunuyor
• Ek bilgiler
  • Limbo, GitHub’da MIT lisansı ile sunuluyor
  • SQLite’ın vaatlerini bir sonraki aşamaya taşımayı amaçlayan gömülü veritabanları geliştirmekle ilgilenen herkesi davet ediyorlar

[seonwoo960000]

Katkıda bulunduğum projenin Hacker News'te çıkması ilginçmiş haha

[GN⁺]

Hacker News görüşleri

• SQLite, kod kalitesi ve sıkı testleri nedeniyle yeniden yazılmasına gerek olmayan bir proje gibi görünüyor

  • Önce başka C kodlarının yeniden yazılması daha iyi olur görüşü var

• SQLite'ın "açık katkı" olmadığı yönündeki tartışma, katkı kabul etmenin her zaman her katkıyı benimsemek anlamına gelmediğini gözden kaçırıyor

  • SQLite'ın katkılar için bir süreci var ve önerilen özellikleri bu şekilde hayata geçiriyor
  • Litestream ve LiteFS gibi SQLite ekosistemindeki diğer projeler de benzer katkı politikalarına sahip

• SQLite3'ten LibSQL'e yapılan fork'un ilk duyurusuna karşı olumsuz bir tutum vardı

  • SQLite3'ün test paketi özel mülkiyetli olduğu için fork'un başarısız olma ihtimalinin yüksek olduğu düşünülüyordu
  • Ancak bellek güvenli bir dile yeniden yazım gibi büyük bir ürün hedefi varsa, fork'un anlamlı olabileceği düşünülüyor

• En yüksek performans için WAL modu seçilmeli ve POSIX advisory locking devre dışı bırakılmalı

  • wal2 modunun projenin radarında olup olmadığını merak eden bir görüş var

• SQLite'ın test paketinin özel mülkiyetli olduğunu bunu ilk kez öğrendiğini söyleyen bir görüş var

  • Android de benzer şekilde inşa edildi, ancak bu başka bir mesele

• async IO bölümündeki mantık ikna edici bulunmuyor

  • SQLite'a asenkron bir arayüz eklemek için yeniden yazım gerektiği düşünülmüyor
  • SQLite'ın senkron arayüzündeki sorun, IO beklenirken thread'in boşta kalması
  • SQLite, depolamaya çok yakın çalışacak şekilde tasarlandığından IO bloklaması çok kısa sürebilir ya da hiç olmayabilir

• Bunun erken aşamadaki bir proje olduğu yönünde bir görüş var

  • Python ve Limbo kullanan bir kod örneği verilmiş

• Fil-C ile derlenirse bellek güvenli bir SQLite elde edilebilir

  • Yalnızca küçük değişiklikler gerekiyor ve test paketini neredeyse tamamen geçiyor

• SQLite yaklaşık 156.000 satır kod ve 92.000 satır test kodundan oluşuyor

• Rust varyantı için DO-178B sertifikasyonunun değerlendirilmediği tahmin ediliyor

• "Limbo" adı, AT&T'nin Inferno işletim sistemi için geliştirilen post-C/UNIX dili için de kullanılmıştı

[aer0700]

SQLite, kod kalitesi ve sıkı testleri sayesinde yeniden yazılmasına gerek olmayan bir proje gibi görünüyor -> SQLite için böyle bir değerlendirme gerçekten kıskandırıcı ve harika.

[regentag]

DO-178B sürecini takip ettiği ve MC/DC kod kapsamı %100’e ulaştığı belirtiliyor.
SQLite’ın bilinmeyen hikayesi