Berhenti Menyinkronkan Semua Data

• Graft adalah mesin penyimpanan transaksional open source yang berupaya menggabungkan kesederhanaan replikasi fisik dengan efisiensi replikasi logis, alih-alih mengirim seluruh change log ke semua klien
• Ia menangani Volume yang terdiri dari Page berukuran tetap pada tingkat Snapshot, dan server mengirimkan graft, yaitu bitset terkompresi berisi indeks halaman yang berubah, bukan data sebenarnya
• Klien melihat graft lalu mengambil hanya halaman yang diperlukan, serta dapat memilih prefetching berbasis Leap, prefetching khusus domain, atau pengambilan proaktif yang mengambil seluruh perubahan
• Dengan memanfaatkan object storage dan edge server, Graft menargetkan replikasi parsial bahkan di lingkungan terbatas seperti browser, aplikasi mobile, serverless function, dan lingkungan embedded
• Model konsistensinya adalah Serializable Snapshot Isolation; commit berbasis Snapshot lama ditolak, lalu klien menanganinya dengan salah satu dari reset/replay, merge, atau Volume fork

---

Masalah replikasi yang ingin dipecahkan Graft

• Replikasi parsial tampak mudah jika hanya perlu menyinkronkan data yang dibutuhkan, tetapi dalam desain nyata tiap metode replikasi memiliki konsekuensi yang jelas
  • Replikasi logis melacak setiap perubahan secara presisi, tetapi membuat konsistensi kuat menjadi rumit
  • Replikasi fisik menghindari kerumitan itu, tetapi harus menyinkronkan semua perubahan, termasuk perubahan yang nantinya akan dibuang
• Graft adalah mesin penyimpanan transaksional open source yang dibuat dengan tujuan sinkronisasi tertunda, replikasi parsial, konsistensi kuat, skalabilitas horizontal, dan durabilitas object storage
• Titik awalnya adalah pengalaman dari SQLSync
  • SQLSync adalah stack database yang dioptimalkan untuk frontend dan dibangun di atas SQLite, menggunakan ide dari Git dan sistem terdistribusi pada mesin sinkronisasinya
  • SQLSync memiliki struktur yang mereplikasi seluruh change log ke semua klien; ini baik-baik saja di server, tetapi tidak cocok untuk lingkungan edge dan browser
• Tujuan Graft adalah memungkinkan klien menyinkronkan dengan kecepatan yang mereka inginkan, mengambil hanya yang diperlukan, dan mereplikasi data arbitrer dengan konsistensi kuat bahkan di edge dan perangkat offline

Desain di antara replikasi penuh dan diff yang sadar skema

• Solusi yang ada secara umum terbagi menjadi dua jalur
  • Replikasi penuh: menyinkronkan seluruh dataset ke setiap klien, sehingga tidak praktis untuk lingkungan terbatas seperti serverless function atau aplikasi web
  • Diff yang sadar skema: melacak perubahan logis pada tingkat baris atau field seperti CDC atau CRDT, tetapi harus terintegrasi mendalam dengan aplikasi dan sulit digeneralisasi untuk data arbitrer
• Graft tidak bergantung pada skema, seperti replikasi penuh
  • Ia tidak mengetahui atau memedulikan jenis data yang disimpan, dan mereplikasi halaman yang berisi byte
• Pada saat yang sama, seperti replikasi logis, Graft menyampaikan deskripsi terkompresi kepada klien tentang apa yang berubah sejak sinkronisasi terakhir
• Abstraksi intinya adalah Volume
  • Volume adalah koleksi Page berukuran tetap yang sparse dan terurut
  • Klien membaca dan menulis Volume melalui API transaksi pada Snapshot tertentu
  • Secara internal, Graft hanya menyimpan dan mereplikasi yang diperlukan, serta menggunakan object storage sebagai backend yang durable dan scalable

Sinkronisasi tertunda: klien mengejar pada waktu yang mereka pilih

