सारा डेटा sync करना बंद करें

• Graft एक open source transaction storage engine है, जिसका उद्देश्य हर client को पूरा change log भेजने के बजाय physical replication की सादगी और logical replication की efficiency को जोड़ना है
• यह fixed-size Page से बने Volume को Snapshot इकाइयों में संभालता है, और server वास्तविक डेटा के बजाय बदले हुए page index का compressed bitmap graft भेजता है
• client graft देखकर सिर्फ ज़रूरी page लाता है, और Leap-आधारित prefetching, domain-specific prefetching, या पूरे change set को पहले से fetch करने जैसे विकल्प चुन सकता है
• object storage और edge server का उपयोग करके यह browser, mobile app, serverless function, और embedded environment जैसे resource-constrained environments में partial replication को लक्ष्य बनाता है
• इसका consistency model Serializable Snapshot Isolation है, और पुराने Snapshot पर आधारित commit को reject करके client को reset/replay, merge, या Volume fork में से एक विकल्प चुनने देता है

---

Graft जिस replication समस्या को हल करना चाहता है

• partial replication देखने में आसान लगती है क्योंकि इसमें सिर्फ ज़रूरी डेटा sync करना होता है, लेकिन वास्तविक design में हर replication approach की अपनी स्पष्ट लागत होती है
  • logical replication हर change को बारीकी से track करती है, लेकिन strong consistency को जटिल बना देती है
  • physical replication इस जटिलता से बचती है, लेकिन बाद में फेंक दिए जाने वाले change भी sync करने पड़ते हैं
• Graft एक open source transaction storage engine है, जिसे lazy sync, partial replication, strong consistency, horizontal scalability, और object storage durability को लक्ष्य बनाकर बनाया गया है
• इसकी शुरुआत SQLSync के अनुभव से हुई
  • SQLSync, SQLite पर बना frontend-optimized database stack है, जो sync engine में Git और distributed systems के विचारों का उपयोग करता है
  • SQLSync की संरचना हर client पर पूरा change log replicate करती है, इसलिए वह server पर तो ठीक है, लेकिन edge और browser environment के लिए उपयुक्त नहीं है
• Graft का लक्ष्य है कि client अपनी पसंद की गति से sync करें, सिर्फ ज़रूरी चीज़ें लाएँ, और edge व offline devices पर भी arbitrary data को strong consistency के साथ replicate कर सकें

full replication और schema-aware diff के बीच का design

• मौजूदा समाधान मोटे तौर पर दो हिस्सों में बंटते हैं
  • full replication: पूरा dataset हर client पर sync किया जाता है, इसलिए serverless function या web app जैसे constrained environment में यह व्यावहारिक नहीं है
  • schema-aware diff: CDC या CRDT की तरह row या field स्तर के logical change track किए जाते हैं, लेकिन इसके लिए application के साथ गहरा integration चाहिए और arbitrary data पर इसे सामान्यीकृत करना कठिन है
• Graft, full replication की तरह schema-agnostic है
  • यह stored data के प्रकार को न जानता है, न उसकी परवाह करता है, और bytes वाले page replicate करता है
• साथ ही logical replication की तरह यह client को आख़िरी sync के बाद क्या बदला है, उसका compressed विवरण देता है
• इसकी core abstraction Volume है
  • Volume fixed-size Page का sparse और ordered collection है
  • client किसी खास Snapshot पर transaction API के ज़रिए Volume को read और write करते हैं
  • अंदरूनी तौर पर Graft सिर्फ ज़रूरी चीज़ें store और replicate करता है, और object storage को durable तथा scalable backend की तरह इस्तेमाल करता है

lazy sync: client जब चाहे तब catch up करे

• Graft को इस मान्यता के साथ design किया गया है कि edge client कभी-कभी ही जागते हैं, network unstable होता है, और execution time छोटा होता है
• continuous replication पर निर्भर रहने के बजाय, client खुद चुनते हैं कि कब sync करना है
• sync की शुरुआत इस सवाल से होती है: “पिछले Snapshot के बाद क्या बदला?”
• server वास्तविक डेटा भेजने के बजाय बदले हुए page index का compressed bitmap graft लौटाता है
  • graft मौजूदा Snapshot पर नए change जोड़ने के निर्देश की तरह काम करता है
  • client समझ सकता है कि कौन से page दोबारा उपयोग किए जा सकते हैं और कौन से page ज़रूरत पड़ने पर fetch करने होंगे
• क्योंकि graft डेटा नहीं बल्कि change metadata है, इसलिए क्या और कब fetch करना है इसका नियंत्रण client के पास रहता है

partial replication और prefetching

