सब कुछ sync करना बंद करें

 (sqlsync.dev)
1 पॉइंट द्वारा GN⁺ 2025-04-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें

edge replication के लिए एक नया approach

  • डेटा sync करना जितना दिखता है उससे कहीं ज़्यादा कठिन समस्या है। मौजूदा solutions आम तौर पर या तो पूरा dataset client पर sync करते हैं, या logical changes को track करते हैं।
  • Graft को इन समस्याओं को हल करने के लिए डिज़ाइन किया गया है, और यह एक open source storage engine है जो simple physical replication और efficient logical replication को जोड़ता है।

lazy sync: अपनी पसंद की गति से sync करें

  • Graft clients को यह चुनने देता है कि वे कब sync करें, इसलिए यह ऐसे edge environments के लिए उपयुक्त है जो बीच-बीच में ही network से जुड़ते हैं।
  • server client के last snapshot के बाद बदले हुए pages का index देता है, और client सिर्फ ज़रूरी डेटा को चुनकर fetch कर सकता है।

partial sync: केवल वही sync करें जिसकी ज़रूरत हो

  • edge environments में पूरे dataset को डाउनलोड करना संभव नहीं होता, इसलिए Graft partial sync को support करता है, जिसमें सिर्फ ज़रूरी pages को selectively fetch किया जाता है।
  • Graft सामान्य prediction algorithms और domain knowledge का उपयोग करके ज़रूरी pages को पहले से fetch कर सकता है।

edge: जहाँ ज़रूरत हो उसके करीब sync

  • Graft दुनिया भर के edge servers के ज़रिए डेटा उपलब्ध कराता है, ताकि user कहीं भी हो, low latency और high responsiveness बनी रहे।
  • client को lightweight बनाया गया है, इसलिए इसे browser, mobile apps, और serverless environments में आसानी से integrate किया जा सकता है।

consistency: सुरक्षित sync

  • Graft एक strong consistency model देता है, जिससे clients के बीच conflicts को सुरक्षित तरीके से handle किया जा सकता है।
  • clients snapshot isolation model के ज़रिए डेटा का consistent view पा सकते हैं, और writes को सख्ती से serialize किया जाता है।

Graft से क्या बनाया जा सकता है?

  • Graft कई तरह के edge-native applications के लिए एक मज़बूत foundation देता है।
  • offline-first apps, cross-platform data, stateless read replicas, और arbitrary data replication जैसी चीज़ें संभव हैं।

Graft SQLite extension (libgraft)

  • libgraft, SQLite का native extension है, जो clients को वास्तव में इस्तेमाल होने वाले database के सिर्फ एक हिस्से को replicate करने देता है, ताकि resource-constrained environments में भी SQLite चल सके।
  • यह asynchronous replication, lazy partial replication, snapshot isolation, point-in-time recovery जैसी सुविधाएँ देता है।

कैसे शामिल हों

  • Graft का development GitHub पर हो रहा है, और community contributions का स्वागत है।
  • आप Discord पर जुड़ सकते हैं या email के ज़रिए feedback दे सकते हैं।
  • आप Graft managed service की waitlist में register कर सकते हैं।

roadmap

  • Graft अभी development में है, और WebAssembly support, SQLSync के साथ integration, तथा कई client libraries के support जैसी योजनाएँ हैं।
  • write latency कम करना, garbage collection, authentication और authorization, volume forking, conflict handling जैसी सुविधाएँ भी जोड़ी जाएँगी।

दूसरे SQLite replication solutions से तुलना

  • Graft की mvSQLite, Litestream, cr-sqlite, Cloudflare Durable Objects, Cloudflare D1, Turso & libSQL, rqlite & dqlite, Verneuil आदि से तुलना करने पर इसके अपने अनोखे फायदे सामने आते हैं।
  • partial replication, arbitrary data structures का support, और edge पर efficient replication इसके प्रमुख differentiators हैं।

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-04-02
Hacker News की राय

  • consistency model समझ में नहीं आ रहा

    • Graft client लोकल में commit करता है और asynchronous तरीके से remote commit की कोशिश करता है
    • अगर दो client एक ही snapshot के आधार पर एक साथ commit करें, तो एक सफल होगा और दूसरा विफल
    • API सिर्फ एक single commit operation देता है
    • लोकल commit सफल होने पर अगर asynchronous propagation विफल हो जाए, तो rollback करना पड़ेगा
    • "commit" की अवधारणा कई अर्थों में मिली-जुली है

  • Graft के लेखक ने धन्यवाद दिया

    • Washington DC में Antithesis BugBash में शामिल हैं
    • Washington में मौजूद लोगों से मिलना चाहते हैं

  • consistency model git जैसा लगता है

    • लोकल copy बदलते हैं और "push" करते समय conflict हो सकता है
    • conflict को साफ़ तौर पर detect करने का कोई तरीका नहीं है
    • read conflict की वजह से conflict हो सकता है

  • जब client Graft को fetch करता है, तो उसे ठीक-ठीक पता चल सकता है कि क्या बदला है

    • Cloud-Backed SQLite के manifest से तुलना की गई
    • server पर computation की ज़रूरत नहीं है

  • implementation details पर बात नहीं की गई

    • एक ऐसी sync layer चाहिए जिसमें app developer को sync की चिंता न करनी पड़े
    • subscription के बिना personal sync को support किया जा सकता है

  • VFS का इस्तेमाल एक मज़ेदार "hack" लगता है

    • offline-first IDE के लिए अपना sync engine बना रहे हैं
    • tree structure का इस्तेमाल करने पर conflict resolution चुनौती है

  • Leap algorithm का इस्तेमाल करने वाला project बहुत दिलचस्प है

    • SQLite integration पर ध्यान देना आसान है, लेकिन यह इसे ज़्यादा general और low-level distributed storage problem की तरह देखता है
    • बिना ठोस अनुभव वाला generic solution जोखिमभरा हो सकता है

  • mobile client धीमे connection पर हो तो समस्या आ सकती है

    • slow sync detect करके server को सीधे query भेजने वाला hybrid approach सुझाया गया

  • page को default sync unit की तरह इस्तेमाल करने वाला approach दिलचस्प है

    • बहुत से concurrent user के साथ conflict हो सकता है
    • OT या CRDT बेहतर हो सकते हैं

  • यह बहुत चुनौतीपूर्ण समस्या है

    • इसे React Native app में आज़माना चाहते हैं