वितरित SQLite: प्रतिमान बदलाव या बढ़ा-चढ़ाकर किया गया प्रचार?

• SQLite बहुत तेज़ है। एक सामान्य single ~40€/m सर्वर पर यह एक साथ ~168,000 reads और ~8000 writes को लगातार संभाल सकता है
• क्योंकि यह embedded systems, phones, desktop applications जैसी client-side applications के लिए डिज़ाइन की गई एक embedded library है, SQLite database को application server के साथ ही मौजूद होना चाहिए और इसे network के ज़रिए access नहीं किया जा सकता
• ऐसी स्थिति में SQLite का उपयोग जहाँ एक से अधिक machines चाहिए हों?
  • कोई weekend project अचानक बहुत लोकप्रिय हो सकता है और उसे तेज़ी से scale करना पड़ सकता है
  • CTO की requirements में से एक यह हो सकती है कि कम-से-कम 2 अलग-अलग data centers में high-availability service deploy की जाए
• पिछले कुछ वर्षों में SQLite को backend applications के लिए backend database के रूप में ढालने की कोशिश करने वाले कुछ projects सामने आए हैं
• यह लेख देखता है कि क्या यह ऐसा paradigm shift है जो organizations को बेहतर user experience तेज़ी से देने में सक्षम बनाता है, या फिर यह उन companies की marketing hype है जो अपने "Unique Selling Proposition" को बढ़ा-चढ़ाकर पेश कर रही हैं

SQLite का edge database के रूप में उपयोग

• SQLite को सिर्फ़ एक साधारण backend database नहीं, बल्कि edge database के रूप में प्रचारित किया जा रहा है
• इसके सबसे प्रमुख players हैं Cloudflare D1, LiteFS का उपयोग करने वाला fly.io, और Turso
• ज़्यादातर SQLite derivatives लगभग एक जैसे ढंग से काम करते हैं
  • कहीं एक primary database होता है जो writes स्वीकार करता है, और उसे दूसरे regions में asynchronously replicate किया जाता है
  • replication आम तौर पर database पर चलाए गए सभी transactions के log, यानी SQLite के Write-Ahead Log, को stream करके की जाती है
  • इस architecture में सैद्धांतिक रूप से reads को edge data centers से serve किया जा सकता है, लेकिन writes को अब भी एक central location तक भेजना पड़ता है
• व्यवहार में आप नहीं चाहेंगे कि किसी e-commerce application में customer order complete कर दे, primary SQLite database में order approve भी हो जाए, लेकिन local read replica पीछे होने के कारण updated data अभी तक न पाए और "not found" error message दिखाए
• "दर्दनाक Eventual Consistency की दुनिया" में आपका स्वागत है

LiteFS का समाधान और उसकी सीमाएँ

• LiteFS एक तरह का hack जैसा समाधान देता है। application __txid cookie set करती है ताकि local replica के पास मौजूद आख़िरी transaction को track किया जा सके, और अगर replica बहुत पुराना हो तो read query को primary database तक forward कर दिया जाए।
• अब application database और reverse proxy के साथ काफ़ी क़रीबी रूप से जुड़ जाती है
• LiteFS यह नहीं बताता कि यह लगभग 100 writes per second ही support करता है

अधिकांश वितरित SQLite systems की मुख्य कमियाँ

• अधिकांश distributed SQLite systems interactive transactions को support नहीं करते, जहाँ transaction के अलग-अलग queries के बीच कुछ computation की जाती है
• एक समय में केवल एक write transaction ही active हो सकता है। सामान्य SQLite database में यह आम तौर पर ठीक है क्योंकि अधिकांश writes कुछ दर्जन microseconds से ज़्यादा नहीं चलतीं
• लेकिन application और SQLite database के बीच network latency जोड़ते ही system टूटने लगता है। database transaction के round-trip time तक locked रहेगा और writes प्रति सेकंड कुछ ही बार तक सीमित हो जाएँगी
• Turso इसे batch के ज़रिए "हल" करता है। कई queries को एक batch में बाँधकर एक single transaction के रूप में चलाया जा सकता है। Cloudflare D1 इस समस्या को batches और stored procedures से "हल" करता है

अगर कोई और सरल समाधान हो तो?

