SQLite WAL vs Journal Delete

Jawaban singkat: pada SQLite 3.45.1, menulis 20.000 baris dalam 20 transaksi butuh 0,089 detik dengan journal mode delete dan 0,054 detik dengan mode wal. Mode WAL jadi 1,65 kali lebih cepat pada pola tulis berkelompok seperti itu. Bedanya bukan dari mesin yang lebih kuat, tapi dari cara commit ditangani: WAL menulis perubahan ke berkas terpisah dan tidak menyalin halaman lama ke rollback journal setiap transaksi.

TL;DR WAL 0,054 detik vs delete 0,089 detik untuk 20.000 baris di 20 transaksi.
Berkas -wal muncul dan pada uji ini berukuran 2.084,2 KB, sementara berkas database utama tinggal 4,0 KB.
Total ukuran di disk jadi 13,7 persen lebih besar: 2.088,2 KB berbanding 1.836,0 KB.
Default SQLite 3.45.1 masih delete dengan synchronous level 2, jadi WAL harus diminta eksplisit.
WAL tidak boleh dipakai di filesystem jaringan yang berbagi berkas antar-host.

WAL sering disebut sebagai "mode cepat" SQLite tanpa angka pendamping. Pengukuran di bawah ini menaruh angka pada klaim itu, sekaligus menunjukkan harga yang dibayar: berkas tambahan, ukuran disk yang naik, dan syarat filesystem yang lebih ketat.

Metodologi pengujian

Uji memakai pustaka sqlite3 bawaan Python pada host Ubuntu 24.04.5 dengan SQLite 3.45.1, page size 4.096 byte, dan synchronous level 2 yang merupakan default. Setiap mode membuat berkas database baru di direktori sementara, menyalakan journal mode yang diuji, lalu memasukkan 20.000 baris ke tabel tiga kolom dengan satu kolom teks sepanjang 80 karakter. Baris dimasukkan dalam 20 transaksi, masing-masing 1.000 baris, supaya pola commit-nya menyerupai aplikasi yang mengelompokkan penulisan, bukan satu commit per baris.

Waktu dihitung dengan penghitung beresolusi tinggi yang membungkus seluruh proses insert dan commit, tidak termasuk pembuatan tabel. Sesudah selesai, ukuran berkas database dicatat, begitu juga ukuran berkas -wal bila ada. Kedua mode dijalankan di direktori yang sama, pada mesin yang sama, tanpa beban lain yang berarti. Ini pengukuran sekali jalan per mode, jadi selisih kecil di bawah lima persen sebaiknya tidak ditafsirkan terlalu jauh.

Berapa selisih waktu dan ukuran antara delete dan WAL?

Mode journal	Waktu insert 20.000 baris	Berkas database	Berkas -wal	Total di disk
delete	0,089 detik	1.836,0 KB	tidak ada	1.836,0 KB
wal	0,054 detik	4,0 KB	2.084,2 KB	2.088,2 KB

Tabel itu menunjukkan dua hal sekaligus. Pertama, WAL memang lebih cepat pada pola tulis berkelompok, sekitar 1,65 kali. Kedua, berkas database utama pada mode WAL terlihat hampir kosong karena hampir semua isinya masih berada di berkas -wal. Siapa pun yang mengukur ukuran database hanya dari berkas utamanya akan salah kira, dan itulah sebabnya checkpoint perlu dipahami sebelum memakai WAL di produksi.

Kenapa WAL lebih cepat pada penulisan berkelompok?

Pada mode rollback journal, setiap transaksi yang akan commit harus menyalin halaman asli ke journal lebih dulu, lalu mengosongkan journal setelah commit berhasil. Pekerjaan itu terjadi berulang untuk setiap transaksi, dan biayanya tumbuh seiring jumlah commit. Mode WAL membalik pendekatannya: perubahan ditulis secara berurutan ke akhir berkas -wal, dan pembaca tetap melihat snapshot lama sampai ada checkpoint.

Karena penulisan ke WAL bersifat menambahkan di ujung berkas, kepala disk tidak dipaksa melompat ke banyak tempat, dan commit tidak perlu menyalin halaman lama. Efeknya terasa paling jelas pada banyak transaksi kecil dan sedang. Pada satu transaksi raksasa berisi ratusan ribu baris, selisihnya menyempit karena biaya dominannya bukan lagi jumlah commit, melainkan volume data yang ditulis.

