SQLite: Mode Wal2

Mengaktifkan/menonaktifkan mode Wal2

• Mode "Wal2" di SQLite sangat mirip dengan mode "wal (Write-Ahead Logging)".
• Untuk mengubah database ke mode wal2, gunakan perintah PRAGMA journal_mode = wal2;.
• Tidak bisa langsung beralih dari mode "wal" ke mode "wal2"; harus diubah dulu ke mode rollback.
• Untuk mengubah database mode wal ke mode wal2, gunakan PRAGMA journal_mode = delete; lalu perintah PRAGMA journal_mode = wal2;.
• Database mode wal2 hanya dapat diakses dari versi SQLite yang dikompilasi dari branch tersebut.
• Jika mencoba menggunakan versi SQLite lain, akan muncul error SQLITE_NOTADB.
• Untuk mengubah database mode wal2 ke mode rollback agar bisa diakses dari semua versi SQLite, gunakan perintah PRAGMA journal_mode = delete;.

Kelebihan mode Wal2

• Pada mode wal yang ada saat ini, ketika penulis menulis data ke database, file database tidak dimodifikasi secara langsung, melainkan data baru ditambahkan ke file "-wal".
• Operasi baca membaca data dari file database asli dan file "-wal".
• Pada suatu titik, data disalin dari file "-wal" ke file database, dan ini disebut "checkpoint".
• Checkpoint dapat dijalankan secara eksplisit melalui PRAGMA wal_checkpoint atau sqlite3_wal_checkpoint_v2(), atau dijalankan otomatis dengan mengatur PRAGMA wal_autocheckpoint (pengaturan default).
• Checkpointer tidak memblokir penulis, dan penulis juga tidak memblokir checkpointer.
• Namun, jika penulis menulis ke database selama checkpoint berlangsung, data baru akan ditambahkan ke akhir file wal sehingga file wal bisa terus membesar.
• Dalam mode wal2, tidak ada masalah file wal yang membesar tanpa batas meskipun checkpointer tidak mendapat kesempatan untuk menyelesaikan pekerjaannya tanpa gangguan.
• Mode wal2 menggunakan dua file wal ("-wal" dan "-wal2"), bukan satu.
• Saat data ditulis, penulis mulai menambahkan data baru ke file wal pertama.
• Setelah file wal pertama cukup besar, penulis mulai menambahkan data ke file wal kedua.
• Setelah itu, file wal pertama dapat di-checkpoint, dan ketika file wal kedua cukup besar serta file pertama sudah di-checkpoint, proses akan beralih kembali ke file pertama.

Pemrograman aplikasi

• Dari sudut pandang pengguna, perbedaan utama antara mode wal dan wal2 berkaitan dengan checkpoint.
• Dalam mode wal, checkpoint dapat dicoba kapan saja, tetapi dalam mode wal2, checkpoint baru bisa dilakukan setelah penulis beralih ke file wal "lain".
• Dalam mode wal, wal-hook (callback) dipanggil setelah transaksi di-commit dengan menggunakan jumlah total halaman dalam file wal sebagai argumen.
• Dalam mode wal2, wal-hook dipanggil dengan jumlah total halaman yang belum di-checkpoint di kedua file wal sebagai argumen, atau dengan argumen 0 jika file wal "lain" kosong atau sudah di-checkpoint.
• Klien disarankan menggunakan strategi checkpoint yang sama seperti mode wal untuk database mode wal2.
• wal-hook dipanggil setelah transaksi di-commit ke disk dan kunci database dilepas, tetapi hal itu terjadi di dalam pemanggilan sqlite3_step().
• Dalam sistem BEGIN CONCURRENT, alih-alih menjalankan checkpoint di dalam wal-hook, dapat digunakan thread yang menunda pekerjaan ini sampai application mutex dilepas.

Opini GN⁺

• Mode wal2 di SQLite menawarkan metode journaling baru yang meningkatkan konkurensi dan efisiensi database.
• Menyelesaikan masalah pertumbuhan file wal tanpa batas penting untuk meningkatkan stabilitas dan performa sistem.
• Dengan diperkenalkannya mode wal2, developer perlu meninjau ulang strategi checkpoint database dan mengimplementasikan logika checkpoint yang tepat untuk konkurensi yang lebih baik.

[GN⁺]

Opini Hacker News

• Dalam mode WAL2, dua file WAL digunakan, bukan satu. File-file tersebut dinamai "<database>-wal" dan "<database>-wal2". Saat data ditulis ke database, operasi penulisan dimulai dengan menambahkan data baru ke file WAL pertama. Ketika file WAL pertama menjadi cukup besar, operasi penulisan beralih untuk menambahkan data ke file WAL kedua. Pada titik ini, file WAL pertama dapat di-checkpoint (dan kemudian dapat ditimpa), lalu setelah file WAL kedua menjadi cukup besar dan file pertama telah di-checkpoint, penulisan beralih kembali ke file WAL pertama. Proses ini terus berulang.

  • Pendekatan ini terasa sangat logis, jadi saya tidak paham kenapa mode WAL tidak diimplementasikan seperti ini sejak awal. Mungkin ini dianggap sebagai optimisasi yang terlalu dini.
  • Saya berharap mode ini segera tersedia secara umum.

• Bedrock

  • Bedrock adalah branch yang lebih menarik.
  • Mencakup fitur WAL2 + CONCURRENT.
  • Ini adalah branch yang digunakan Expensify untuk melakukan scaling hingga 4M QPS pada satu node (6 tahun lalu).

• Membagikan tautan tentang left-right primitive, teknik yang mirip dengan mode WAL2.

  • Teknik ini lebih tua daripada implementasi yang ditautkan, tetapi ditemukan kembali secara independen, dan secara khusus ditulis untuk mendukung database SQL performa tinggi lain bernama Noria.

• Dalam mode WAL2, dua file WAL digunakan, bukan satu. File-file tersebut dinamai "<database>-wal" dan "<database>-wal2".

  • Saya penasaran berapa banyak orang yang akan menghapus file wal. Karena setelah beralih ke wal2, mereka bisa mengira file wal itu sisa yang tertinggal.

• Microsoft SQL Server menggunakan arsitektur serupa, tetapi alih-alih file log terpisah, ia mengalokasikan Virtual Log Files (VLF) di dalam file log fisik (di disk). VLF dialokasikan dalam ring buffer dan jumlahnya bisa mencapai ribuan.

• Saya jadi tahu bahwa fitur ini memang belum dirilis.

• Saya selalu khawatir bahwa WAL ada untuk membantu menjaga integritas data dan memulihkan dari crash. Namun, file itu sendiri ditulis secara batch (dan di-commit ke disk secara andal), bukan setelah setiap perubahan pada database, demi mendapatkan performa. Bukankah ini justru merusak tujuannya? Secara umum, tidak khusus untuk database tertentu, saya belum menemukan jawaban untuk ini.

• Saya penasaran bagaimana dampaknya terhadap sistem SQLite terdistribusi baru seperti Litestream.

• Jadi pada dasarnya ini semacam double buffering untuk database? Masuk akal.

• Mode WAL2 dimasukkan dalam benchmark riset backend HC-tree.