• web applications को दुनिया भर में बहुत तेज़ बनाने का एक बहुत सरल और शक्तिशाली तरीका पहले से मौजूद है: Cache-Control और ETag headers का उपयोग करने वाला HTTP caching
• HTTP caching का उपयोग करने पर weak consistency databases जैसी तकनीकों की ज़रूरत नहीं पड़ती, जिससे web applications बहुत ज़्यादा complex होने या race conditions के प्रति कमज़ोर होने से बचती हैं
• इस लेख के लेखक अपनी नई किताब "Cloudflare for Speed and Security" में काफ़ी समय यह समझाने में लगाते हैं कि अलग-अलग caching strategies किस तरह web applications को तेज़ बनाने के साथ-साथ बहुत कम resources में बड़ी संख्या में concurrent users को संभालने लायक बनाती हैं

abstraction के रूप में database

• latency ही वह एकमात्र समस्या नहीं थी जिसे distributed SQLite हल करने की कोशिश कर रहा था। दूसरी समस्या operational complexity है
• network से जुड़े server clusters को manage करना मुश्किल है और अक्सर downtime तथा revenue loss का कारण बनता है। database management की बात तो अलग है, जिसमें लगातार देखरेख और मज़बूत security culture चाहिए ताकि 2017 में GitLab के साथ हुई आपदा जैसी घटनाओं से बचा जा सके
• इसलिए विचार यह है कि database को application के साथ bundle कर दिया जाए और सब कुछ एक single server पर रखा जाए
• एक ही developer हो तो यह अच्छा लगता है, लेकिन बड़े organizations में आम तौर पर database servers के maintenance के लिए अलग लोग या team होती है
• यही वजह है कि embedded library की जगह socket के ज़रिए access किया जाने वाला database वास्तव में एक बेहतरीन abstraction है, क्योंकि यह सिर्फ़ technical abstraction नहीं बल्कि organizational abstraction भी है। development के दौरान यह developer machine पर चलने वाला एक साधारण container हो सकता है, लेकिन production में यह application वाले उसी server पर चलने वाले container से लेकर network पर access होने वाले distributed cluster तक कुछ भी हो सकता है। developer को सिर्फ़ एक configuration variable DATABASE_URL बदलना पड़ता है और बाक़ी सब operations team संभाल लेती है
• इसके उलट पारंपरिक Unix file system distributed computing के लिए उपयुक्त abstraction नहीं था। बेशक NFS (Network File System) मौजूद है, लेकिन Unix file system single-machine access के लिए डिज़ाइन होने के कारण इसका performance काफ़ी खराब रहता है। दूसरी ओर S3 protocol बड़ी मात्रा में unstructured data को efficient, scalable और reliable तरीके से store करने के लिए काफ़ी अच्छा abstraction है। developer बस S3-compatible SDK इस्तेमाल करता है और आगे की चिंता छोड़ देता है, जबकि operations team या cloud provider performance, durability, reliability जैसी सारी चीज़ें संभाल लेते हैं

निष्कर्ष

• SQLite वाकई एक शानदार database है, लेकिन अधिकांश teams के लिए SQLite से बचना और उसकी जगह PostgreSQL चुनना बेहतर होगा
• PostgreSQL को सर्वश्रेष्ठ backend database बनाने में असंख्य engineering hours लगाए गए हैं। SQLite चुनने पर आपको अनिवार्य रूप से उन चीज़ों को नाज़ुक और bug-prone तरीक़े से फिर से बनाना पड़ेगा जो PostgreSQL के पास लंबे समय से मौजूद हैं
• अभी SQLite को backend database बनाने की जो हलचल है, लेखक उसे edge computing infrastructure बेचने वाली companies की marketing coup भर मानता है, जिन्होंने यह समझ लिया है कि computing data storage के बिना कुछ नहीं है। इनके लिए उसकी (बिना माँगी) सलाह है कि CDN बनाने और applications पर complexity थोपने के बजाय HTTP caching में निवेश करें। इससे कहीं बेहतर नतीजे मिलते हैं
• पैदा की गई complexity की वजह से backend applications के 99.9% को edge पर ले जाने से कोई फ़ायदा नहीं मिलेगा, और उन्हें इसके बजाय दुनिया भर में 100ms से कम का शानदार अनुभव देने के लिए अच्छी caching strategies deploy करने पर ध्यान देना चाहिए
• और server-side applications के लिए SQLite के प्रयोग यहीं समाप्त होते हैं। यह PostgreSQL की जीत है

• "शौकिया लोग tactics पर चर्चा करते हैं, professionals logistics पर। (Amateurs discuss tactics. Professionals discuss logistics.)"
  सफलता के लिए मैदान में लिए गए tactical decisions से ज़्यादा महत्वपूर्ण वे supporting systems और processes होते हैं जो उन निर्णयों को संभव बनाते हैं, यानी logistics और management

