Upstash ने अपने AWS लैम्ब्डा कार्यों के लिए सबसे अच्छा डेटाबेस विकल्प बनने के मिशन के साथ अपनी यात्रा शुरू की। इस बीच, हमने आपके सर्वर रहित कार्यों को बनाने के लिए एक और बढ़िया विकल्प खोजा:क्लाउडफ्लेयर वर्कर्स। यह एक रोमांचक उत्पाद है क्योंकि यह कम लागत के साथ पूरी दुनिया में बेहतर विलंबता का वादा करता है और कोई ठंड शुरू नहीं होती है। लेकिन AWS लैम्ब्डा की तुलना में इसकी कई सीमाएँ हैं। अतिरिक्त सीमाएँ डेटाबेस विकल्पों की सूची को छोटा बनाती हैं। हमने इसे इस प्रश्न के लिए Upstash को एक बेहतरीन समाधान के रूप में पेश करने के अवसर के रूप में देखा:CF Workers are stateless. Where should I keep my data then?
चुनौतियां
पहुंच-योग्यता
क्लाउडफ्लेयर वर्कर्स एक अधिक बंद वातावरण है। यह एडब्ल्यूएस की तरह नहीं है। आप अपना खुद का डेटाबेस उसी क्षेत्र में स्थापित नहीं कर सकते हैं और इसे वीपीसी के माध्यम से एक्सेस नहीं कर सकते हैं। इसलिए आपको अपने डेटाबेस को वर्कर्स फंक्शन से एक्सेस करने की आवश्यकता है। क्लाउडफ्लेयर वर्कर्स रनटाइम के रूप में V8 आइसोलेट्स का उपयोग करते हैं। यह टीसीपी कनेक्शन की अनुमति नहीं देता है। तो डेटाबेस HTTP के माध्यम से सुलभ होना चाहिए।
वैश्विक प्रतिकृति
श्रमिकों को हर जगह तैनात होने का फायदा है। जबकि आपका कार्य दुनिया भर से कम विलंबता के साथ सुलभ है; आपको अपने डेटाबेस तक पहुंचने के लिए सैकड़ों मिलीसेकंड खर्च नहीं करना चाहिए। आपका डेटाबेस उस जगह के करीब होना चाहिए जहां आपका फ़ंक्शन निष्पादित होता है। यह आपके डेटा को कई क्षेत्रों और महाद्वीपों में दोहराने से संभव है।
कम लेटेंसी
डेवलपर्स एज कंप्यूटिंग समाधान पसंद करते हैं क्योंकि वे हर जगह कम विलंबता प्रदान करते हैं। डेटाबेस एक अड़चन नहीं होना चाहिए। रेडिस जैसे इन-मेमोरी डेटाबेस सब-मिलीसेकंड लेटेंसी प्रदान करते हैं।
उपस्टैश की यात्रा
REST API
हमने देशी Redis API सपोर्ट के साथ Upstash को लॉन्च किया। सभी रेडिस क्लाइंट समर्थित हैं, यह लीगेसी रेडिस अनुप्रयोगों के लिए एकदम सही है। लेकिन जल्द ही हमने उपयोगकर्ताओं को सर्वर रहित कार्यों पर कनेक्शन की समस्या देखना शुरू कर दिया। साथ ही यह क्लाउडफ्लेयर वर्कर्स से उपलब्ध नहीं था। इसलिए हमने सबसे पहले GraphQL API लागू किया। लेकिन हम ग्राफ़क्यूएल एपीआई से खुश नहीं थे, क्योंकि प्रॉक्सी परत के कारण प्रदर्शन ओवरहेड था। रेडिस कमांड चलाने के लिए ग्राफक्यूएल भी सबसे आसान तरीका नहीं था। हमने प्रदर्शन ओवरहेड को कम करने के लिए डेटाबेस इंजन के अंदर एक आरईएसटी सर्वर बनाने का फैसला किया। हमें लगता है कि आरईएसटी रेडिस के लिए बेहतर फिट है। हमने REST API लॉन्च किया और देखा कि यह उन डेवलपर्स के बीच काफी लोकप्रिय है जो Cloudflare Works और Webassembly से Redis को एक्सेस करना चाहते हैं।
एज कैशिंग
आरईएसटी एपीआई के लिए धन्यवाद, अपस्टैश श्रमिकों से सुलभ था लेकिन विलंबता आदर्श नहीं थी। कुछ डेवलपर्स ने रेडिस प्रतिक्रियाओं को कैश करने के लिए क्लाउडफ्लेयर के अपने कैशिंग का उपयोग करने का प्रयास किया। लेकिन यह एक जटिल समाधान था। Redis पहले से ही बहुत तेज़ होना चाहिए, इसलिए cache Redis . को अच्छा नहीं लगता कहीं और। इसलिए हमने एज कैशिंग बनाने का फैसला किया जहां हम सभी किनारे के स्थानों पर रेडिस आरईएसटी प्रतिक्रिया को कैश करते हैं। हमने रेडिस प्रतिक्रियाओं को कैश करने के लिए सीडीएन प्रदाताओं का उपयोग किया। यह एज लेटेंसीज में काफी सुधार था, 80% तक प्रदर्शन लाभ।
वैश्विक डेटाबेस
एज कैशिंग वैश्विक विलंबता समस्या का एक अच्छा समाधान था लेकिन कुछ उपयोग के मामलों में इसकी कुछ कमियां हैं। सबसे पहले, यह कैश अमान्यता (पर्ज) का समर्थन नहीं करता है। यदि कैश का समाप्ति समय 30 सेकंड है; फिर 30 सेकंड की एक विंडो है जहां आपके ग्राहक पुराने डेटा को पढ़ सकते हैं। यह कई वेब उपयोग मामलों द्वारा सहन किया जा सकता है लेकिन सभी नहीं। दूसरे, एज कैशिंग केवल REST API के लिए समर्थित है। रेडिस क्लाइंट एज कैशिंग से लाभ नहीं उठा सकते हैं। इसलिए हमने एक नया डेटाबेस प्रकार डिजाइन करने का फैसला किया जो डेटा को कई क्षेत्रों में दोहराता है। इसे अत्यधिक उपलब्ध और पर्याप्त रूप से सुसंगत बनाने के लिए इसे डिजाइन करना बहुत चुनौतीपूर्ण था। वर्तमान में Upstash के पास एक वैश्विक डेटाबेस पेशकश है जो आपके डेटा को 5 अलग-अलग AWS क्षेत्रों (पूर्वी और पश्चिम उत्तरी अमेरिका, यूरोप, एशिया, दक्षिण अमेरिका) में दोहराता है। ग्लोबल डेटाबेस कैश नहीं है इसलिए इसमें कैशे-अमान्य समस्या नहीं है। सभी प्रतिकृतियों के लिए लेखन को तुरंत दोहराया जाता है। प्रदर्शन और उपलब्धता के लिए, वैश्विक डेटाबेस को अंततः संगत होने के लिए डिज़ाइन किया गया है।
एज कैशिंग बनाम ग्लोबल डेटाबेस (या दोनों)
अगर आपको अपने एज सॉल्यूशन के लिए सिर्फ कैश की जरूरत है तो एज कैशिंग एक अच्छा सॉल्यूशन हो सकता है। लेकिन अगर आपको कैश को तुरंत अमान्य करने के लिए अपने लेखन की आवश्यकता है, तो आपको ग्लोबल डेटाबेस को प्राथमिकता देनी चाहिए। कैशिंग के अलावा, वैश्विक डेटाबेस का उपयोग अत्यधिक उपलब्ध वैश्विक डेटास्टोर के रूप में किया जा सकता है। यह भी ध्यान रखें कि एज कैशिंग केवल REST कॉल के लिए उपलब्ध है। यदि आप रेडिस क्लाइंट का उपयोग कर रहे हैं, तो ग्लोबल डेटाबेस एकमात्र विकल्प है जिसमें कम विलंबता किनारे पर है।
एज कैशिंग और ग्लोबल डेटाबेस दोनों को रीड लेटेंसी को कम करने के लिए डिज़ाइन किया गया है। यदि आपका उपयोग मामला 90% लिखना है तो एक एकल क्षेत्र सेटअप अधिक समझ में आएगा। राइट्स में मल्टी और सिंगल रीजन डेटाबेस दोनों के लिए समान लेटेंसी है, लेकिन ग्लोबल सेट अप में वे 5 गुना अधिक महंगे हैं।
जब एज कैशिंग सक्षम होती है, तो अपस्टैश मूल से पहला अनुरोध प्राप्त करता है और फिर किनारे पर कैश करता है। यदि मूल निकट नहीं है, तो विलंबता अधिक होगी। यदि आप सभी मामलों के लिए सर्वश्रेष्ठ विलंबता चाहते हैं; आप एक वैश्विक डेटाबेस पर एज कैशिंग को सक्षम करके दोनों का उपयोग कर सकते हैं।
बेंचमार्क एप्लिकेशन देखें जो एज कैशिंग और वैश्विक डेटाबेस की विलंबता की तुलना करता है।
आगे क्या है?
यहाँ कुछ चीज़ें हैं जिन पर हम Upstash at Edge को बेहतर बनाने के लिए काम कर सकते हैं:
- लिखने के लिए कम विलंबता:वर्तमान में, वैश्विक डेटाबेस को एकल लीडर आर्किटेक्चर के साथ पठन विलंबता को अनुकूलित करने के लिए डिज़ाइन किया गया है। हमें लगता है कि इसमें अधिकांश उपयोग के मामले शामिल हैं। लेकिन आपकी प्रतिक्रिया और नए उपयोग के मामलों के आधार पर हम एक आर्किटेक्चर पर काम कर सकते हैं जो कम विलंबता लिखने के साथ-साथ पढ़ता है।
- काफ्का समर्थन:हम आने वाले हफ्तों में रेडिस के अलावा काफ्का को भी लॉन्च करने की योजना बना रहे हैं। काफ्का किनारे पर नए उपयोग के मामलों को सक्षम करेगा जैसे कि क्लिकस्ट्रीम विश्लेषण या सर्वर रहित/किनारे कार्यों से लॉग को कफका में धकेलना।
हम आपके फ़ीडबैक द्वारा निर्देशित Upstash को सुधारना और विकसित करना जारी रखते हैं। हमें Twitter या Discord पर अपने विचार बताएं।