Tüm verileri senkronize etmeyi bırakın

• Graft, tüm istemcilere tam değişiklik günlüğü göndermek yerine fiziksel replikasyonun sadeliğiyle mantıksal replikasyonun verimliliğini birleştirmeye çalışan açık kaynaklı bir işlemsel depolama motorudur
• Sabit boyutlu Page’lerden oluşan Volume’leri Snapshot biriminde ele alır; sunucu gerçek veriyi değil, değişen sayfa indekslerinin sıkıştırılmış bit kümesi olan graftı gönderir
• İstemci grafta bakarak yalnızca ihtiyaç duyduğu sayfaları alır; Leap tabanlı prefetching, alan adına özel prefetching veya tüm değişiklikleri getiren proaktif getirme arasında seçim yapabilir
• Nesne depolama ve edge sunucularından yararlanarak tarayıcı, mobil uygulama, serverless fonksiyon ve gömülü ortamlar gibi kısıtlı ortamlarda da kısmi replikasyonu hedefler
• Tutarlılık modeli Serializable Snapshot Isolation’dır; eski Snapshot’a dayalı commit’leri reddeder ve istemcinin bunları reset/replay, merge veya Volume fork seçeneklerinden biriyle ele almasını sağlar

---

Graft’ın çözmeye çalıştığı replikasyon sorunu

• Kısmi replikasyon, yalnızca gerekli verileri senkronize edince kolay görünür; ancak gerçek tasarımda her replikasyon yönteminin belirgin bir bedeli vardır
  • Mantıksal replikasyon tüm değişiklikleri hassas biçimde izler, ancak güçlü tutarlılığı karmaşık hâle getirir
  • Fiziksel replikasyon bu karmaşıklıktan kaçınır, ancak daha sonra atılacak değişiklikleri bile senkronize etmek zorunda kalır
• Graft, gecikmeli senkronizasyon, kısmi replikasyon, güçlü tutarlılık, yatay ölçeklenebilirlik ve nesne depolama dayanıklılığı hedefleriyle oluşturulmuş açık kaynaklı bir işlemsel depolama motorudur
• Çıkış noktası SQLSync deneyimidir
  • SQLSync, SQLite üzerine inşa edilmiş, ön yüz odaklı bir veritabanı yığınıdır; senkronizasyon motorunda Git ve dağıtık sistem fikirlerini kullanır
  • SQLSync, tüm değişiklik günlüğünü tüm istemcilere replike eden bir yapıya sahip olduğundan sunucuda iyi çalışsa da edge ve tarayıcı ortamlarına uygun değildir
• Graft’ın hedefi, istemcilerin istedikleri hızda senkronize olması, yalnızca ihtiyaç duyduklarını alması ve edge ile çevrimdışı cihazlarda rastgele verileri güçlü tutarlılıkla replike etmesidir

Tam replikasyon ile şema farkındalığı olan diff arasındaki tasarım

• Mevcut çözümler genel olarak iki kola ayrılır
  • Tam replikasyon: Tüm veri kümesini her istemciyle senkronize eder; bu yüzden serverless fonksiyonlar veya web uygulamaları gibi kısıtlı ortamlar için pratik değildir
  • Şema farkındalığı olan diff: CDC veya CRDT gibi satır ya da alan düzeyindeki mantıksal değişiklikleri izler, ancak uygulamayla derin entegrasyon gerektirir ve rastgele veriler için genelleştirmesi zordur
• Graft, tam replikasyon gibi şemadan bağımsızdır
  • Saklanan verinin türünü bilmez ya da önemsemez; bayt içeren sayfaları replike eder
• Aynı zamanda mantıksal replikasyon gibi, son senkronizasyondan bu yana neyin değiştiğine dair sıkıştırılmış bir açıklamayı istemciye iletir
• Temel soyutlama Volume’dür
  • Volume, sabit boyutlu Page’lerden oluşan seyrek ve sıralı bir koleksiyondur
  • İstemciler belirli bir Snapshot’ta işlem API’siyle Volume okur ve yazar
  • İçeride Graft yalnızca gerekli olanı depolar ve replike eder; dayanıklı ve ölçeklenebilir arka uç olarak nesne depolamayı kullanır

Gecikmeli senkronizasyon: istemcinin istediği zamanda yetişmesi