• browser tab, mobile app, और serverless function में कुछ query संभालने के लिए पूरा dataset डाउनलोड करना मुश्किल होता है
• graft मिलने के बाद client तय करता है कि कौन से page अब भी valid हैं और कौन से fetch करने होंगे
• सिर्फ ज़रूरी page चुनकर fetch करने से वास्तव में इस्तेमाल होने वाला डेटा ही replicate किया जा सकता है
• page access latency घटाने के लिए Graft कई prefetching तरीके देता है
  • general-purpose prefetching: Leap algorithm पर आधारित built-in prefetcher access pattern पहचानकर आगे होने वाले page access का अनुमान लगाता है
  • domain-specific prefetching: application user profile जैसे अक्सर पढ़े जाने वाले डेटा के बारे में अपनी जानकारी का उपयोग करके संबंधित page पहले से ला सकता है
  • eager fetch: ज़रूरत पड़ने पर सारे changes पहले से fetch करके व्यवहारिक रूप से full replication पर लौटा जा सकता है, जो खासकर server-side Graft workload में उपयोगी है
• page सीधे object storage पर host किए जाते हैं, इसलिए replication की नींव durability और scalability दोनों देती है

edge deployment और embedded client

• Graft की edge replication का लक्ष्य सिर्फ यह तय करना नहीं है कि कौन सा डेटा sync होगा, बल्कि यह भी है कि डेटा ज़रूरत की जगह पर मौजूद हो
• page object storage से global edge server fleet के ज़रिए serve किए जाते हैं
  • अक्सर access होने वाले hot page को client के पास cache किया जा सकता है
  • लक्ष्य है दुनिया भर के user location से low latency और high responsiveness देना
• Graft client को lightweight और embeddable बनाने के लिए design किया गया है
  • dependencies कम हैं और runtime छोटा है
  • इसे browser, device, mobile app, और serverless function जैसे environment में integrate किया जा सकता है
• क्योंकि edge caching consistency और conflict handling की समस्या पैदा करती है, Graft इसके साथ strong consistency model भी देता है

consistency model और conflict handling

• Graft अपना consistency model Serializable Snapshot Isolation रखता है
• client किसी खास Snapshot पर isolated और consistent data view पाते हैं, और reads एक-दूसरे को बाधित किए बिना साथ-साथ चल सकते हैं
• writes को सख्ती से serialize किया जाता है, जिससे सभी transaction के लिए वैश्विक रूप से consistent order बनता है
• offline-first और lazy replication प्रकृति के कारण client पुराने Snapshot के आधार पर commit करने की कोशिश कर सकते हैं
  • ऐसे commit को बिना शर्त स्वीकार करने से strict serializability टूट जाएगी
  • Graft ऐसे commit को सुरक्षित रूप से reject करता है और client को आगे का तरीका चुनने देता है
• client के लिए आम तौर पर तीन विकल्प हैं
  • Reset and replay: नया Snapshot लाएँ, local transaction फिर से apply करें, और दोबारा कोशिश करें
    • global data strict serializable स्थिति में बना रहता है
    • local स्तर पर Optimistic Snapshot Isolation जैसा अनुभव मिलता है, जहाँ read अंदरूनी रूप से consistent Snapshot देखती है लेकिन commit reject होने पर वह Snapshot छोड़ा जा सकता है
  • Merge: local state को server के latest Snapshot के साथ merge करें
    • इस स्थिति में global consistency model snapshot isolation तक घट सकता है
  • Volume fork: स्थायी रूप से अलग नया Volume बनाकर अलग हो जाएँ
    • इससे global serializability बनी रहती है

किन applications को बनाया जा सकता है

• offline-first app: notes, task management, और CRUD app जैसे आंशिक रूप से offline काम करने वाले app में Graft sync संभाल सकता है
  • conflict handler के साथ मिलाकर arbitrary data पर multiplayer feature भी संभव हैं
• cross-platform data: mobile platform, device, और web के बीच डेटा share किया जा सकता है और vendor lock-in कम किया जा सकता है
• stateless read replica: बिना local state के database replica चलाकर latest Snapshot metadata लिया जा सकता है और तुरंत query चलाई जा सकती है
  • पूरा डेटा डाउनलोड करने या log replay करने की ज़रूरत नहीं होती
• arbitrary data replication: Graft page replication पर केंद्रित है, इसलिए page के अंदर के data format में दखल नहीं देता
  • यह SQLite database, AI model, Parquet, Lance file, और Geospatial tilesets जैसे डेटा पर काम कर सकता है

SQLite extension libgraft

• अभी Graft इस्तेमाल करने का सबसे आसान तरीका native SQLite extension libgraft है
• libgraft वहाँ इस्तेमाल किया जा सकता है जहाँ SQLite चलता है, और यह database का सिर्फ वही हिस्सा replicate करता है जिसे client वास्तव में उपयोग करता है
• यह SQLite VFS implement करता है और database read/write को intercept करता है
• यह वही transaction और concurrency semantics देता है जो SQLite WAL mode में प्रदान करता है
• इसमें ये सुविधाएँ शामिल हैं
  • object storage के साथ asynchronous replication
  • edge और device पर lazy partial replication
  • Serializable Snapshot Isolation
  • point-in-time recovery
• दस्तावेज़ GitHub के SQLite docs में देखे जा सकते हैं

भागीदारी और managed service की योजना

• Graft का विकास GitHub पर खुले रूप में हो रहा है
• issue, discussion, और Pull Request स्वीकार किए जाते हैं, और contribution guide उपलब्ध है
• बातचीत के लिए Discord और email channel दिए गए हैं
• Graft Managed Service लॉन्च करने की भी योजना है, और उसके लिए waitlist link उपलब्ध है

