हर Durable Object में zero-latency SQLite स्टोरेज

 (simonwillison.net)
2 पॉइंट द्वारा GN⁺ 2024-10-15 | 1 टिप्पणियां | WhatsApp पर शेयर करें

  • हर Durable Object में zero-latency SQLite storage

    • Kenton Varda ने Cloudflare के Durable Object प्लेटफ़ॉर्म के अगले संस्करण का परिचय दिया, जिसे हाल ही में key/value स्टोरेज से SQLite-आधारित पूर्ण relational system में अपग्रेड किया गया है
    • Durable Objects के पहले संस्करण की उपयोगी पृष्ठभूमि के लिए Paul Butler का Cloudflare का durable multiplayer moat देखा जा सकता है। यह WebSocket-आधारित real-time collaborative applications बनाने में लोकप्रिय है
    • नए SQLite-आधारित Durable Objects distributed system design का एक आकर्षक तत्व हैं, जो बड़े पैमाने के applications डिज़ाइन करने का एक रोचक तरीका सुझाते हैं

  • Durable Objects का मुख्य विचार

    • Durable Object, data और application logic को उसी physical host पर रखता है, जिससे बहुत तेज़ read और write performance मिलती है
    • एक single object, single machine के single thread पर चलता है, इसलिए throughput सीमित होता है। ज़्यादा traffic संभालने के लिए और objects बनाए जाते हैं। यह तब सबसे आसान होता है जब state की हर unit पर इतना कम traffic हो कि उसे एक single object संभाल सके

  • फ्लाइट बुकिंग सिस्टम का उदाहरण

    • हर flight को अपने SQLite database वाले समर्पित Durable Object से map किया जा सकता है। हर airline के लिए हर दिन हज़ारों नए databases बनते हैं
    • हर DO का एक unique नाम होता है, और Cloudflare का network requests को उस object तक route करता है, चाहे वह दुनिया में कहीं भी हो

  • तकनीकी विवरण

    • Litestream से प्रेरित होकर, हर DO WAL entries की sequence को लगातार object storage में stream करता है। यह हर 16MB पर या हर 10 सेकंड में batch किया जाता है
    • 10 सेकंड की window के भीतर durability सुनिश्चित करने के लिए, write commit होते ही नज़दीकी data center की पाँच replicas को भेजी जाती है, और तीन के acknowledge करते ही write को स्वीकार कर लिया जाता है

  • JavaScript API डिज़ाइन

    • इसे asynchronous के बजाय blocking तरीके से डिज़ाइन किया गया है। इसका उद्देश्य तेज़ single-threaded persistence operations देना है
    • इसमें ऐसा उदाहरण शामिल है जो जानबूझकर N+1 query pattern दिखाता है, जिसे SQLite अच्छी तरह संभाल सकता है

  • Storage Relay Service

    • यह Durable Objects के पीछे का आधारभूत system है, और Cloudflare के मौजूदा D1 SQLite system को एक साल से अधिक समय से support दे रहा है

  • Durable Objects कहाँ बनाए जाते हैं

    • Durable Objects बन जाने के बाद अपनी location नहीं बदलते। डिफ़ॉल्ट रूप से, इन्हें उस data center में instantiate किया जाता है जहाँ शुरुआती get() request की जाती है
    • किसी दूसरी location पर Durable Objects को manually बनाने के लिए get() में वैकल्पिक locationHint parameter दिया जाता है

  • where.durableobjects.live साइट

    • यह Cloudflare network में DO कहाँ बनाए जाते हैं, इसे track करने वाली साइट है

GN⁺ की संक्षिप्त समीक्षा

  • Cloudflare के Durable Objects, SQLite पर आधारित होकर बड़े पैमाने के application design के लिए नई संभावनाएँ पेश करते हैं। यह data और application logic को एक ही physical host पर रखकर तेज़ performance देते हैं
  • यह system खास तौर पर real-time collaborative applications के लिए उपयोगी है और state की अलग-अलग units को संभालने की flexibility देता है
  • Durable Objects, data durability सुनिश्चित करने के लिए कई data centers में replicas बनाते हैं, जिससे stability और reliability बढ़ती है
  • यह तकनीक बड़े distributed systems design में रुचि रखने वाले developers के लिए दिलचस्प हो सकती है। इसी तरह की क्षमताएँ देने वाले systems में Amazon का DynamoDB और Google का Firestore शामिल हैं

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

1 टिप्पणियां

 
GN⁺ 2024-10-15
Hacker News टिप्पणियाँ

  • write API synchronous है, लेकिन इसमें छिपी हुई asynchronous wait capability है। अगर write fail हो जाए, तो runtime response को HTTP failure से बदल देता है, जिससे writes को अपने-आप batch करके success मान लेना संभव हो जाता है

    • read transaction नहीं है, इसलिए किसी खास समय का snapshot पाना मुश्किल है
    • हर runtime instance 128MB RAM तक सीमित है
    • WebSockets hibernate हो सकते हैं, और इस दौरान कोई cost नहीं आती। इससे client DO के सोए होने पर भी connection बनाए रख सकता है
    • automatic RPC feature है, जिससे दूसरे DO या worker से सामान्य JS call की तरह communicate किया जा सकता है। serialization और parsing runtime संभालता है

  • हर DO WAL entry की sequence को object storage में stream करता है, और यह हर 16MB या 10 सेकंड पर batch होती है

    • globally write-to-read में 10 सेकंड लग सकते हैं
    • regionally placed database cluster को replace करना मुश्किल है

  • Durable Object design पसंद है। इसका आंतरिक कामकाज समझना आसान है

    • DO तेज़ और कम लागत वाले real-time experience बनाने के लिए अच्छा है, लेकिन analytics और overview तैयार करना मुश्किल है
    • SQLite में data डालने पर कई छोटे SQLite instances को query करके result merge करना पड़ता है

  • Durable Objects की physical location कहाँ होती है, यह समझना मुश्किल है

    • जिज्ञासा है कि क्या यह API call होने वाले region में स्थित होता है
    • जिज्ञासा है कि क्या DO अपने-आप किसी दूसरी location पर move कर सकता है

  • नई cloud technologies को समझना मुश्किल है

    • 15 साल से ज़्यादा web development experience होने के बावजूद लगता है कि ये technologies अपने लिए सही नहीं हैं

  • schema migration को कैसे handle किया जाएगा, यह जानने की जिज्ञासा है

    • अगर database tenant के हिसाब से मौजूद है, तो schema change को हर DO पर apply करना मुश्किल है

  • DO design दिलचस्प है, लेकिन लगता है कि यह सिर्फ high-load system या toy project के लिए ही उपयुक्त है

    • production में proven system चाहिए, और DO अभी mature नहीं है

  • DO design से प्रभावित हूँ। complex work को छोटे scale पर handle करने का इसका तरीका असली product structure जैसा लगता है

  • ध्यान गया कि CF developers को DO इस्तेमाल करने के लिए encourage कर रहा है

    • worker का WebSocket connection 30 सेकंड बाद timeout हो जाता है, और DO इस्तेमाल करने की सिफारिश की जाती है

  • जिज्ञासा है कि क्या DO MVC architecture के "model" के बराबर है

    • tenant के हिसाब से DO इस्तेमाल करने, और सभी DO को query या join करने के तरीके को लेकर जिज्ञासा है