सर्वरलेस का भ्रम
- Serverless क्लाउड तकनीक का एक प्रमुख ट्रेंड बन चुका है।
- यह डेवलपर्स को सिर्फ बिज़नेस लॉजिक पर फोकस करने देता है, बिना सर्वर मैनेजमेंट का बोझ उठाए।
- पेमेंट मॉडल: केवल उपयोग के अनुसार भुगतान करें, और ऑपरेशनल ओवरहेड लगभग शून्य के करीब रहता है।
- कई serverless डेटाबेस अब मार्केट में हैं; Elastic, Confluent, Pinecone जैसे पुराने लीडर्स और Neon, WarpStream, Upstash, Turbopuffer जैसे नए challengers प्रतिस्पर्धा कर रहे हैं।
मौजूदा serverless डेटाबेस की समस्याएँ
- कई serverless डेटाबेस वास्तव में serverless नहीं हैं।
- ज्यादातर सेवाएँ cloud-native architecture पर आधारित हैं, जो server-pool युग के लिए एक नवाचारी डिज़ाइन है।
- ये सर्वर क्लस्टर चलाती हैं और जटिल software तथा मानव हस्तक्षेप के जरिए लोड अनुमानित कर capacity का प्रबंधन करती हैं।
- यही भ्रम उपयोगकर्ताओं के लिए वास्तविक समस्या बन जाता है।
अप्रभावी आर्किटेक्चर का असर
- आर्किटेक्चर mismatch सिर्फ तकनीकी विवरण नहीं, बल्कि यूज़र्स के लिए वास्तविक समस्या बनता है।
- उपयोगकर्ता निष्क्रिय सर्वरों के खर्च का भुगतान करते हैं, क्योंकि सर्वर क्लस्टर हमेशा अलग-अलग उद्देश्यों के लिए रन होते रहते हैं।
- स्केलेबिलिटी issue: नए सर्वर को क्लस्टर में जोड़ने में कुछ मिनट लगते हैं, यानी तुरंत ट्रैफिक surge संभालना संभव नहीं होता।
- सीमित विकल्प: प्रत्येक क्लाउड क्षेत्र के लिए इन्फ्रास्ट्रक्चर मैनेजमेंट की जरूरत होने के कारण उपयोगकर्ता सेवा क्षेत्र चुनने में सीमित हो जाते हैं।
अस्थायी/असतत मॉडल
- server-pool architecture पर आधारित “serverless” डेटाबेस टिकाऊ नहीं हैं।
- प्रदाता को सर्वर क्लस्टर चलाने के लिए पर्याप्त निवेश की जरूरत होती है, जिससे pricing बदल सकती है।
- लाइटवेट यूज़र्स सिस्टम को सपोर्ट करने के लिए अतिरिक्त शुल्क चुकाते हैं और सफल उपयोगकर्ता अनपेक्षित कीमत वृद्धि का सामना करते हैं।
serverless-native आर्किटेक्चर की जरूरत
- क्लाउड कंप्यूटिंग के शुरुआती दौर में अधिकांश “cloud” डेटाबेस legacy डेटाबेस थे।
- serverless-native architecture इन्फ्रास्ट्रक्चर मैनेजमेंट का हर काम क्लाउड प्रदाता को सौंपती है और सर्वर क्लस्टर की जगह stateless functions तथा serverless सेवाओं का उपयोग करती है।
- यह तरीका cloud infrastructure को single large supercomputer की तरह लेकर immediate scalability और वास्तविक pay-per-request मॉडल को संभव बनाता है।
- लिटमस टेस्ट: जाँचने के लिए कि डेटाबेस सचमुच serverless-native है या नहीं, देखना चाहिए कि क्या उसे बिना Kubernetes cluster या VM provision किए सीधे क्लाउड खाते पर deploy किया जा सकता है।
LambdaDB का परिचय
- LambdaDB एक नया search engine है, जिसे serverless-native तरीके से बनाया गया है।
- यह सिस्टम serverless capabilities और resources का सेट बनकर चलता है, और database logic तथा infra को पूरी तरह अलग करता है।
- यूज़र रिक्वेस्ट रीज़नल गेटवे से गुजरती हैं और रिक्वेस्ट प्रकार के अनुसार Control Functions या Data Functions में route की जाती हैं।
- एंटरप्राइज फीचर्स: LambdaDB point-in-time restore और zero-copy cloning जैसी सुविधाएँ देता है, बिना किसी infrastructure management की जरूरत के।
LambdaDB कैसे काम करता है
- LambdaDB architecture: सभी घटक serverless क्लाउड सेवाओं से बने हैं।
- गेटवे प्रत्येक यूज़र रिक्वेस्ट के API key को validate करता है और उसे control function या data function की तरफ route करता है।
- Control functions CRUD operations और data-management requests को हैंडल करती हैं, जबकि data functions वास्तविक डेटा write/read करती हैं।
- Write path: Writer Function रिक्वेस्ट को record करती है, फिर इसे durable serverless write buffer में लिखकर client को response भेजती है।
खर्च का विरोधाभास
- LambdaDB server-pool डेटाबेस की तुलना में compute खर्च कम करता है।
- Lambda का प्रति-इकाई मूल्य EC2 instance से अधिक है, लेकिन उच्च उपलब्धता और fault tolerance सुनिश्चित करने के लिए आवश्यक redundancy के कारण कुल खर्च घटता है।
- फिक्स्ड capacity का waste: कंपनियों की औसत compute उपयोगिता सिर्फ 10-20% होती है, इसलिए serverless computing से 50-90% तक बचत संभव है।
प्रदर्शन और स्केलेबिलिटी
- Performance और scalability: LambdaDB ने 960-डायमेंशनल vectors से सैकड़ों मिलियन vectors जोड़ने के प्रयोग में अपनी performance साबित की।
- Write latency: प्रति सेकंड 10 upserts पर median latency 43ms रही, और ट्रैफिक 100x बढ़ने पर भी latency लगभग समान रही।
- Query latency: विविध लोड पर query latency स्थिर रही; 99वें percentile में यह 172ms से 210ms के बीच थी।
- Optimization efforts: query function की latency सुधारने के लिए लगातार optimization की जा रही है, और serverless infrastructure भी बेहतर हो रही है।
ग्राहकों के लिए लाभ
- Cost saving: LambdaDB में idle server नहीं होने के कारण यह 10x से भी अधिक सस्ता है।
- तत्काल और लगभग अनंत scalability: LambdaDB milliseconds में हजारों parallel functions तक scale कर सकता है।
- सरल शुरुआत और scale: मजबूत AI applications बनाना संभव है, और जैसे-जैसे business grow करता है, architecture अभी भी सरल और cost-efficient रहता है।
- एंटरप्राइज फीचर्स: point-in-time restore और zero-copy cloning जैसी सुविधाएँ उपलब्ध हैं, बिना अतिरिक्त complexity या खर्च के।
भविष्य की योजनाएँ और विजन
- LambdaDB पहले ही रोज़ाना सैकड़ों मिलियन requests को करोड़ों दस्तावेज़ों पर प्रोसेस कर रहा है।
- लॉन्ग-टर्म roadmap: रिलेशनल डेटा, streams, key-value, graph आदि अन्य data models को सपोर्ट करने की योजना है।
5 टिप्पणियां
संकल्पना अच्छी है, लेकिन क्वेरी लेटेंसी कम करने के लिए
stateकी जरूरत अनिवार्य रूप से पड़ती है। MySQL और PostgreSQL से तुलना करने पर क्वेरी लेटेंसी लगभग 100 गुना ज्यादा लगती है। यह लगभग वैसा लगता है जैसे फाइल सिस्टम में इनपुट और आउटपुट हो रहा हो।अच्छा सुझाव देने के लिए धन्यवाद। आपने जो कहा कि “लेटेंसी कम करने के लिए state की ज़रूरत होती है”, वह हमारे architecture के एक प्रमुख trade-off को बिल्कुल सही ढंग से पकड़ लिया।
सबसे पहले query latency की बात करूँ तो, हमारे benchmark में p99 (99th percentile) लगभग 130-210ms के स्तर पर होता है। शायद आपने जो 100x फर्क का ज़िक्र किया, वह पोस्ट में बताए गए “cold start में कई सेकंड लग सकते हैं” वाले सबसे खराब (worst-case) केस को देखकर कहा है। जैसा आपने इंगित किया, यह निश्चित ही हमारे architecture की कमजोरी है, और जैसा पोस्ट में उल्लेखित है, production में यह 0.01% से कम (P99.99) पर होता है। बाकी ज्यादातर queries प्रत्येक lambda के local memory और disk को cache की तरह इस्तेमाल करके स्थिर performance देने के लिए design की गई हैं।
इसलिए जैसा आपने कहा, सभी queries के 10ms से नीचे गारंटी होनी जरूरी हो ऐसे ultra-low-latency वित्तीय ट्रेडिंग सिस्टम जैसे मामलों में यह architecture शायद उपयुक्त नहीं हो। लेकिन अधिकांश AI-आधारित search और recommendation applications में P99 के हिसाब से 100-200ms latency पर्याप्त अच्छी performance मानी जा सकती है, और infrastructure खर्च तथा operational overhead को 90% से अधिक घटाने का फायदा इससे कहीं ज्यादा बड़ा है।
एक बार फिर से आपके thoughtful feedback के लिए धन्यवाद।
जैसा आपने कहा, यह सामान्य प्रयोजन वाले DB की बजाय कुछ खास स्थितियों में ‘सचमुच सर्वरलेस’ की तरह इस्तेमाल किया जा सकने वाला समाधान लगता है।
मुझे अंदाज़ा नहीं था कि जवाब कोरियन में आएगा! (मैंने शायद थोड़ा ज्यादा cynical होकर लिख दिया...)
सच कहूँ तो पहले मुझे लगा था कि यह एक breakthrough idea है। सच में, serverless DBs की सबसे बड़ी समस्या यह है कि कहीं न कहीं अंदर असली server रन कर रहा होता है। इसलिए जब traffic अचानक बढ़ता है, उस server के allocate होने तक सिस्टम फ्रीज़ हो जाता है (लगभग 5 मिनट तक)। इसी कारण मौजूद cloud (AWS आदि) की serverless DB को production level पर use करना मुश्किल हो जाता है।
मैंने सोचा था कि शायद बना कर देखूँ, लेकिन चिंता यह थी कि अगर mysql, postgresql आदि में पहले से मौजूद indexing, sorting जैसे binary logic वगैरह को फिर से implement करना पड़े, और उतनी ही reliable open source DB project को Lambda पर दोबारा बनाना कितना कठिन होगा—यही सोच रहा था।
चूँकि यह आपका सीधे बनाया हुआ product है, इसलिए मैं आपके काम में बहुत अच्छे development की उम्मीद करता हूँ~!
आपके अच्छे सुझाव के लिए धन्यवाद। जैसा आपने कहा, यह RDB उपयोग मामलों के लिए उपयुक्त नहीं है और इसे सर्च इंजन (Elasticsearch), vector DB (Pinecone) के पोज़िशन के रूप में समझा जाना चाहिए। आंतरिक रूप से भी इंडेक्सिंग, सॉर्टिंग और एग्रीगेशन जैसी सुविधाओं को सपोर्ट करने के लिए हमने लंबे समय से वेरिफ़ाइड Lucene का उपयोग किया है। धन्यवाद :)