WAL juga mengubah pola konkurensi. Pembaca tidak lagi memblokir penulis dan sebaliknya, sehingga satu proses bisa membaca sambil proses lain menulis. Ini keuntungan yang tidak muncul di tabel waktu di atas karena uji di sini hanya mengukur satu penulis tanpa pembaca bersamaan. Bila aplikasi Anda punya pembaca dan penulis yang saling tumpang tindih, manfaat nyatanya bisa lebih besar daripada angka 1,65 kali.

Dampak WAL pada ukuran database

Ya, setidaknya selama berkas -wal belum di-checkpoint. Pada uji ini total ukuran naik dari 1.836,0 KB menjadi 2.088,2 KB, atau sekitar 13,7 persen lebih besar. Berkas WAL di-checkpoint otomatis ketika ukurannya melewati ambang default 1.000 halaman, yang pada page size 4.096 byte berarti sekitar 4 MB, jadi pada basis data yang lebih besar ukuran berkas -wal akan mentok di kisaran itu dan tidak terus membengkak tanpa batas.

Yang perlu diwaspadai justru kebalikannya: pada aplikasi dengan pembaca berumur panjang, misalnya proses laporan yang membuka transaksi baca selama berjam-jam, checkpoint tidak bisa memindahkan halaman yang masih dibutuhkan pembaca itu. Berkas -wal lalu terus tumbuh dan ruang disk bisa habis tanpa gejala yang jelas. Solusinya bukan mematikan WAL, tapi memastikan transaksi baca ditutup secepat mungkin.

Kapan WAL sebaiknya tidak dipakai?

Jangan pakai WAL bila berkas database berada di filesystem jaringan yang dipakai beberapa host sekaligus, karena mode ini mengandalkan shared memory dan penguncian antar-proses di satu mesin. Jangan pakai juga pada media read-only atau bila aplikasi membuka database dari beberapa mesin berbeda lewat mount yang sama. Untuk kasus seperti itu, mode rollback journal tetap lebih aman walaupun lebih lambat.

Satu hal lagi yang sering terlewat: properti WAL tersimpan permanen di berkas database. Sekali diaktifkan, database akan terus memakai WAL pada pembukaan berikutnya, bahkan bila kode aplikasi tidak lagi mengirim perintah PRAGMA. Untuk kembali ke mode lama, jalankan perintah PRAGMA yang sama dengan nilai delete pada database yang sedang tidak dipakai proses lain.

Cara mengaktifkan dan memverifikasi WAL

Aktifkan dengan satu perintah setelah koneksi dibuka, lalu baca kembali nilainya untuk memastikan perubahan benar-benar diterima. Perintah untuk mengubah mode mengembalikan nilai baru sebagai hasil, jadi tidak perlu menebak apakah berhasil. Bila hasilnya tetap delete, biasanya ada transaksi lain yang masih terbuka pada database yang sama.

Verifikasi berikutnya adalah memeriksa berkas di disk: setelah beberapa penulisan, akan muncul berkas dengan akhiran -wal dan -shm di sebelah berkas database. Keduanya normal dan bukan tanda kerusakan. Saat aplikasi ditutup dengan bersih, checkpoint terakhir akan memindahkan isi WAL ke berkas utama dan berkas -wal menghilang. Bila berkas -wal tetap ada setelah semua proses berhenti, itu tanda penutupan tidak bersih dan perlu diperiksa sebelum disalin sebagai backup.

Untuk backup, jangan pernah menyalin hanya berkas database utama ketika WAL aktif, karena sebagian data masih di berkas -wal. Pakai mekanisme backup bawaan SQLite atau hentikan penulis lalu jalankan checkpoint lebih dulu. Ini kesalahan yang paling sering menghasilkan "database kosong" pada salinan, dan penyebabnya bukan SQLite, melainkan cara menyalin berkasnya.

Perilaku WAL saat proses mati mendadak