• Graft dirancang dengan asumsi bahwa klien edge sesekali aktif, jaringan tidak stabil, dan waktu eksekusi singkat
• Alih-alih bergantung pada replikasi kontinu, klien memilih sendiri kapan akan menyinkronkan
• Sinkronisasi dimulai dari pertanyaan “apa yang berubah sejak Snapshot terakhir?”
• Server tidak mengirimkan data sebenarnya, melainkan merespons dengan graft, bitset terkompresi berisi indeks halaman yang berubah
  • graft berfungsi sebagai panduan untuk menempelkan perubahan baru pada Snapshot yang ada
  • Klien dapat mengetahui halaman mana yang bisa digunakan kembali dan halaman mana yang perlu diambil saat dibutuhkan
• Karena graft adalah metadata perubahan, bukan data, kendali atas apa yang diambil dan kapan tetap berada pada klien

Replikasi parsial dan prefetching

• Di tab browser, aplikasi mobile, dan serverless function, sulit mengunduh seluruh dataset hanya untuk menangani sebagian query
• Setelah menerima graft, klien menentukan halaman mana yang masih valid dan halaman mana yang perlu diambil
• Karena hanya halaman yang diperlukan yang diambil secara selektif, hanya data yang benar-benar akan digunakan yang perlu direplikasi
• Graft mendukung beberapa metode prefetching untuk mengurangi latensi akses halaman
  • Prefetching tujuan umum: prefetcher bawaan berbasis algoritme Leap mengidentifikasi pola akses dan memprediksi akses halaman di masa depan
  • Prefetching khusus domain: aplikasi dapat memanfaatkan pengetahuan tentang data yang sering diakses, seperti profil pengguna, untuk mengambil halaman terkait terlebih dahulu
  • Pengambilan proaktif: jika diperlukan, semua perubahan dapat diambil sehingga secara efektif kembali menjadi replikasi penuh; ini sangat berguna untuk workload Graft di sisi server
• Karena halaman di-host langsung di object storage, halaman tersebut digunakan sebagai basis replikasi yang durable dan scalable

Penempatan edge dan klien embedded

• Replikasi edge Graft tidak hanya menargetkan data apa yang disinkronkan, tetapi juga menempatkan data di lokasi yang membutuhkannya
• Halaman disajikan dari object storage melalui armada edge server global
  • hot page yang sering diakses dapat di-cache dekat dengan klien
  • Tujuannya adalah latensi rendah dan responsivitas tinggi, terlepas dari lokasi pengguna di seluruh dunia
• Klien Graft dirancang agar ringan dan mudah di-embed
  • Dependensinya sedikit dan runtime-nya kecil
  • Dapat diintegrasikan ke lingkungan seperti browser, perangkat, aplikasi mobile, dan serverless function
• Karena edge caching menimbulkan masalah konsistensi dan penanganan konflik, Graft juga menyediakan model konsistensi kuat

Model konsistensi dan penanganan konflik

• Graft menggunakan Serializable Snapshot Isolation sebagai model konsistensinya
• Klien memperoleh tampilan data yang terisolasi dan konsisten pada Snapshot tertentu, dan operasi baca dapat berjalan bersamaan tanpa saling mengganggu
• Operasi tulis diserialisasi secara ketat sehingga semua transaksi memiliki urutan yang konsisten secara global
• Karena sifat offline-first dan replikasi tertunda, klien dapat mencoba commit berdasarkan Snapshot lama
  • Jika commit semacam ini diterima begitu saja, strict serializability akan rusak
  • Graft menolak commit tersebut dengan aman dan membiarkan klien memilih cara menanganinya
• Pilihan umum klien ada tiga
  • Reset and replay: mengambil Snapshot terbaru, menerapkan ulang transaksi lokal, lalu mencoba lagi
    • Data global tetap berada dalam keadaan strict serializable
    • Secara lokal, klien mengalami Optimistic Snapshot Isolation; operasi baca melihat Snapshot yang konsisten secara internal, tetapi Snapshot tersebut dapat dibuang jika commit ditolak
  • Merge: menggabungkan state lokal dengan Snapshot terbaru dari server
    • Dalam kasus ini, model konsistensi global dapat turun menjadi snapshot isolation
  • Volume fork: membuat Volume baru secara permanen dan memisahkannya
    • Global serializability tetap dipertahankan