• Graft, edge istemcilerinin ara sıra uyandığı, ağın kararsız olduğu ve çalışma süresinin kısa olduğu ortamlar varsayılarak tasarlanmıştır
• Sürekli replikasyona bağlı kalmaz; istemci ne zaman senkronize olacağını doğrudan seçer
• Senkronizasyon “son Snapshot’tan bu yana ne değişti?” sorusuyla başlar
• Sunucu gerçek veriyi göndermez; yanıt olarak değişen sayfa indekslerinin sıkıştırılmış bit kümesi olan **graft**ı döner
  • graft, mevcut Snapshot’a yeni değişiklikleri ekleme konusunda bir kılavuz görevi görür
  • İstemci hangi sayfaları yeniden kullanabileceğini, hangi sayfaları da gerektiğinde getirmesi gerektiğini bilir
• graft veri değil değişiklik meta verisi olduğundan, neyin ne zaman getirileceğine dair kontrol istemcide kalır

Kısmi replikasyon ve prefetching

• Tarayıcı sekmelerinde, mobil uygulamalarda ve serverless fonksiyonlarda bazı sorguları işlemek için tüm veri kümesini indirmek zordur
• İstemci graftı aldıktan sonra hangi sayfaların hâlâ geçerli olduğunu ve hangi sayfaları getirmesi gerektiğini değerlendirir
• Yalnızca gerekli sayfaları seçerek getirdiği için gerçekten kullanılacak veriyi replike edebilir
• Graft, sayfa erişim gecikmesini azaltmak için çeşitli prefetching yöntemlerini destekler
  • Genel amaçlı prefetching: Leap algoritmasına dayalı yerleşik prefetcher, erişim örüntülerini belirleyerek gelecekteki sayfa erişimlerini tahmin eder
  • Alan adına özel prefetching: Uygulama, kullanıcı profilleri gibi sık sorgulanan verilere ilişkin bilgisini kullanarak ilgili sayfaları önceden getirebilir
  • Proaktif getirme: Gerekirse tüm değişiklikler getirilerek fiilen tam replikasyona dönülebilir; bu özellikle sunucu tarafı Graft iş yükleri için yararlıdır
• Sayfalar doğrudan nesne depolamada barındırıldığı için dayanıklı ve ölçeklenebilir bir replikasyon temeli olarak kullanılır

Edge dağıtımı ve gömülü istemciler

• Graft’ın edge replikasyonu yalnızca hangi verilerin senkronize edileceğini değil, verinin ihtiyaç duyulan konuma yerleştirilmesini de hedefler
• Sayfalar, nesne depolamadan küresel bir edge sunucu filosu üzerinden sunulur
  • Sık erişilen hot page’ler istemciye yakın yerlerde önbelleğe alınabilir
  • Dünya genelindeki kullanıcı konumundan bağımsız olarak düşük gecikme ve yüksek yanıt verebilirlik hedeflenir
• Graft istemcisi hafif ve gömülebilir olacak şekilde tasarlanmıştır
  • Az bağımlılığa ve küçük bir çalışma zamanına sahiptir
  • Tarayıcı, cihaz, mobil uygulama ve serverless fonksiyon gibi ortamlara entegre edilebilir
• Edge önbellekleme, tutarlılık ve çakışma yönetimi sorunları yarattığından Graft güçlü bir tutarlılık modeli de sağlar

Tutarlılık modeli ve çakışma yönetimi

• Graft tutarlılık modeli olarak Serializable Snapshot Isolation kullanır
• İstemciler belirli bir Snapshot’ta yalıtılmış ve tutarlı bir veri görünümü elde eder; okumalar birbirini engellemeden eşzamanlı ilerleyebilir
• Yazmalar katı biçimde seri hâle getirilir ve tüm işlemler için küresel olarak tutarlı bir sıra oluşur
• Offline-first ve gecikmeli replikasyon özellikleri nedeniyle istemci eski bir Snapshot’a dayanarak commit denemesi yapabilir
  • Bu tür commit’leri koşulsuz kabul etmek strict serializability’yi bozar
  • Graft bu commit’i güvenli biçimde reddeder ve istemcinin nasıl ele alacağını seçmesini sağlar