WAL dirancang untuk justru menguntungkan pada skenario ini. Perubahan yang sudah di-commit berada di berkas -wal dan dianggap sah, sehingga saat database dibuka kembali, SQLite memutar ulang isi WAL dan menghasilkan keadaan yang konsisten. Proses yang mati sebelum commit tidak meninggalkan perubahan separuh jadi, karena commit baru dianggap selesai setelah catatan commit tertulis di WAL.

Konsekuensinya untuk operasi: mematikan proses dengan sinyal keras tidak merusak database, tapi berkas -wal akan tertinggal dan pemulihan terjadi pada pembukaan berikutnya. Pada database besar dengan WAL yang panjang, pembukaan pertama setelah mati mendadak bisa terasa lebih lambat karena proses pemulihan. Ini normal, bukan tanda kerusakan, dan tidak perlu tindakan manual.

Yang benar-benar berbahaya adalah mematikan mesin dengan cara memutus daya pada perangkat penyimpanan yang mengabaikan perintah flush. SQLite mengandalkan jaminan bahwa data yang sudah di-flush benar-benar sampai ke media. Pada disk virtual atau kartu memori yang tidak mematuhi jaminan itu, WAL maupun rollback journal sama-sama tidak bisa menjamin apa pun. Karena itu, untuk database yang penting, pilih media penyimpanan yang jujur soal flush sebelum menyalahkan mode journal.

Untuk keperluan backup, urutan yang aman adalah menghentikan penulis, menjalankan checkpoint, lalu menyalin berkas database beserta berkas -wal dan -shm bila masih ada. Cara yang lebih rapi adalah memakai mekanisme backup bawaan SQLite yang menangani konsistensi tanpa perlu menghentikan aplikasi. Menyalin tiga berkas secara manual tanpa urutan yang benar adalah cara paling umum menghasilkan salinan yang tampak baik tetapi kehilangan transaksi terakhir.

Satu kebiasaan yang layak dibangun: setiap kali mengubah mode journal atau menambah penulis baru ke database, jalankan ulang uji tulis singkat dan catat hasilnya. Angka 0,089 dan 0,054 detik di atas hanya berlaku untuk mesin dan pola tulis yang diuji. Bila penulisnya berubah dari satu proses menjadi lima, biaya penguncian ikut berubah, dan keputusan yang dulu benar bisa jadi tidak lagi relevan.

FAQ

Apakah WAL mempercepat pembacaan juga?

Tidak secara langsung. Pembacaan pada WAL bisa sedikit lebih cepat karena tidak ada penguncian bersama dengan penulis, tapi keuntungan utamanya adalah konkurensi, bukan latensi baca. Pada uji ini pembacaan tidak diukur, jadi klaim soal percepatan baca tidak bisa dibuat dari data di atas.

Apakah WAL aman untuk aplikasi produksi?

Aman dan merupakan mode yang direkomendasikan dokumentasi resmi SQLite untuk sebagian besar aplikasi. Syaratnya satu: berkas database harus berada di filesystem lokal yang mendukung penguncian bersama, bukan di mount jaringan. Selama syarat itu terpenuhi, WAL adalah pilihan default yang wajar.

Berapa besar berkas -wal yang wajar?

Pada page size 4.096 byte dan ambang checkpoint default 1.000 halaman, berkas WAL akan di-checkpoint ketika mendekati 4 MB. Pada uji ini berkas WAL berhenti di 2.084,2 KB karena penulisan selesai sebelum ambang tercapai. Bila Anda melihat berkas berukuran ratusan MB, hampir selalu penyebabnya transaksi baca yang terlalu lama terbuka.

Apakah mode delete masih berguna?

Masih, terutama untuk database yang disimpan di media read-only, dibagikan lewat filesystem jaringan, atau dibuka bergantian oleh beberapa mesin. Untuk aplikasi satu mesin dengan banyak penulisan, data uji di atas menunjukkan WAL memberi 1,65 kali kecepatan dengan tambahan 13,7 persen ukuran disk.

Rujukan resmi untuk perilaku yang dijelaskan di atas: dokumentasi Write-Ahead Logging di sqlite.org, daftar PRAGMA termasuk journal_mode, dan panduan cara database SQLite bisa rusak. Ketiganya menjelaskan syarat filesystem dan pola backup yang tidak bisa ditebak dari angka benchmark saja.