Aplikasi yang dapat dibangun

• Aplikasi offline-first: di aplikasi yang berjalan sebagian secara offline seperti catatan, manajemen tugas, dan aplikasi CRUD, Graft dapat menangani sinkronisasi
  • Jika digabungkan dengan conflict handler, fitur multiplayer juga dimungkinkan di atas data arbitrer
• Data lintas platform: data dapat dibagikan di platform mobile, perangkat, dan web, sekaligus mengurangi ketergantungan pada vendor
• Replika baca stateless: replika database dapat dijalankan tanpa state lokal; setelah mengambil metadata Snapshot terbaru, query dapat langsung dijalankan
  • Tidak perlu mengunduh seluruh data atau memutar ulang log
• Replikasi data arbitrer: karena Graft berfokus pada replikasi halaman, ia tidak ikut campur pada format data di dalam halaman
  • Data seperti database SQLite, model AI, file Parquet, Lance, dan Geospatial tilesets dapat dijadikan target

Ekstensi SQLite libgraft

• Saat ini cara termudah menggunakan Graft adalah libgraft, ekstensi SQLite native
• libgraft dapat digunakan di tempat SQLite berjalan, dan hanya mereplikasi bagian database yang benar-benar digunakan klien
• Ia mengimplementasikan SQLite VFS untuk mengintersep pembacaan dan penulisan database
• Ia menyediakan semantik transaksi dan konkurensi seperti yang disediakan SQLite dalam WAL mode
• Fitur yang disediakan adalah sebagai berikut
  • Replikasi asinkron dengan object storage
  • Replikasi parsial tertunda di edge dan perangkat
  • Serializable Snapshot Isolation
  • Pemulihan ke titik waktu tertentu
• Dokumentasinya tersedia di dokumentasi SQLite di GitHub

Partisipasi dan rencana layanan terkelola

• Graft dikembangkan secara terbuka di GitHub
• Issue, diskusi, dan Pull Request diterima, serta tersedia contribution guide
• Discord dan email disediakan sebagai kanal percakapan
• Peluncuran Graft Managed Service juga direncanakan, dan tautan untuk bergabung ke daftar tunggu tersedia

Roadmap

• Graft telah melalui satu tahun riset, beberapa iterasi, dan satu perubahan arah besar, tetapi masih banyak pekerjaan tersisa
• Item yang direncanakan adalah sebagai berikut
  • Dukungan WebAssembly: memungkinkan Graft digunakan di browser, dengan target dukungan untuk build Wasm resmi SQLite, wa-sqlite, dan sql.js
  • Integrasi Graft dan SQLSync: setelah dukungan Wasm, rencananya adalah memisahkan layer mutation, rebase, dan query subscription milik SQLSync lalu menempatkannya di atas database yang direplikasi Graft
  • Perluasan client library: wrapper klien Graft native untuk Python, JavaScript, Go, dan Java diinginkan
  • Penulisan latensi rendah: saat ini operasi push diblokir hingga commit sepenuhnya ke object storage
    • Eksperimen S3 express zone
    • Pendekatan menempatkan grup konsensus durable berlatensi rendah di depan object storage
  • Garbage collection, checkpointing, dan compaction: diperlukan untuk memaksimalkan performa query, meminimalkan ruang terbuang, dan melakukan penghapusan permanen
  • Autentikasi dan otorisasi: pekerjaan luas yang mencakup dari akun layanan terkelola hingga izin baca/tulis Volume yang terperinci
  • Volume forking: layanan dapat melakukan zero-copy fork dengan menyalin referensi Segment ke Volume baru, tetapi fork lokal saat ini harus menyalin semua halaman
  • Penanganan konflik: rencananya menyediakan strategi penyelesaian konflik bawaan dan titik ekstensi; strategi awalnya adalah menggabungkan otomatis transaksi yang tidak tumpang tindih

