Pendekatan eksperimental seorang developer dalam membangun database berkinerja tinggi menggunakan io_uring Linux dan sistem dual write-ahead log (WAL) telah memicu perdebatan teknis yang sengit di komunitas pemrograman. Kontroversi ini berpusat pada apakah desain yang diusulkan benar-benar mempertahankan jaminan durabilitas yang diharapkan dari database.
Developer tersebut menciptakan database key-value eksperimental bernama Poro , mengimplementasikan apa yang mereka sebut desain dual WAL untuk mencapai performa yang lebih baik dengan operasi I/O asinkron. Alih-alih pendekatan tradisional menulis perubahan ke disk dan menunggu konfirmasi sebelum merespons klien, sistem ini menggunakan dua log terpisah: intent WAL yang mencatat operasi yang direncanakan dan completion WAL yang mengonfirmasi operasi yang berhasil.
Komponen Teknis Utama
- Intent WAL: Mencatat operasi yang direncanakan sebelum eksekusi
- Completion WAL: Mencatat penyelesaian operasi yang berhasil
- io_uring: Antarmuka I/O asinkron Linux dengan antrian submission/completion
- Circular Buffers: Entri batch untuk meningkatkan performa (ambang batas kapasitas 75%)
- Verifikasi Checksum: Pemeriksaan integritas data selama pemulihan
- Ring Buffer Terpisah: Mencegah head-of-line blocking antara jenis WAL
Komunitas Mempertanyakan Prinsip Inti Database
Komunitas teknis telah mengangkat kekhawatiran serius tentang desain fundamental ini. Beberapa developer telah menunjukkan apa yang tampaknya merupakan cacat kritis dalam pendekatan tersebut. Sistem mengembalikan sukses kepada klien setelah menulis catatan intent dan completion secara asinkron, tetapi sebelum memastikan catatan-catatan ini benar-benar disimpan ke disk. Ini berarti klien bisa menerima konfirmasi bahwa data mereka telah disimpan, hanya untuk kehilangan data tersebut jika sistem crash segera setelahnya.
Apakah ini berarti bahwa klien bisa menerima sukses untuk sebuah permintaan, yang jika sistem crash segera setelahnya, ketika diputar ulang, belum tentu memiliki permintaan tersebut tercatat? Bagaimana hal itu tidak melanggar ACID ?
Properti ACID (Atomicity, Consistency, Isolation, Durability) adalah persyaratan fundamental untuk sistem database yang dapat diandalkan. Aspek durabilitas secara khusus mengharuskan bahwa setelah transaksi dikonfirmasi sebagai berhasil, data harus bertahan dari kegagalan sistem. Kritikus berargumen bahwa pendekatan dual WAL secara fundamental melanggar jaminan ini.
Klaim Performa Dipertanyakan
Meskipun developer melaporkan peningkatan performa yang mengesankan - mengklaim peningkatan 10x dalam throughput transaksi - anggota komunitas mempertanyakan apakah keuntungan ini datang dengan mengorbankan keandalan data. Beberapa developer berpengalaman telah menyatakan kebingungan tentang bagaimana dua operasi tulis asinkron bisa lebih cepat atau lebih dapat diandalkan daripada satu operasi tulis sinkron yang benar-benar menjamin persistensi data.
Perdebatan ini juga telah menyoroti pendekatan alternatif yang digunakan dalam sistem produksi. Beberapa developer telah berbagi teknik tahan crash mereka sendiri, seperti menggunakan file hash dan length terpisah dengan operasi atomic rename, atau mengimplementasikan struktur B-tree append-only yang menyatukan WAL dan penyimpanan data.
Pendekatan WAL Tradisional vs Dual WAL
| Aspek | WAL Tradisional | Dual WAL (Usulan) |
|---|---|---|
| Operasi Tulis | Penulisan sinkron tunggal | Dua penulisan asinkron (intent + completion) |
| Respons Klien | Setelah konfirmasi flush disk | Setelah operasi memori selesai |
| Jaminan Durabilitas | Kuat (data bertahan dari crash) | Dipertanyakan (data mungkin hilang) |
| Klaim Performa | Baseline | Peningkatan 10x dilaporkan |
| Proses Recovery | Terapkan semua entri yang committed | Terapkan hanya entri dengan record intent dan completion |
Detail Implementasi yang Hilang Memicu Kebingungan
Sebagian besar kritik komunitas berasal dari penjelasan yang tidak jelas dalam proposal asli. Beberapa developer menduga bahwa implementasi sebenarnya mungkin mencakup langkah yang hilang di mana sistem menunggu kedua catatan WAL di-flush ke disk sebelum mengembalikan sukses kepada klien. Namun, ini akan menghilangkan manfaat performa yang diklaim, karena menunggu dua operasi disk kemungkinan akan lebih lambat daripada menunggu satu.
Diskusi ini juga telah mengangkat pertanyaan tentang skenario akses bersamaan. Jika beberapa thread mengakses data yang sedang ditulis secara asinkron, sistem bisa menghadapi tantangan konsistensi tambahan di luar kekhawatiran durabilitas dasar.
Implikasi yang Lebih Luas untuk Desain Database
Meskipun ada kritik, eksperimen ini telah memicu diskusi berharga tentang arsitektur database modern dan potensi io_uring untuk sistem penyimpanan berkinerja tinggi. Interface io_uring Linux memang menawarkan keuntungan nyata untuk aplikasi yang dapat memanfaatkan I/O asinkron dengan benar, tetapi komunitas database tampaknya skeptis bahwa manfaat ini dapat direalisasikan tanpa mengorbankan jaminan keandalan fundamental.
Perdebatan berlanjut saat developer mencari klarifikasi tentang detail implementasi sebenarnya dan apakah sistem yang diusulkan benar-benar dapat mempertahankan kepatuhan ACID sambil memberikan peningkatan performa yang dijanjikan.
*Write-ahead log (WAL): Teknik di mana perubahan pertama kali ditulis ke file log sebelum diterapkan ke database utama, memastikan data dapat dipulihkan setelah crash.*io_uring: Interface kernel Linux yang menyediakan operasi I/O asinkron yang efisien, memungkinkan aplikasi untuk mengirimkan beberapa operasi tanpa blocking.
*ACID: Seperangkat properti (Atomicity, Consistency, Isolation, Durability) yang menjamin transaksi database yang dapat diandalkan.
Referensi: Async I/O on Linux and durability