Daha Hızlı SQLite Arayışı

• SQLite zaten hızlı bir veritabanı sistemi, ancak araştırmacılar onu daha da hızlandırmanın yollarını arıyor.
• Helsinki Üniversitesi ve Cambridge'den araştırmacılar, "Asenkron I/O ile sunucusuz çalışma zamanı/veritabanı ortak tasarımı" başlıklı bir makale yayımlayarak kuyruk gecikmesini (latency) 100 kata kadar azaltmanın mümkün olduğunu gösterdi. Bu makale, Rust ile yeniden yazılmış bir SQLite olan Limbo'nun temelini oluşturuyor.

io_uring

• io_uring açıklaması: Linux çekirdeğinin io_uring alt sistemi, asenkron I/O için bir arayüz sağlar. Bu, kullanıcı alanı ile çekirdek alanı arasındaki ring buffer üzerinden tampon kopyalama ek yükünü azaltır. Uygulamalar I/O isteklerini gönderip, işletim sisteminden I/O işleminin tamamlandığı bildirimini beklerken başka işler yapabilir.

• SQLite'in sorgu yürütmesi: SQLite verileri depolamak için dosyalar kullanır ve sqlite3_open() fonksiyonuyla veritabanını açar, sqlite3_prepare() fonksiyonuyla SQL ifadelerini bytecode'a dönüştürür. sqlite3_step() fonksiyonu ise bytecode komutlarını çalıştırarak sorguyu işler.

Öncül

• Sunucusuz bilişimin yükselişi: Sunucusuz ortamlarda veritabanı gecikmesi sorun yaratabilir. Veritabanını doğrudan edge runtime içine gömmek gecikmeyi ortadan kaldırır ve SQLite bu tür ortamlar için uygundur.

• SQLite'in sorunları: Senkron I/O kullanımı nedeniyle kaynak kullanımı en iyi seviyede değildir ve eşzamanlılık ile çoklu kiracılık sorunlarına yol açar.

• io_uring'e geçiş: POSIX I/O çağrılarını io_uring ile değiştirmek basit değildir; SQLite'in asenkron I/O modeline uyacak şekilde yeniden tasarlanması gerekir.

Limbo

• Asenkron I/O desteği: VM ve BTree bileşenleri asenkron I/O'yu destekleyecek şekilde değiştirilmiş ve senkron bytecode komutları asenkron komutlarla değiştirilmiştir. Asenkron I/O, bloklamayı ortadan kaldırır ve eşzamanlılığı artırır.

• Sorgu ve depolama motorunun ayrılması: Kaynak kullanımını en üst düzeye çıkarmak için sorgu motoru ile depolama motorunun ayrılması öneriliyor.

Değerlendirme ve sonuçlar

• Benchmark: Her kiracının kendi gömülü veritabanına sahip olduğu çok kiracılı bir sunucusuz çalışma zamanı simüle edildi. SQLite ile Limbo'nun sorgu gecikmesi karşılaştırıldığında, Limbo p999 düzeyinde kuyruk gecikmesini 100 kat azalttı.

• Gelecek çalışmalar: Birden fazla okuyucu ve yazarı içeren ek benchmark'lar planlanıyor; performans avantajı özellikle yalnızca p999 sonrasında belirginleşiyor.

• Açık kaynak kod: Limbo'nun kodu açık kaynak olarak sunuluyor: Limbo GitHub

[GN⁺]

Hacker News görüşleri

• AWS Lambda gibi örneklerde sunucusuz bilişimin belirli kullanım senaryolarının, merkezi veritabanının da sunucusuz şekilde kurulduğu uygulamalarla her zaman iyi örtüşmediğine dair bir tartışma var

  • 6-7 yıl önce karmaşık hiyerarşik dosyaları işleyip belirli bilgileri çıkarması gereken bir sorunu çözmek için çalıştığı bir deneyimden bahsediliyor
  • FaaS, hesaplama açısından pahalı işler için maliyetliydi; büyük XML dosyalarını her seferinde yükleyip ayrıştırmak verimsizdi
  • Çözüm olarak, dosyaları bir zamanlayıcıyla okuyup ayrıştıran, ardından bunları bir SQLite veritabanına yükleyip indeksleyen ve dosyayı S3'e kaydeden merkezi bir işlev kullanıldı
  • Lambda işlevleri, dosya yerel kopyadan daha yeniyse ya da cold start durumunda sorgu yapmak için dosyayı S3'ten indiriyordu
  • Lambda'da yerel /tmp dizini bulunduğu ve Python çalışma zamanına SQLite dahil olduğu için işlevin dışında ayrıca kod yüklemeye gerek olmadığının fark edildiği belirtiliyor
  • Bu tür bir çözümün daha da hızlanabileceğine yönelik çalışmaların ilgi çekici olduğu ifade ediliyor

• İki araştırmacıdan birinin yazarın yöneticisi olduğunu belirtmek faydalı olabilir

  • Yazar ile araştırmacıların ilişkili olmadığını yanlış düşündüğü söyleniyor

• "Yararlar yalnızca p999 ve üzerinde belirgin hale geliyor; p90 ve p99'da performans SQLite ile neredeyse aynı" görüşüne katılınıyor

  • SQLite ve optimizasyonu sevse de bunun doğru olduğu belirtiliyor

• SQLite kapsamlı bir test paketine sahip, yani çok ayrıntılı biçimde test ediliyor

  • Yeniden yazımın benzer testlerden geçip geçmeyeceği, özellikle de hızlı ama yazması zor ve potansiyel olarak hatalı özellikler olan io_uring gibi şeyler kullanıldığında, sorgulanıyor

• Kıyaslama için, her kiracının kendi gömülü veritabanına sahip olduğu çok kiracılı bir sunucusuz çalışma zamanı simüle edilmiş

  • SQLite her kiracı için kendi thread'ine sahip ve ölçüm için sorgular her thread'de çalıştırılıyor
  • Sunucusuz SQLite kurulumunun istek başına bir SQLite süreci kullanıp kullanmayacağı sorgulanıyor

• Daha önce Postgres'e async io getirmeye yönelik bir girişim olmuş, ancak durdurulmuş

  • Son dönemdeki öneri, kod tabanını fork etmeden depolama yöneticisinin özel olarak değiştirilebilmesini sağlamak
  • Yeni öneriye büyük ilgi olduğu ve bunun depolama ile hesaplamayı ayırma eğilimiyle ilişkili olduğu belirtiliyor

• Async io çalışırken başka işler yapılabileceği fikrine dair bir soru var

  • Veritabanı işi yapılırken işlem tamamlanmasını beklemek gerekip gerekmediği sorgulanıyor

• Blog yazısının yazarı olarak, bu yazının ana sayfaya çıkmasını beklemediğini söylüyor

  • Turso'da çalıştığını, makalenin 2024 Nisan'ında yayımlandığını ve o zamandan beri birçok iyileştirme yapıldığını belirtiyor

• SQLite açık kaynaklı, ancak kritik test harness'i açık kaynak değil

  • Alternatiflerin uyumluluğu nasıl garanti edeceğine dair soru soruluyor

• SQLite dosya biçiminin sıkı bir alt kümesi olarak JSON benzeri bir biçim oluşturmak için basit bir yol aramış ama bulamamış

  • Dosya biçiminde çok fazla keyfilik olduğunu düşündüğü için ilgisini kaybettiğini, ama başka birinin başarılı olabileceğini söylüyor