roadmap

• Graft ने 1 साल की research, कई iteration, और एक बड़े direction change से गुज़रने के बाद यह रूप लिया है, लेकिन अभी बहुत काम बाकी है
• योजनाबद्ध आइटम इस प्रकार हैं
  • WebAssembly support: browser में Graft को उपयोगी बनाना, और SQLite official Wasm build, wa-sqlite, sql.js support देना लक्ष्य है
  • Graft और SQLSync integration: Wasm support के बाद SQLSync की mutation, rebase, और query subscription layer को अलग करके Graft-replicated database के ऊपर रखना योजना में है
  • client library विस्तार: Python, JavaScript, Go, और Java के लिए native Graft client wrapper चाहिए
  • low-latency writes: अभी push operation object storage में पूरी तरह commit होने तक block रहता है
    • S3 express zone experiment
    • object storage के सामने low-latency durable consensus group रखने का तरीका
  • garbage collection, checkpointing, compaction: query performance अधिकतम करने, waste space कम करने, और permanent deletion के लिए ज़रूरी
  • authentication और authorization: managed service account से लेकर Volume read/write के fine-grained permission तक का बड़ा कार्यक्षेत्र
  • Volume forking: service Segment reference को नए Volume में कॉपी करके zero-copy fork कर सकती है, लेकिन local fork में अभी सभी page कॉपी करने पड़ते हैं
  • conflict handling: built-in conflict resolution strategy और extension point देने की योजना है, और शुरुआती strategy overlapping न होने वाले transaction को auto-merge करना है

SQLite replication समाधानों के साथ तुलना

• तुलना से जुड़ी जानकारी docs और blog post से जुटाई गई है, और साथ में यह सावधानी भी दी गई है कि यह पूरी तरह सटीक न हो सकती है

• mvSQLite

  • mvSQLite एक custom VFS layer implement करता है जो SQLite page को सीधे FoundationDB में store करता है
  • Graft और mvSQLite दोनों page-level versioning के ज़रिए lazy fetch और partial database view को संभव बनाते हैं
  • अंतर storage location और page change tracking तरीके में है
    • mvSQLite FoundationDB पर निर्भर है और सभी node को cluster तक सीधी पहुँच चाहिए
    • Graft का Splinter-based changeset self-contained है, इसलिए deploy करना आसान है, और बदले हुए page version जानने के लिए FoundationDB से सीधे query करने की ज़रूरत नहीं पड़ती

• Litestream

  • Litestream SQLite WAL frame को लगातार object storage में replicate करने वाला streaming backup solution है
  • Graft custom VFS के ज़रिए SQLite commit प्रक्रिया में सीधे integrate होता है, जिससे lazy partial replication और distributed writes संभव होते हैं
  • दोनों page को object storage में replicate करते हैं और point-in-time recovery support करते हैं

• cr-sqlite

  • cr-sqlite एक SQLite extension है जो table को CRDT में बदलकर logical row-level replication संभव बनाता है
  • यह automatic conflict resolution देता है, लेकिन schema-aware और application-level integration की आवश्यकता होती है
  • Graft schema-agnostic है और arbitrary SQLite extension तथा custom data structure के साथ compatible है, लेकिन global serializability के लिए application को conflict resolution स्पष्ट रूप से संभालना होता है

• Cloudflare Durable Objects with SQLite Storage

  • Durable Objects और SQLite का संयोजन Cloudflare edge network में business logic से घिरी strong consistency और high durability वाली database layer दे सकता है
  • अंदरूनी तौर पर यह SQLite WAL को object storage में replicate करता है और समय-समय पर checkpoint करता है, जो Litestream जैसा है
  • Graft replication को first-class feature के रूप में expose करता है और edge के साथ efficient replication को लक्ष्य बनाता है

• Cloudflare D1

  • Cloudflare D1 HTTP API से access होने वाला managed SQLite database है
  • Graft distributed model अपनाता है जिसमें डेटा को client application में embed करके सीधे edge तक replicate किया जाता है

• Turso & libSQL

  • Turso libSQL के माध्यम से managed SQLite database और embedded replica प्रदान करता है
  • Graft partial replication और arbitrary schema-agnostic data structure support के कारण अलग दिखता है
  • Graft backend service page level पर काम करती है और पूरा transaction lifecycle client को सौंपती है

• rqlite & dqlite

  • rqlite और dqlite Raft-based consensus और network protocol के ज़रिए SQLite को कई server पर distribute करते हैं
  • इनका फोकस आपस में जुड़े रहने वाले stateful node के समूह को sync करना है
  • Graft object storage पर बना stateless system है, जिसे edge के साथ डेटा exchange करने के लिए design किया गया है

• Verneuil

  • Verneuil object storage के माध्यम से SQLite Snapshot को read replica में asynchronously replicate करता है और reliability को प्राथमिकता देता है
  • replication lag या freshness को न्यूनतम करने वाले mechanism से यह स्पष्ट रूप से बचता है
  • Graft multi-writer distributed database के अधिक करीब काम करता है और selective real-time partial replication पर ज़ोर देता है