Litestream v0.5.0
(fly.io)- Litestream v0.5.0 adalah pembaruan yang secara signifikan meningkatkan ketahanan aplikasi berbasis SQLite
- Memperkenalkan format file LTX baru yang mendukung pemulihan point-in-time (PITR) yang efisien serta kompresi data
- Menghapus konsep generation antar beberapa instance Litestream sehingga pengelolaan dan operasional menjadi lebih sederhana
- Dukungan JetStream dan peralihan ke driver SQLite Go modern membuat pengembangan serta lingkungan integrasi menjadi lebih nyaman
- Ke depannya akan ditambahkan fitur yang lebih kuat seperti read replica berbasis VFS
Ikhtisar dan pembaruan utama
- Litestream adalah alat backup dan pemulihan untuk aplikasi SQLite, bersifat open source dan dapat dijalankan di mana saja
- Pemulihan dari kegagalan server menjadi mudah, sehingga memberikan keamanan dalam membangun aplikasi full-stack berbasis SQLite
- Versi terbaru (v0.5.0) mendukung peningkatan kecepatan dan Point-In-Time Recovery (PITR)
Alur perkembangan LiteFS dan Litestream
- Proyek SQLite utama yang dikembangkan oleh Ben Johnson dari Fly.io adalah Litestream dan LiteFS
- LiteFS memanfaatkan file system FUSE untuk melakukan replikasi live pada tingkat transaksi internal database
- Namun, permintaan pasar lebih terfokus pada Litestream yang lebih sederhana dalam operasional, sehingga pelajaran teknis dari LiteFS kembali diterapkan ke Litestream
Pengenalan format file LTX
-
Untuk mengatasi keterbatasan dan inefisiensi dari metode backup berbasis halaman SQLite sebelumnya, diperkenalkan LTX (format berbasis transaksi)
-
LTX menyediakan pengelolaan rentang halaman berdasarkan urutan transaksi serta compaction halaman duplikat
- Contoh: beberapa file LTX diterapkan dari yang terbaru, dan untuk halaman yang duplikat hanya versi terbaru yang digunakan sehingga status akhir database dapat dipulihkan dengan cepat
- Melalui struktur hierarki file, file LTX digabungkan per 30 detik, 5 menit, dan 1 jam untuk secara drastis mengurangi jumlah file yang dibutuhkan saat pemulihan
-
Kecepatan pemulihan data hanya dibatasi oleh throughput I/O
Penghapusan konsep generation
- Litestream dapat berjalan dan crash seperti proses Unix pada umumnya, dan ketika operasinya terhenti dapat terjadi ketidaksesuaian dalam sinkronisasi data
- Sebelumnya, untuk mencegah benturan antar beberapa instance, diperkenalkan metode pengelolaan bernama generation
- Namun, dengan beralih ke LTX, pemulihan berbasis transaction ID menjadi memungkinkan sehingga pengelolaan generation yang kompleks tidak lagi diperlukan
Upgrade Litestream v0.5.0
- Karena format file telah berubah cukup besar, pemulihan langsung dari WAL segment v0.3.x tidak dimungkinkan
- Upgrade dilakukan secara sederhana dengan menjalankan versi baru → membuat file LTX baru, dan file WAL lama juga tetap dipertahankan
- Kompatibilitas file konfigurasi juga tetap dijaga
- Perubahan utama: kini hanya satu target replikasi yang diizinkan per database, keputusan ini diambil untuk mempermudah pengembangan dan menghindari benturan replikasi
- Perintah tetap sama seperti sebelumnya, tetapi cara referensinya berubah menjadi berbasis transaction ID (TXID)
Peningkatan lainnya
- Dengan kompresi per halaman dan penambahan indeks pada library format file LTX, akses selektif ke halaman di dalam file besar dan perluasan fungsi menjadi memungkinkan
- Ke depannya, fitur tambahan seperti query data pada titik waktu tertentu dapat diimplementasikan
- Dependensi CGO dihapus dan driver SQLite Go dialihkan ke modernc.org/sqlite sehingga memberikan keuntungan untuk build otomatis dan lingkungan cross-compilation
- Termasuk dukungan tipe replika JetStream, pembaruan klien S3/Google Storage/Azure Blob Storage, dan dukungan versi baru API S3
Rencana ke depan
- Pengembangan fitur Litestream VFS untuk lingkungan target read replica sedang berlangsung
- Melalui fitur ini, nantinya replika cepat dapat dibuat dengan langsung membaca hanya halaman yang dibutuhkan dari S3
- Prototipe sudah ada dan sedang bersiap untuk dipublikasikan
1 komentar
Opini Hacker News
Pengalaman developer saat mendeploy aplikasi SQLite di Fly.io terasa agak kurang memuaskan; saya mencoba selama beberapa jam untuk menjalankan aplikasi Rails produksi, tetapi menemui berbagai masalah seperti inisialisasi database, migrasi, status writable, dan lain-lain. Akar masalahnya ternyata eager loading pada gem buatan saya sendiri, tetapi ada beberapa lapisan runner di atasnya sehingga sulit didiagnosis. Saya berharap mereka lebih serius meningkatkan DX, tetapi karena pelanggan besar mungkin tidak menjalankan workload seperti ini, saya rasa bagi Fly.io ini bukan prioritas. Saya penasaran host apa yang dipakai orang-orang yang sudah pernah mendeploy aplikasi SQLite di produksi.
Tahun lalu saya menyiapkan aplikasi Rails 8 baru di Fly, dan meskipun penyimpanan data utamanya memakai PG, database solid stack sekundernya menggunakan SQLite. Ada sedikit masalah di sisi Rails terkait migrasi solid queue, tetapi itu bukan masalah dari Fly. Saya juga sedang mempertimbangkan memigrasikan PG utama ke SQLite, dan saat ini sudah memanfaatkan SQLite dengan baik di beberapa bagian.
Saya memakai SQLite untuk aplikasi konsol di lingkungan produksi. DB-nya berada di drive berbagi file.
Senang sekali Fly melanjutkan kembali pengembangan Litestream setelah sempat berhenti selama 2 tahun. Saya sangat puas karena hampir selalu memakai Litestream. Biaya penggunaan nyatanya jauh lebih murah daripada slogan iklan “beberapa sen per hari”; saat memakai replikasi Litestream ke S3 pada aplikasi produksi nyata, biaya bulanannya hanya sekitar 2–3 sen (US$0,02–0,03). Saya juga membagikan pengalaman terkait.
Menarik bahwa Litestream akan segera mendukung semua tujuan yang kompatibel dengan s3. Selama ini saya memakai solusi SFTP karena tidak ingin memakai layanan object storage cloud yang di-hardcode. Terima kasih kepada para pengembangnya. Berikut tautan PR dan tautan panduan.
Saya ingin segera mencoba Litestream. Saya penasaran apakah ada benchmark atau demo tentang berapa lama waktu pemulihan yang sebenarnya. Dulu saya pernah mengimplementasikan backup S3 sendiri, dan saat itu Litestream butuh 20 menit untuk memulihkan 1.000 baris, yang terasa cukup tidak optimal. Saya ingin tahu seberapa banyak kecepatan pemulihannya sudah membaik sekarang.
Saya penasaran apa keunggulan Litestream dibanding sqlite.org/rsync.
Pembeda Litestream adalah tidak memerlukan “server” di sisi lain; cukup object storage saja. Ini bisa membuatnya lebih murah dari sisi biaya.
Litestream mendukung Point In Time Recovery. Jadi bukan hanya punya replika pada titik waktu saat ini, tetapi juga bisa memulihkan ke snapshot pada waktu mana pun.
Ada komentar menarik terkait LiteFS dan Litestream: “respons pasar adalah jawabannya! Pengguna lebih menyukai Litestream.” Sejujurnya, Litestream memang lebih mudah dioperasikan dan dipahami, jadi masuk akal kalau fokus kembali diarahkan ke sana.
Membagikan tautan terkait Litestream Revamped dan diskusi Hacker News
Blog
Diskusi HN
Kami sedang mendeploy aplikasi internal ke armada jarak jauh eksternal, tetapi koneksi internetnya tidak stabil sehingga sulit membangun sistem pengumpulan data dengan baik. Saya penasaran bagaimana Litestream menangani backup di lingkungan tidak stabil seperti ini, dan apakah beberapa backup bisa digabungkan ke DB pusat untuk di-query.
Sedikit peringatan: saya pernah menangani migrasi aplikasi bisnis legacy ke Azure, dengan struktur di mana server MSSQL lokal berjalan bersama aplikasinya, mirip pola Litestream. Aplikasi itu dikembangkan dengan asumsi akses lokal (latensi di bawah 1 ms), sehingga di mana-mana ada query N+1 yang sangat parah. Akibatnya, hampir mustahil berpindah ke arsitektur lain. Jika Anda khawatir model hosting seperti ini akan mentok saat mencapai batas skala, saya tidak merekomendasikannya. Namun, satu mesin saja sebenarnya bisa menangani skala yang cukup besar, jadi dalam praktiknya mungkin bukan masalah besar.
Di masa sekarang, ketika satu instance bisa mendukung RAM lebih dari 20 TB dan ratusan core, menurut saya opsi ini cukup kompetitif. Jika digabungkan dengan arsitektur sel per pengguna/tenant, pendekatan ini bisa menjadi lebih efisien.
Saya juga dulu pernah mengerjakan produk yang server aplikasi dan databasenya berada di rak yang sama, jadi sama-sama berlatensi rendah. Saat produk itu sukses dan query N+1 bertambah menjadi ribuan, 1 ms dengan cepat berubah menjadi 500 ms atau lebih. Setiap dua bulan kami berulang kali mencari bottleneck lambat di NewRelic lalu memperbaikinya. Karena itu aplikasi Rails, masalah N+1 mudah muncul tetapi relatif mudah juga diperbaiki.
Praktik query yang buruk pada akhirnya pasti akan menimbulkan masalah. Sulit menyebutnya sebagai kelemahan pendekatan ini sendiri.
Sebenarnya saya rasa ini bukan trade-off besar, karena pada akhirnya layanan seperti ini hanya memperlihatkan seberapa bermasalah kode Anda. Itu salah kode, bukan salah layanannya.
Ada yang bertanya apa itu N+1.
Saya benar-benar menyukai Litestream; mudah digunakan dan belum pernah crash sekalipun. Saya merekomendasikannya dipakai sebagai layanan unit systemd. Saya memakainya bukan hanya sebagai alat backup, tetapi juga untuk database mirroring. Saya juga menantikan fitur read-replica yang akan datang.