• İstemcinin tipik seçenekleri üç tanedir
  • Reset and replay: En güncel Snapshot’ı getirir, yerel işlemleri yeniden uygular ve tekrar dener
    • Küresel veri strict serializable durumda kalır
    • Yerelde Optimistic Snapshot Isolation deneyimlenir; okumalar dahili olarak tutarlı bir Snapshot görür, ancak commit reddedilirse bu Snapshot atılabilir
  • Merge: Yerel durumu sunucunun en güncel Snapshot’ıyla birleştirir
    • Bu durumda küresel tutarlılık modeli snapshot isolation düzeyine düşebilir
  • Volume fork: Kalıcı olarak yeni bir Volume oluşturup ayrıştırır
    • Küresel serializability korunur

Oluşturulabilecek uygulamalar

• Offline-first uygulamalar: Not, görev yönetimi ve CRUD uygulamaları gibi kısmen çevrimdışı çalışan uygulamalarda senkronizasyonu Graft üstlenebilir
  • Çakışma işleyicileriyle birleştirildiğinde rastgele veri üzerinde multiplayer özellikleri de mümkün olur
• Platformlar arası veri: Mobil platformlar, cihazlar ve web arasında veri paylaşımı sağlayıp tedarikçi bağımlılığını azaltabilir
• Durumsuz okuma replikaları: Yerel durum olmadan bir veritabanı replikası başlatıp en güncel Snapshot meta verisini aldıktan sonra hemen sorgu çalıştırabilir
  • Tüm veriyi indirmeye veya log replay yapmaya gerek yoktur
• Rastgele veri replikasyonu: Graft sayfa replikasyonuna odaklandığından sayfa içindeki veri biçimine karışmaz
  • SQLite veritabanları, yapay zeka modelleri, Parquet, Lance dosyaları, Geospatial tilesets gibi verileri hedefleyebilir

SQLite uzantısı libgraft

• Graft’ı kullanmanın şu anda en kolay yolu yerel SQLite uzantısı libgraft’tır
• libgraft, SQLite’ın çalıştığı her yerde kullanılabilir ve istemcinin gerçekten kullandığı veritabanı parçalarını replike eder
• SQLite VFS uygulayarak veritabanı okuma ve yazmalarını yakalar
• SQLite’ın WAL mode ile sunduğuna benzer işlem ve eşzamanlılık semantiklerini sağlar
• Sağladığı özellikler şunlardır
  • Nesne depolama ile asenkron replikasyon
  • Edge ve cihazlarda gecikmeli kısmi replikasyon
  • Serializable Snapshot Isolation
  • Belirli bir zamana geri yükleme
• Belgeler GitHub’daki SQLite dokümanlarında görülebilir

Katılım ve yönetilen servis planı

• Graft, GitHub üzerinde açık olarak geliştiriliyor
• Issue, tartışma ve Pull Request kabul ediliyor; contribution guide sağlanıyor
• İletişim kanalları olarak Discord ve e-posta sunuluyor
• Graft Managed Service’in çıkarılması da planlanıyor ve bekleme listesine kayıt bağlantısı sağlanıyor

Yol haritası

• Graft, 1 yıllık araştırma, birçok yineleme ve büyük bir yön değişikliğinden geçti; ancak hâlâ yapılacak çok iş var
• Planlanan maddeler şunlardır
  • WebAssembly desteği: Graft’ın tarayıcıda kullanılmasını sağlamak; SQLite’ın resmi Wasm derlemesi, wa-sqlite ve sql.js desteğini hedefler
  • Graft ve SQLSync entegrasyonu: Wasm desteğinden sonra SQLSync’in mutation, rebase ve query subscription katmanlarını ayırıp Graft replikasyon veritabanının üzerine yerleştirme planıdır
  • İstemci kütüphanelerini genişletme: Python, JavaScript, Go ve Java için yerel Graft istemci wrapper’ları isteniyor
  • Düşük gecikmeli yazmalar: Mevcut push işlemleri, nesne depolamaya tamamen commit edilene kadar bloklanıyor
    • S3 express zone denemeleri
    • Nesne depolamanın önüne düşük gecikmeli, dayanıklı bir konsensüs grubu koyma yaklaşımı
  • Çöp toplama, checkpointing ve compaction: Sorgu performansını en üst düzeye çıkarmak, boşa harcanan alanı en aza indirmek ve kalıcı silme için gereklidir
  • Kimlik doğrulama ve yetkilendirme: Yönetilen servis hesaplarından Volume okuma/yazma için ince taneli izinlere kadar uzanan geniş bir iştir
  • Volume forking: Servis, Segment referanslarını yeni Volume’e kopyalayarak zero-copy fork yapabilir; ancak yerel fork şu anda tüm sayfaların kopyalanmasını gerektiriyor
  • Çakışma yönetimi: Yerleşik çakışma çözüm stratejileri ve genişletme noktaları sunulması planlanıyor; ilk strateji, örtüşmeyen işlemleri otomatik birleştirmek olacak

