7 poin oleh xguru 2024-08-09 | 1 komentar | Bagikan ke WhatsApp
  • rqlite adalah database relasional terdistribusi open source yang ringan dan ditulis dengan Go
  • Dibangun di atas protokol konsensus Raft dan menggunakan SQLite sebagai mesin penyimpanan
  • Pengembangan 9.0 telah dimulai, dengan target mengurangi penggunaan disk sekitar 50%
  • Target ini akan dicapai melalui perombakan desain tingkat tinggi yang menghilangkan penyebab utama konsumsi disk pada rqlite

Apa yang saat ini paling banyak memakan penggunaan disk?

  • Log Raft:
    • Log perubahan pada sistem
    • Log ini adalah inti dari sistem konsensus Raft
  • Database SQLite aktif:
    • Database live yang digunakan rqlite untuk menyediakan operasi baca dan tulis
    • Setelah statement SQLite berhasil di-commit ke log Raft, statement tersebut diterapkan ke database SQLite aktif
  • Snapshot database SQLite aktif:
    • Untuk mencegah log Raft tumbuh tanpa batas, subsistem Raft di dalam rqlite secara berkala membuat dan menyimpan salinan point-in-time dari database SQLite aktif
    • Salinan ini disebut snapshot
    • Setelah snapshot dibuat, rqlite dapat memangkas log Raft
    • Salinan snapshot ini digunakan rqlite untuk memulihkan node saat node dimulai ulang, atau dikirim ke node lain saat node tersebut perlu "mengejar" status cluster rqlite yang sudah ada
    • Pembuatan snapshot dan pemangkasan log adalah konsep inti dalam sistem berbasis Raft

Desain tingkat tinggi untuk rqlite 9.0

  • Strategi utama untuk mengurangi penggunaan disk adalah menghilangkan kebutuhan menyimpan salinan snapshot dari database SQLite aktif di sistem Raft
  • Log Raft dipangkas secara berkala karena pembuatan snapshot dan berhenti bertambah setelah titik tertentu, tetapi database SQLite aktif terus bertambah seiring makin banyak data ditulis
  • Dan karena salinan snapshot database SQLite hampir sama besar dengan database SQLite aktif, ukurannya juga ikut bertambah
  • Jadi, jika salinan snapshot dapat dihilangkan, rqlite akan menggunakan disk 50% lebih sedikit
  • Namun, node rqlite memang membutuhkan salinan snapshot pada titik tertentu. Ini tidak bisa dihindari.
  • Jadi bagaimana cara melewati pembuatan salinan sambil tetap memenuhi kebutuhan pembuatan dan pemulihan snapshot?
  • Untuk memahami bagaimana hal ini dapat dihindari tanpa menyimpan salinan tambahan selama proses snapshot, penting untuk mengetahui bahwa rqlite menjalankan database SQLite dasarnya dalam mode Write-Ahead Log(WAL)
  • Dalam desain 9.0 yang diusulkan, file database SQLite aktif (tidak termasuk file WAL terkait) dan salinan snapshot dari sistem Raft secara logis adalah hal yang sama
  • Fakta ini dapat dimanfaatkan untuk menghilangkan kebutuhan menyimpan salinan snapshot terpisah di sistem Raft

Pendekatan baru untuk pembuatan snapshot

  • Pembuatan snapshot dan checkpoint WAL:
    • Pada saat pembuatan snapshot, rqlite melakukan checkpoint pada Write-Ahead Log(WAL) database SQLite aktif
    • Semua penulisan setelah itu diarahkan ke file WAL baru, sehingga file SQLite utama tetap tidak berubah sejak titik saat snapshot dibuat
    • Hasilnya, hingga snapshot berikutnya terjadi, file SQLite utama merepresentasikan status point-in-time yang dibutuhkan oleh penyimpanan snapshot Raft
    • Pendekatan ini memungkinkan operasi baca dan tulis normal menggunakan gabungan file SQLite dan file WAL, sementara file SQLite utama yang tidak berubah berfungsi sebagai set data untuk penyimpanan snapshot Raft
    • Tidak diperlukan lagi salinan tambahan!
  • Menulis referensi ke penyimpanan snapshot:
    • Alih-alih menyalin seluruh file SQLite, rqlite menulis referensi seperti checksum ke penyimpanan snapshot
    • Referensi ini dapat digunakan untuk memverifikasi bahwa file SQLite utama cocok dengan apa yang dirujuk oleh penyimpanan snapshot setiap kali data snapshot dibutuhkan
      • (Verifikasi ini melindungi dari bug, kesalahan operasional, atau kerusakan disk, tetapi tidak mutlak diperlukan)
  • Memulihkan dari snapshot:
    • Seperti disebutkan sebelumnya, semua penulisan setelah proses snapshot diarahkan ke file WAL, sehingga file SQLite utama siap digunakan dalam proses pemulihan dari snapshot, misalnya saat node dimulai ulang atau saat snapshot dikirim ke node lain
    • Artinya, file SQLite utama (mengabaikan file WAL terkait) tetap identik secara logis dengan apa yang sebenarnya akan ditulis rqlite ke penyimpanan snapshot Raft jika rqlite benar-benar membuat salinan duplikat
  • Desain baru ini disebut "reference snapshot"

Peningkatan bonus

  • Reference snapshot juga akan membawa beberapa peningkatan penting lainnya
  • Pembuatan snapshot lebih cepat: karena hanya menulis data minimum ke penyimpanan snapshot Raft, proses snapshot akan menjadi jauh lebih cepat
    • Ini akan terdiri dari waktu checkpoint SQLite WAL (biasanya sangat singkat) dan waktu perhitungan checksum
    • Tidak perlu lagi menyalin data SQLite dalam jumlah besar ke penyimpanan snapshot setiap kali membuat snapshot
    • Keuntungan snapshot yang lebih cepat menjadi jelas jika diketahui bahwa penulisan ke rqlite diblokir selama proses snapshot
  • Restart lebih cepat: bahkan node dengan data SQLite beberapa gigabyte akan dapat dimulai ulang jauh lebih cepat
    • Saat ini, ketika restart, rqlite harus memulihkan file database SQLite aktif dari salinan di penyimpanan snapshot Raft
    • Namun dalam desain baru ini, saat startup file database SQLite aktif sudah berada di lokasi yang benar
    • Paling jauh, rqlite hanya perlu membandingkan checksum dari penyimpanan snapshot dengan checksum database SQLite aktif
    • Sistem multi-GB seharusnya dapat restart dalam hitungan detik

Langkah berikutnya

  • Peralihan ke rqlite 9.0 akan menjadi langkah penting dalam mengoptimalkan efisiensi rqlite
  • Dengan mengimplementasikan reference snapshot, diharapkan penggunaan disk dapat dikurangi secara signifikan, kecepatan pembuatan snapshot meningkat, dan waktu restart node membaik
  • Ada banyak detail yang harus ditangani dengan benar, seperti pengelolaan SQLite WAL, upgrade mulus dari rilis sebelumnya, dan pemilihan checksum
  • Karena itu, nantikan pembaruan berikutnya seiring pengembangan menuju rilis besar ini