Perbandingan dengan solusi replikasi SQLite

• Informasi perbandingan dikumpulkan dari dokumentasi dan posting blog, dengan catatan bahwa mungkin tidak sepenuhnya akurat

• mvSQLite

  • mvSQLite mengimplementasikan layer VFS kustom yang menyimpan halaman SQLite langsung di FoundationDB
  • Graft dan mvSQLite mirip karena manajemen versi tingkat halaman memungkinkan delayed fetch dan tampilan database parsial
  • Perbedaannya ada pada lokasi penyimpanan dan cara pelacakan perubahan halaman
    • mvSQLite bergantung pada FoundationDB dan semua node harus mengakses cluster secara langsung
    • Changeset berbasis Splinter milik Graft bersifat self-contained sehingga lebih mudah didistribusikan, dan tidak perlu melakukan query langsung ke FoundationDB untuk mengetahui versi halaman yang berubah

• Litestream

  • Litestream adalah solusi backup streaming yang terus mereplikasi frame WAL SQLite ke object storage
  • Graft terintegrasi langsung ke proses commit SQLite melalui VFS kustom, sehingga memungkinkan replikasi parsial tertunda dan penulisan terdistribusi
  • Keduanya mereplikasi halaman ke object storage dan mendukung pemulihan ke titik waktu tertentu

• cr-sqlite

  • cr-sqlite adalah ekstensi SQLite yang mengubah tabel menjadi CRDT, sehingga memungkinkan replikasi logis tingkat baris
  • Ia menyediakan penyelesaian konflik otomatis, tetapi memerlukan kesadaran skema dan integrasi di tingkat aplikasi
  • Graft tidak bergantung pada skema dan kompatibel dengan ekstensi SQLite serta struktur data kustom arbitrer, tetapi demi global serializability, aplikasi harus menangani penyelesaian konflik secara eksplisit

• Cloudflare Durable Objects with SQLite Storage

  • Menggabungkan Durable Objects dan SQLite memungkinkan database dengan konsistensi kuat dan durabilitas tinggi, yang dibungkus oleh logika bisnis, ditempatkan di jaringan edge Cloudflare
  • Secara internal, ini mirip dengan Litestream karena mereplikasi WAL SQLite ke object storage dan melakukan checkpoint secara berkala
  • Graft mengekspos replikasi sebagai fitur kelas utama dan menargetkan replikasi yang efisien dengan edge

• Cloudflare D1

  • Cloudflare D1 adalah database SQLite terkelola yang diakses melalui HTTP API
  • Graft adalah model terdistribusi yang meng-embed data ke dalam aplikasi klien dan mereplikasikannya langsung ke edge

• Turso & libSQL

  • Turso menyediakan database SQLite terkelola dan replika embedded melalui libSQL
  • Graft dibedakan oleh replikasi parsial dan dukungan untuk struktur data arbitrer yang tidak bergantung pada skema
  • Layanan backend Graft beroperasi pada tingkat halaman dan menyerahkan seluruh lifecycle transaksi kepada klien

• rqlite & dqlite

  • rqlite dan dqlite mendistribusikan SQLite ke banyak server melalui konsensus berbasis Raft dan protokol jaringan
  • Keduanya berfokus pada sinkronisasi sekumpulan node stateful yang tetap saling terhubung
  • Graft adalah sistem stateless yang dibangun di atas object storage dan dirancang untuk bertukar data dengan edge

• Verneuil

  • Verneuil mereplikasi Snapshot SQLite secara asinkron ke replika baca melalui object storage, dengan mengutamakan keandalan
  • Mekanisme untuk meminimalkan replication lag atau freshness secara eksplisit dihindari
  • Graft bekerja lebih mirip database terdistribusi multi-writer dan menekankan replikasi parsial real-time yang selektif