GN⁺ की राय

• लेखक के तर्क के अनुसार अधिकांश backend applications में SQLite का उपयोग केवल complexity बढ़ाता है और कोई ठोस लाभ नहीं देता। PostgreSQL जैसे पहले से proven और mature database का उपयोग करना बेहतर विकल्प होगा
• edge computing infrastructure कंपनियों द्वारा SQLite को आगे बढ़ाना तकनीकी लाभ से अधिक marketing strategy का हिस्सा लगता है। यदि वे HTTP caching और CDN में अधिक निवेश करें तो यह application developers के लिए अधिक उपयोगी होगा
• अधिकांश backend applications केवल उपयुक्त caching strategy से ही काफ़ी तेज़ और scalable services दे सकती हैं। जब तक edge computing वास्तव में आवश्यक न हो, अनावश्यक complexity से बचना बेहतर है
• distributed SQLite कुछ विशेष use cases में उपयोगी हो सकता है, लेकिन इसे एक general-purpose solution की तरह इस्तेमाल करने में अभी सीमाएँ दिखती हैं। development convenience, performance और consistency—सभी को एक साथ संतुष्ट करना आसान नहीं होगा
• अंततः सबसे महत्वपूर्ण बात यह है कि application की requirements और team की capabilities के अनुरूप technology चुनी जाए। चलन के पीछे भागने के बजाय उसके फायदे-नुकसान का गहराई से विश्लेषण करके सावधानी से निर्णय लेना चाहिए
• लेखक इस बात पर ज़ोर देता है कि backend database के रूप में SQLite में अभी कई कमियाँ हैं, लेकिन ऐसे दूसरे use cases हो सकते हैं जहाँ SQLite की खूबियाँ काम आएँ, इसलिए इसे पूरी तरह नज़रअंदाज़ करना भी उचित नहीं होगा

[aer0700]

Postgres और sqlite में कौन सा सबसे बेहतर है, इस पर सोचने से ज़्यादा,
यह सोचना बेहतर नहीं होगा कि इन दोनों में से मेरी स्थिति के लिए कौन ज़्यादा उपयुक्त है?
क्योंकि हालात के मुताबिक सबसे अच्छा विकल्प बदल सकता है।

[GN⁺]

Hacker News राय

• LiteFS के लेखक के अनुसार, distributed SQLite डेवलपर्स के लिए paradigm shift या बढ़ा-चढ़ाकर किया गया प्रचार नहीं, बल्कि एक विस्तार या "अगला कदम" माना जा सकता है
  • यह SQLite की horizontal scalability को लेकर चिंताओं को संबोधित करता है
• distributed SQLite के जरिए अपेक्षित paradigm shift के user devices की ओर जाने की संभावना है
  • यह local-first apps को संभव बनाता है, जिससे तेज़ UI interaction और synchronization के माध्यम से eventual consistency मिलती है
• production environment में LiteFS का उपयोग करने पर database queries को तुरंत हल किया जा सकता है, जिससे web apps में loading state हटाई जा सकती है और तेज़ load time संभव होता है
• self-hosting के लिए सरल और distributed open source storage solution की आवश्यकता है
  • Ceph, SeaweedFS, MinIO जैसी मौजूदा solutions के साथ चुनौतियाँ और जटिलता जुड़ी हुई हैं
• LiteFS का विचार read-heavy applications के लिए network n-tier architecture को बदलकर SQLite के performance benefits का उपयोग करना है
  • यह हर application के लिए पूरी तरह उपयुक्त नहीं भी हो सकता
• लेख का यह दावा कि SQLite का उपयोग केवल "कुछ milliseconds बचाएगा", कम करके आँकना माना गया है
  • applications को users के और करीब चलाने से query latency काफ़ी कम हो सकती है
• SQLite और PostgreSQL के use cases और फायदे अलग-अलग हैं
  • यह दोनों के बीच सीधी प्रतिस्पर्धा नहीं है
• लेख के इस दावे पर सवाल उठाया गया है कि PostgreSQL सबसे बेहतरीन backend database है और SQLite का उपयोग करने से फीचर्स को कमज़ोर तरीके से फिर से बनाना पड़ेगा
  • इसी तरह के दावे दूसरे databases के बारे में भी किए जा सकते हैं
• हर user के लिए अलग database बनाकर SQLite को shard करना एक संभावित तरीका है
  • हालांकि, इसके लिए यह ज़रूरी है कि users को एक-दूसरे के data के साथ interaction करने की आवश्यकता न हो