Perhitungkan compaction

Pertanyaan

Berapa banyak I/O dan ruang disk yang sebenarnya dikeluarkan untuk satu byte data pengguna, dan siapa yang membayarnya?

Setelah baca ini, kamu bisa menghitung write, read, dan space amplification untuk strategi compaction tertentu, serta menjelaskan kenapa tombstone dan pekerjaan latar bisa merusak latensi.

Prasyarat dan contoh

Kamu sudah baca M09.04 Telusuri proses baca/tulis LSM: memtable, SSTable, dan Bloom filter dianggap paham.

Mesin LSM menerima 10 MB per detik data pengguna. Disk SSD-nya mampu menulis 500 MB per detik. Kelihatannya longgar. Dua jam kemudian latensi baca melonjak dan tulis ditahan. Penyebabnya bukan trafik naik, tapi compaction menulis jauh lebih banyak dari 10 MB per detik.

Mekanisme

Mengapa compaction ada. SSTable nggak pernah diubah, jadi update dan delete menumpuk versi lama dan file yang tumpang tindih. Compaction membaca beberapa file, menggabungkan secara terurut, membuang versi lama dan tombstone yang boleh dibuang, lalu menulis file baru.

Tiga amplification.

• Write amplification (WA): byte yang ditulis ke disk / byte yang ditulis pengguna.
• Read amplification (RA): jumlah I/O (file atau blok) per baca.
• Space amplification (SA): byte di disk / byte data hidup.

Dua strategi umum.

Leveled. Level 1 berukuran 10x level 0 dan seterusnya (faktor 10), file di tiap level di bawah L0 tidak tumpang tindih. Satu key hanya ada di paling banyak satu file per level, sehingga RA kecil (satu file per level). Harganya: data didorong turun level demi level, dan tiap dorongan menulis ulang sekitar 10 kali ukuran data yang didorong (karena file di level bawah yang tumpang tindih ikut ditulis). Dengan 4 level aktif, WA sering berkisar 10-30. SA kecil, sekitar 1,1x.

Size-tiered. Gabungkan beberapa file berukuran mirip jadi satu yang lebih besar. Tiap byte ditulis ulang sekali per tingkat, jadi WA jauh lebih rendah, sekitar jumlah tingkat (misal 4-8). Tapi file bisa tumpang tindih, sehingga RA lebih tinggi, dan saat compaction besar berjalan, file lama dan baru ada bersamaan, jadi SA bisa mendekati 2x.

Angka kerja. Pengguna menulis 10 MB per detik. Leveled dengan WA 20: disk menerima 200 MB per detik tulis. Compaction juga membaca, sekitar jumlah yang sama, jadi anggaran I/O bisa mencapai 400 MB per detik pada disk 500 MB per detik. Sisa kapasitas untuk baca pengguna tinggal sedikit. Selain itu, SSD punya write amplification sendiri di level flash, jadi umur disk ikut turun.

Tombstone. Delete ditulis sebagai tombstone supaya menutupi versi lama di file yang lebih dalam. Tombstone hanya boleh dibuang saat compaction mencapai titik di mana tidak ada versi lama di bawahnya (level terbawah, atau semua file yang mungkin memuat key itu ikut dikompaksi). Kalau dibuang lebih cepat, data yang sudah dihapus "hidup lagi". Pada sistem replikasi, tombstone juga harus bertahan cukup lama agar replika yang tertinggal menerimanya, misalnya Cassandra memakai gc_grace_seconds default 10 hari.

Pekerjaan latar harus dibatasi. Compaction bersaing dengan baca dan flush untuk I/O dan CPU. Praktik umum: batasi laju tulis compaction (rate limiter), jalankan beberapa thread dengan batas, dan tahan tulis pengguna (write stall) kalau tumpukan file L0 melewati ambang, misalnya 20 file. Stall itu mekanisme perlindungan, bukan bug: tanpanya RA dan SA tak terbatas.

Saat rancangan ini gagal

• Compaction tertinggal. Tulis masuk lebih cepat dari kemampuan compaction. File L0 menumpuk, RA naik, lalu tulis ditahan. Gejalanya: p99 baca dan tulis naik bersamaan.
• Tombstone menumpuk. Antrean yang sering menghapus (misalnya tiap pesan dihapus setelah dibaca) membuat scan melewati jutaan tombstone untuk menemukan satu key hidup. Latensi baca naik walau data hidup kecil.
• Penghapusan terlalu dini. Tombstone dibuang sebelum replika tertinggal menerimanya, sehingga data terhapus muncul lagi.
• Space spike. Size-tiered dengan data 800 GB di disk 1 TB bisa kehabisan ruang saat compaction besar butuh 800 GB ruang sementara.
• Contoh tandingan: tim mengukur WA 3 di benchmark dengan tulis acak seragam, lalu produksi memakai update pada subset kecil key. Hasil nyata beda karena WA bergantung pada distribusi key dan strategi, bukan angka tetap mesin.

Latihan

Leveled compaction dengan faktor 10. Pengguna menulis 8 MB per detik. Data mengalir melalui L0 (flush), lalu L1, L2, L3. Anggap tiap dorongan antar level menulis ulang 10x data yang didorong (pendekatan kasar), jadi WA total sekitar 1 (flush) + 10 + 10 + 10. Disk menulis maksimal 400 MB per detik, dan compaction juga membaca jumlah sama.

1. Berapa WA dan beban tulis disk?
2. Apakah kapasitas I/O cukup (tulis + baca compaction)?
3. Data hidup 600 GB dengan SA 1,1x. Berapa disk dipakai, dan bagaimana kalau size-tiered dengan SA 2x?

Lihat pembahasan+

1. WA sekitar 1 + 10 + 10 + 10 = 31. Beban tulis disk = 8 x 31 = 248 MB per detik.
2. Compaction juga membaca sekitar jumlah yang sama, jadi total I/O sekitar 248 (tulis) + 240 (baca, tanpa flush) = sekitar 490 MB per detik. Itu melewati 400 MB per detik, jadi compaction tertinggal dan tulis akan ditahan. Opsi: kurangi WA (size-tiered atau faktor level lebih kecil), tambah disk, atau turunkan laju tulis.
3. Leveled: 600 x 1,1 = 660 GB. Size-tiered: 600 x 2 = 1.200 GB, dua kali lipat disk, dan saat compaction besar lonjakan sementara bisa mendekati batas itu. Karena itu kapasitas harus direncanakan di puncak, bukan rata-rata.

Perhatikan angka WA di sini kasar. Perkiraan nyata bergantung pada tumpang tindih key dan distribusi tulis, jadi ukur di beban sesungguhnya.

Terkait

• Sebelumnya: M09.04 Telusuri proses baca/tulis LSM.
• Lanjut ke M09.06 Bedakan object storage dari basis data.
• Retensi dan kapasitas dihitung dengan cara yang sama seperti di M01.03 Perkirakan kebutuhan sumber daya. Lab L09 dan proyek B05 belum tersedia.

Catatan

• Asumsi: SSD tunggal, WA leveled dihitung kasar (faktor 10 per level), tanpa kompresi.
• Yang nggak dibahas: universal/FIFO compaction, subcompaction, dan write amplification pada level flash SSD.
• Nilai default seperti gc_grace_seconds bisa berubah antarversi, periksa dokumentasi versimu.
• Terakhir ditinjau: 26 Oktober 2026.