Mencari SQLite yang Lebih Cepat

• SQLite pada dasarnya sudah merupakan sistem basis data yang cepat, tetapi para peneliti sedang mencari cara untuk membuatnya lebih cepat lagi
• Peneliti dari Universitas Helsinki dan Cambridge menerbitkan makalah berjudul "co-design serverless runtime/database through asynchronous I/O" yang menunjukkan bahwa latensi ekor dapat dikurangi hingga 100 kali. Makalah ini menjadi dasar bagi Limbo, SQLite yang ditulis ulang dalam Rust.

io_uring

• Penjelasan io_uring: Subsistem io_uring di kernel Linux menyediakan antarmuka untuk I/O asinkron. Ini mengurangi overhead penyalinan buffer melalui ring buffer antara ruang pengguna dan ruang kernel. Aplikasi dapat mengajukan permintaan I/O dan mengerjakan tugas lain sampai menerima notifikasi dari OS bahwa operasi I/O telah selesai.

• Eksekusi kueri SQLite: SQLite menggunakan file untuk penyimpanan data, membuka basis data dengan fungsi sqlite3_open(), dan mengubah pernyataan SQL menjadi bytecode dengan fungsi sqlite3_prepare(). Fungsi sqlite3_step() mengeksekusi instruksi bytecode untuk memproses kueri.

Premis

• Meningkatnya komputasi serverless: Dalam lingkungan serverless, latensi basis data dapat menjadi masalah. Jika basis data langsung disematkan ke edge runtime, tidak ada latensi jaringan, dan SQLite cocok untuk lingkungan seperti ini.

• Masalah SQLite: Penggunaan I/O sinkron membuat pemakaian sumber daya tidak optimal serta menimbulkan masalah konkurensi dan multi-tenant.

• Peralihan ke io_uring: Mengganti pemanggilan I/O POSIX dengan io_uring bukan hal yang sederhana; SQLite perlu didesain ulang agar sesuai dengan model I/O asinkron.

Limbo

• Dukungan I/O asinkron: Komponen VM dan BTree dimodifikasi untuk mendukung I/O asinkron, dan instruksi bytecode sinkron diganti dengan instruksi asinkron. I/O asinkron menghilangkan blocking dan meningkatkan konkurensi.

• Pemisahan query dan storage engine: Diusulkan untuk memisahkan mesin kueri dan mesin penyimpanan guna memaksimalkan penggunaan sumber daya.

Evaluasi dan hasil

• Benchmarking: Runtime serverless multi-tenant disimulasikan sehingga setiap tenant memiliki basis data tertanamnya sendiri. Hasil perbandingan latensi kueri antara SQLite dan Limbo menunjukkan bahwa Limbo mengurangi latensi ekor di p999 hingga 100 kali.

• Pekerjaan lanjutan: Benchmark tambahan yang mencakup banyak pembaca dan penulis sedang direncanakan, dan keunggulan performa hanya tampak menonjol setelah p999.

• Kode open source: Kode Limbo tersedia sebagai open source: Limbo GitHub

[GN⁺]

Komentar Hacker News

• Ada diskusi bahwa kasus penggunaan tertentu untuk komputasi serverless, misalnya AWS Lambda dan database terpusat, tidak selalu cocok dengan aplikasi yang dibangun dengan pendekatan serverless

  • Ada pengalaman mengerjakan solusi 6–7 tahun lalu untuk menangani berkas hierarkis yang kompleks dan mengekstrak informasi tertentu
  • FaaS mahal untuk pekerjaan yang mahal secara komputasi, dan memuat serta mem-parsing file XML besar setiap kali itu tidak efisien
  • Sebagai solusi, digunakan fungsi terpusat dengan timer untuk membaca dan mem-parsing file, memuatnya ke database SQLite, mengindeksnya, lalu menyimpan file tersebut ke S3
  • Fungsi Lambda akan mengunduh file dari S3 dan menjalankan pencarian saat file itu lebih baru daripada salinan lokal atau saat cold start
  • Diketahui bahwa Lambda memiliki direktori lokal /tmp dan runtime Python sudah menyertakan SQLite, jadi tidak perlu mengunggah kode lain selain fungsi itu sendiri
  • Menarik melihat adanya pekerjaan yang sedang berlangsung untuk membuat solusi seperti ini menjadi lebih cepat

• Mungkin layak disebutkan bahwa salah satu dari dua peneliti itu adalah atasan penulis

  • Sempat salah mengira bahwa penulis dan penelitinya tidak memiliki hubungan

• Setuju bahwa "manfaatnya hanya benar-benar terlihat di atas p999, sedangkan pada p90 dan p99 performanya hampir sama dengan SQLite"

  • Menyukai SQLite dan optimisasi, tetapi ini memang benar

• SQLite memiliki test suite yang sangat luas sehingga telah diuji secara menyeluruh

  • Ada pertanyaan apakah penulisan ulang ini akan mendapatkan pengujian serupa, terutama jika memakai fitur seperti io_uring yang cepat tetapi sulit ditulis dan berpotensi buggy

• Untuk benchmarking, disimulasikan runtime serverless multi-tenant di mana setiap tenant memiliki database embedded sendiri

  • SQLite memiliki thread tersendiri per tenant dan pengukuran dilakukan dengan menjalankan kueri pada masing-masing thread
  • Muncul pertanyaan apakah konfigurasi SQLite serverless akan menggunakan proses SQLite per request

• Sebelumnya pernah ada upaya untuk memperkenalkan async io ke Postgres, tetapi dihentikan

  • Proposal terbaru adalah memungkinkan storage manager diganti dengan implementasi kustom tanpa perlu mem-fork codebase
  • Ada minat besar terhadap proposal baru ini, dan hal itu terkait dengan pergerakan memisahkan storage dan compute

• Ada pertanyaan tentang gagasan bahwa ketika async io sedang bekerja, pekerjaan lain bisa dilakukan sementara itu

  • Ada pertanyaan apakah saat bekerja dengan database tetap harus menunggu transaksi selesai

• Sebagai penulis posting blog tersebut, tidak menyangka tulisan ini akan naik ke halaman depan

  • Bekerja di Turso, makalahnya diterbitkan pada April 2024, dan sejak itu sudah ada banyak perbaikan

• SQLite bersifat open source, tetapi test harness pentingnya tidak

  • Ada pertanyaan bagaimana alternatifnya akan menjamin kompatibilitas

• Pernah mencoba mencari jalur sederhana untuk membuat format mirip JSON sebagai subset ketat dari format file SQLite, tetapi gagal

  • Ada begitu banyak unsur arbitrer dalam format file itu sehingga minat pun hilang, meski orang lain mungkin bisa berhasil