SQLite replikasyon çözümleriyle karşılaştırma

• Karşılaştırma bilgileri dokümanlar ve blog yazılarından toplanmıştır; tamamen doğru olmayabileceğine dair bir not eklenmiştir

• mvSQLite

  • mvSQLite, SQLite sayfalarını doğrudan FoundationDB içinde depolayan özel bir VFS katmanı uygular
  • Graft ve mvSQLite, sayfa düzeyinde sürüm yönetimiyle gecikmeli fetch ve kısmi veritabanı görünümlerini mümkün kılmaları bakımından benzerdir
  • Fark, depolama konumu ve sayfa değişikliklerinin izlenme yöntemidir
    • mvSQLite FoundationDB’ye dayanır ve tüm düğümlerin kümeye doğrudan erişmesi gerekir
    • Graft’ın Splinter tabanlı changeset’i kendi kendine yeterlidir; bu da dağıtımı kolaylaştırır ve değişen sayfa sürümlerini bilmek için FoundationDB’yi doğrudan sorgulamayı gerektirmez

• Litestream

  • Litestream, SQLite WAL frame’lerini sürekli olarak nesne depolamaya replike eden bir streaming yedekleme çözümüdür
  • Graft, özel VFS ile SQLite commit sürecine doğrudan entegre olur; gecikmeli kısmi replikasyon ve dağıtık yazmaları mümkün kılar
  • İkisi de sayfaları nesne depolamaya replike eder ve belirli bir zamana geri yüklemeyi destekler

• cr-sqlite

  • cr-sqlite, tabloları CRDT’ye dönüştürerek mantıksal satır düzeyi replikasyonu mümkün kılan bir SQLite uzantısıdır
  • Otomatik çakışma çözümü sunar, ancak şema farkındalığı ve uygulama düzeyinde entegrasyon gerektirir
  • Graft şemadan bağımsızdır ve rastgele SQLite uzantıları ile özel veri yapılarıyla uyumludur; ancak küresel serializability için uygulamanın çakışma çözümünü açıkça ele alması gerekir

• Cloudflare Durable Objects with SQLite Storage

  • Durable Objects ile SQLite birleştirildiğinde, iş mantığıyla sarılmış güçlü tutarlılığa ve yüksek dayanıklılığa sahip bir veritabanı Cloudflare edge ağına yerleştirilebilir
  • İçeride SQLite WAL’ı nesne depolamaya replike etmesi ve periyodik checkpoint yapması bakımından Litestream’e benzer
  • Graft, replikasyonu birinci sınıf bir özellik olarak sunar ve edge ile verimli replikasyonu hedefler

• Cloudflare D1

  • Cloudflare D1, HTTP API üzerinden erişilen yönetilen bir SQLite veritabanıdır
  • Graft, veriyi istemci uygulamasına gömerek doğrudan edge’e replike eden dağıtık bir modeldir

• Turso & libSQL

  • Turso, libSQL aracılığıyla yönetilen SQLite veritabanı ve gömülü replikalar sağlar
  • Graft, kısmi replikasyon ve rastgele, şemadan bağımsız veri yapılarını desteklemesiyle ayrışır
  • Graft arka uç servisi sayfa düzeyinde çalışır ve işlem yaşam döngüsünün tamamını istemciye bırakır

• rqlite & dqlite

  • rqlite ve dqlite, Raft tabanlı konsensüs ve ağ protokolü üzerinden SQLite’ı birden çok sunucuya dağıtır
  • Bunlar birbirine bağlı kalan durumlu düğüm kümelerini senkronize etmeye odaklanır
  • Graft, nesne depolama üzerine kurulu durumsuz bir sistemdir ve edge ile veri alışverişi yapmak üzere tasarlanmıştır

• Verneuil

  • Verneuil, SQLite Snapshot’larını nesne depolama üzerinden okuma replikalarına asenkron olarak replike eder ve güvenilirliği önceliklendirir
  • Replikasyon gecikmesini veya güncelliği en aza indirecek mekanizmalardan özellikle kaçınır
  • Graft daha çok çok yazarlı dağıtık veritabanı gibi çalışır ve seçici gerçek zamanlı kısmi replikasyonu vurgular