अपने सर्वर रहित ऐप को प्रति सेकंड हजारों ऑपरेशनों या सैकड़ों-हजारों समवर्ती उपयोगकर्ताओं से आगे बढ़ाने के मार्गदर्शन के लिए इस दस्तावेज़ को पढ़ें। इस दस्तावेज़ में आपको सिस्टम को गहराई से समझने में मदद करने के लिए उन्नत विषय शामिल हैं। यदि आप अभी क्लाउड फायरस्टोर से शुरुआत कर रहे हैं, तो इसके बजाय क्विकस्टार्ट गाइड देखें।
क्लाउड फायरस्टोर और फायरबेस मोबाइल/वेब एसडीके सर्वर रहित ऐप्स विकसित करने के लिए एक शक्तिशाली मॉडल प्रदान करते हैं जहां क्लाइंट-साइड कोड सीधे डेटाबेस तक पहुंचता है। एसडीके ग्राहकों को वास्तविक समय में डेटा के अपडेट सुनने की सुविधा देता है। आप रिस्पॉन्सिव ऐप्स बनाने के लिए रीयल-टाइम अपडेट का उपयोग कर सकते हैं जिनके लिए सर्वर इंफ्रास्ट्रक्चर की आवश्यकता नहीं होती है। हालाँकि किसी चीज़ को तैयार करना और चलाना बहुत आसान है, यह क्लाउड फायरस्टोर को बनाने वाले सिस्टम में बाधाओं को समझने में मदद करता है ताकि ट्रैफ़िक बढ़ने पर आपका सर्वर रहित ऐप अच्छा प्रदर्शन कर सके।
अपने ऐप को स्केल करने की सलाह के लिए निम्नलिखित अनुभाग देखें।
अपने उपयोगकर्ताओं के निकट एक डेटाबेस स्थान चुनें
निम्नलिखित चित्र वास्तविक समय ऐप की वास्तुकला को प्रदर्शित करता है:
जब उपयोगकर्ता के डिवाइस (मोबाइल या वेब) पर चलने वाला कोई ऐप क्लाउड फायरस्टोर से कनेक्शन स्थापित करता है, तो कनेक्शन उसी क्षेत्र में क्लाउड फायरस्टोर फ्रंटएंड सर्वर पर रूट किया जाता है जहां आपका डेटाबेस स्थित है। उदाहरण के लिए, यदि आपका डेटाबेस us-east1 में है, तो कनेक्शन क्लाउड फायरस्टोर फ्रंटएंड के साथ-साथ us-east1 में भी चला जाता है। ये कनेक्शन लंबे समय तक चलते हैं और ऐप द्वारा स्पष्ट रूप से बंद किए जाने तक खुले रहते हैं। फ्रंटएंड अंतर्निहित क्लाउड फायरस्टोर स्टोरेज सिस्टम से डेटा पढ़ता है।
उपयोगकर्ता के भौतिक स्थान और क्लाउड फायरस्टोर डेटाबेस स्थान के बीच की दूरी उपयोगकर्ता द्वारा अनुभव की जाने वाली विलंबता को प्रभावित करती है। उदाहरण के लिए, भारत में एक उपयोगकर्ता जिसका ऐप उत्तरी अमेरिका में Google क्लाउड क्षेत्र में एक डेटाबेस से बात करता है, उसे अनुभव धीमा और ऐप कम तेज़ लग सकता है, अगर डेटाबेस इसके करीब स्थित हो, जैसे कि भारत में या एशिया के किसी अन्य हिस्से में। .
विश्वसनीयता के लिए डिज़ाइन
निम्नलिखित विषय आपके ऐप की विश्वसनीयता को सुधारते हैं या प्रभावित करते हैं:
ऑफ़लाइन मोड सक्षम करें
फायरबेस एसडीके ऑफ़लाइन डेटा दृढ़ता प्रदान करते हैं। यदि उपयोगकर्ता के डिवाइस पर ऐप क्लाउड फायरस्टोर से कनेक्ट नहीं हो पाता है, तो ऐप स्थानीय रूप से कैश्ड डेटा के साथ काम करके प्रयोग करने योग्य बना रहता है। यह तब भी डेटा एक्सेस सुनिश्चित करता है जब उपयोगकर्ता खराब इंटरनेट कनेक्शन का अनुभव करते हैं या कई घंटों या दिनों के लिए पूरी तरह से एक्सेस खो देते हैं। ऑफ़लाइन मोड पर अधिक विवरण के लिए, ऑफ़लाइन डेटा सक्षम करें देखें।
स्वचालित पुनर्प्रयासों को समझें
फायरबेस एसडीके पुन: प्रयास करने और टूटे हुए कनेक्शन को फिर से स्थापित करने का ध्यान रखता है। यह क्लाइंट और डेटाबेस के बीच सर्वर को पुनरारंभ करने या नेटवर्क समस्याओं के कारण होने वाली क्षणिक त्रुटियों को हल करने में मदद करता है।
क्षेत्रीय और बहु-क्षेत्रीय स्थानों में से चुनें
क्षेत्रीय और बहु-क्षेत्रीय स्थानों के बीच चयन करते समय कई विरोधाभास होते हैं। मुख्य अंतर यह है कि डेटा को कैसे दोहराया जाता है। यह आपके ऐप की उपलब्धता की गारंटी देता है। एक बहु-क्षेत्रीय उदाहरण मजबूत सेवा विश्वसनीयता प्रदान करता है और आपके डेटा की स्थायित्व बढ़ाता है लेकिन व्यापार-बंद लागत है।
वास्तविक समय क्वेरी प्रणाली को समझें
रीयल-टाइम क्वेरीज़, जिन्हें स्नैपशॉट श्रोता भी कहा जाता है, ऐप को डेटाबेस में परिवर्तनों को सुनने देती है और डेटा में परिवर्तन होते ही कम-विलंबता सूचनाएं प्राप्त करती है। एक ऐप समय-समय पर अपडेट के लिए डेटाबेस को पोल करके समान परिणाम प्राप्त कर सकता है, लेकिन यह अक्सर धीमा, अधिक महंगा होता है और अधिक कोड की आवश्यकता होती है। रीयल-टाइम क्वेरीज़ को कैसे सेट अप और उपयोग करें, इसके उदाहरणों के लिए, रीयल-टाइम अपडेट प्राप्त करें देखें। निम्नलिखित अनुभाग इस बात का विवरण देते हैं कि स्नैपशॉट श्रोता कैसे काम करते हैं और प्रदर्शन को बनाए रखते हुए वास्तविक समय के प्रश्नों को स्केल करने के लिए कुछ सर्वोत्तम प्रथाओं का वर्णन करते हैं।
दो उपयोगकर्ताओं की कल्पना करें जो मोबाइल एसडीके में से एक के साथ निर्मित मैसेजिंग ऐप के माध्यम से क्लाउड फायरस्टोर से जुड़ते हैं।
क्लाइंट ए chatroom नामक संग्रह में दस्तावेज़ जोड़ने और अद्यतन करने के लिए डेटाबेस में लिखता है:
collection chatroom:
document message1:
from: 'Sparky'
message: 'Welcome to Cloud Firestore!'
document message2:
from: 'Santa'
message: 'Presents are coming'
क्लाइंट बी स्नैपशॉट श्रोता का उपयोग करके उसी संग्रह में अपडेट सुनता है। जब भी कोई नया संदेश बनाता है तो क्लाइंट बी को तत्काल सूचना मिलती है। निम्नलिखित चित्र स्नैपशॉट श्रोता के पीछे की वास्तुकला को दर्शाता है:
जब क्लाइंट बी स्नैपशॉट श्रोता को डेटाबेस से जोड़ता है तो घटनाओं का निम्नलिखित क्रम होता है:
- क्लाइंट बी क्लाउड फायरस्टोर से एक कनेक्शन खोलता है और फायरबेस एसडीके के माध्यम से
onSnapshot(collection("chatroom"))पर कॉल करके एक श्रोता को पंजीकृत करता है। यह श्रोता घंटों तक सक्रिय रह सकता है। - क्लाउड फायरस्टोर फ्रंटएंड डेटासेट को बूटस्ट्रैप करने के लिए अंतर्निहित स्टोरेज सिस्टम पर सवाल उठाता है। यह मिलान दस्तावेज़ों के संपूर्ण परिणाम सेट को लोड करता है। हम इसे एक मतदान क्वेरी के रूप में संदर्भित करते हैं। सिस्टम यह सत्यापित करने के लिए डेटाबेस के फायरबेस सुरक्षा नियमों का मूल्यांकन करता है कि उपयोगकर्ता इस डेटा तक पहुंच सकता है। यदि उपयोगकर्ता अधिकृत है, तो डेटाबेस उपयोगकर्ता को डेटा लौटाता है।
- क्लाइंट बी की क्वेरी फिर श्रवण मोड में चली जाती है। श्रोता एक सदस्यता हैंडलर के साथ पंजीकृत होता है और डेटा के अपडेट की प्रतीक्षा करता है।
- क्लाइंट ए अब किसी दस्तावेज़ को संशोधित करने के लिए एक राइट ऑपरेशन भेजता है।
- डेटाबेस दस्तावेज़ परिवर्तन को अपने भंडारण सिस्टम में भेजता है।
- लेन-देन की दृष्टि से, सिस्टम उसी अद्यतन को आंतरिक चेंजलॉग में भेजता है। चेंजलॉग परिवर्तन होते ही उनका एक सख्त क्रम स्थापित करता है।
- चेंजलॉग बदले में अपडेटेड डेटा को सब्सक्रिप्शन हैंडलर के पूल तक पहुंचाता है।
- एक रिवर्स क्वेरी मिलानकर्ता यह देखने के लिए निष्पादित करता है कि अद्यतन दस्तावेज़ वर्तमान में पंजीकृत स्नैपशॉट श्रोताओं से मेल खाता है या नहीं। इस उदाहरण में, दस्तावेज़ क्लाइंट बी के स्नैपशॉट श्रोता से मेल खाता है। जैसा कि नाम से पता चलता है, आप रिवर्स क्वेरी मैचर को एक सामान्य डेटाबेस क्वेरी के रूप में सोच सकते हैं लेकिन इसे उल्टा किया जाता है। किसी क्वेरी से मेल खाने वाले दस्तावेज़ों को खोजने के बजाय, यह कुशलतापूर्वक प्रश्नों के माध्यम से उन दस्तावेज़ों को खोजता है जो आने वाले दस्तावेज़ से मेल खाते हैं। मिलान मिलने पर, सिस्टम संबंधित दस्तावेज़ को स्नैपशॉट श्रोताओं को अग्रेषित कर देता है। फिर सिस्टम यह सुनिश्चित करने के लिए डेटाबेस के फायरबेस सुरक्षा नियमों का मूल्यांकन करता है कि केवल अधिकृत उपयोगकर्ता ही डेटा प्राप्त करें।
- सिस्टम क्लाइंट बी के डिवाइस पर दस्तावेज़ अपडेट को एसडीके पर अग्रेषित करता है, और
onSnapshotकॉलबैक सक्रिय हो जाता है। यदि स्थानीय दृढ़ता सक्षम है, तो एसडीके स्थानीय कैश पर भी अपडेट लागू करता है।
क्लाउड फायरस्टोर की स्केलेबिलिटी का एक महत्वपूर्ण हिस्सा चेंजलॉग से लेकर सब्सक्रिप्शन हैंडलर और फ्रंटएंड सर्वर तक फैन-आउट पर निर्भर करता है। फैन-आउट एकल डेटा परिवर्तन को लाखों वास्तविक समय के प्रश्नों और कनेक्टेड उपयोगकर्ताओं की सेवा के लिए कुशलतापूर्वक प्रचारित करने की सुविधा देता है। इन सभी घटकों की कई प्रतिकृतियां कई क्षेत्रों (या बहु-क्षेत्र परिनियोजन के मामले में कई क्षेत्रों) में चलाकर, क्लाउड फायरस्टोर उच्च उपलब्धता और स्केलेबिलिटी प्राप्त करता है।
यह ध्यान देने योग्य है कि मोबाइल और वेब एसडीके से जारी किए गए सभी रीड ऑपरेशन उपरोक्त मॉडल का पालन करते हैं। वे निरंतरता की गारंटी बनाए रखने के लिए श्रवण मोड के बाद मतदान क्वेरी निष्पादित करते हैं। यह वास्तविक समय के श्रोताओं, दस्तावेज़ को पुनः प्राप्त करने के लिए कॉल और एक-शॉट क्वेरी पर भी लागू होता है। आप एकल दस्तावेज़ पुनर्प्राप्ति और एक-शॉट क्वेरी को अल्पकालिक स्नैपशॉट श्रोताओं के रूप में सोच सकते हैं जो प्रदर्शन के आसपास समान बाधाओं के साथ आते हैं।
वास्तविक समय की क्वेरी को स्केल करने के लिए सर्वोत्तम अभ्यास लागू करें
स्केलेबल रीयल-टाइम क्वेरी डिज़ाइन करने के लिए निम्नलिखित सर्वोत्तम अभ्यास लागू करें।
सिस्टम में हाई राइट ट्रैफिक को समझें
यह अनुभाग आपको यह समझने में मदद करता है कि सिस्टम बढ़ती संख्या में लेखन अनुरोधों पर कैसे प्रतिक्रिया देता है।
क्लाउड फायरस्टोर चेंजलॉग जो वास्तविक समय की क्वेरी को संचालित करता है, लेखन ट्रैफ़िक बढ़ने पर स्वचालित रूप से क्षैतिज रूप से स्केल करता है। जैसे-जैसे किसी डेटाबेस के लिए लिखने की दर एक सर्वर द्वारा संभाले जाने की क्षमता से अधिक बढ़ जाती है, चेंजलॉग कई सर्वरों में विभाजित हो जाता है, और क्वेरी प्रोसेसिंग एक के बजाय कई सब्सक्रिप्शन हैंडलर से डेटा का उपभोग करना शुरू कर देती है। क्लाइंट और एसडीके के नजरिए से, यह सब पारदर्शी है और विभाजन होने पर ऐप की ओर से किसी कार्रवाई की आवश्यकता नहीं है। निम्नलिखित चित्र दर्शाता है कि वास्तविक समय की क्वेरी कैसे मापी जाती है:
स्वचालित स्केलिंग आपको बिना किसी सीमा के अपना लेखन ट्रैफ़िक बढ़ाने की अनुमति देती है, लेकिन जैसे-जैसे ट्रैफ़िक बढ़ता है, सिस्टम को प्रतिक्रिया देने में कुछ समय लग सकता है। राइट हॉटस्पॉट बनाने से बचने के लिए 5-5-5 नियम की सिफारिशों का पालन करें। कुंजी विज़ुअलाइज़र लेखन हॉटस्पॉट का विश्लेषण करने के लिए एक उपयोगी उपकरण है।
कई ऐप्स में पूर्वानुमानित जैविक विकास होता है, जिसे क्लाउड फायरस्टोर बिना किसी सावधानी के समायोजित कर सकता है। हालाँकि, बड़े डेटासेट को आयात करने जैसे बैच वर्कलोड बहुत तेज़ी से लेखन को बढ़ा सकते हैं। जैसे ही आप अपना ऐप डिज़ाइन करते हैं, इस बात से अवगत रहें कि आपका लेखन ट्रैफ़िक कहाँ से आता है।
समझें कि लिखना और पढ़ना कैसे परस्पर क्रिया करते हैं
आप रीयल-टाइम क्वेरी सिस्टम को पाठकों के साथ लेखन कार्यों को जोड़ने वाली पाइपलाइन के रूप में सोच सकते हैं। जब भी कोई दस्तावेज़ बनाया जाता है, अद्यतन किया जाता है, या हटा दिया जाता है, तो परिवर्तन भंडारण प्रणाली से वर्तमान में पंजीकृत श्रोताओं तक फैल जाता है। क्लाउड फायरस्टोर की चेंजलॉग संरचना मजबूत स्थिरता की गारंटी देती है, जिसका अर्थ है कि आपके ऐप को उन अपडेट की सूचनाएं कभी नहीं मिलती हैं जो डेटाबेस द्वारा डेटा परिवर्तन करने की तुलना में ऑर्डर से बाहर हैं। यह डेटा स्थिरता के आसपास के किनारे के मामलों को हटाकर ऐप विकास को सरल बनाता है।
इस कनेक्टेड पाइपलाइन का मतलब है कि हॉटस्पॉट या लॉक विवाद पैदा करने वाला राइट ऑपरेशन, रीड ऑपरेशन को नकारात्मक रूप से प्रभावित कर सकता है। जब लिखने का कार्य विफल हो जाता है या थ्रॉटलिंग का अनुभव होता है, तो चेंजलॉग से लगातार डेटा की प्रतीक्षा में रीड रुक सकता है। यदि आपके ऐप में ऐसा होता है, तो आपको धीमे लेखन संचालन और प्रश्नों के लिए संबंधित धीमी प्रतिक्रिया समय दोनों दिखाई दे सकते हैं। हॉटस्पॉट से बचना इस समस्या से बचने की कुंजी है।
दस्तावेज़ और लेखन कार्य छोटे रखें
स्नैपशॉट श्रोताओं के साथ ऐप बनाते समय, आप आम तौर पर चाहते हैं कि उपयोगकर्ता डेटा परिवर्तनों के बारे में तुरंत पता लगा सकें। इसे हासिल करने के लिए चीजों को छोटा रखने की कोशिश करें। सिस्टम दसियों फ़ील्ड वाले छोटे दस्तावेज़ों को सिस्टम के माध्यम से बहुत तेज़ी से आगे बढ़ा सकता है। सैकड़ों फ़ील्ड और बड़े डेटा वाले बड़े दस्तावेज़ों को संसाधित होने में अधिक समय लगता है।
इसी तरह, विलंबता को कम रखने के लिए छोटे, तेज़ प्रतिबद्ध और लिखने के संचालन को प्राथमिकता दें। बड़े बैच आपको लेखक के दृष्टिकोण से उच्च थ्रूपुट दे सकते हैं लेकिन वास्तव में स्नैपशॉट श्रोताओं के लिए अधिसूचना समय बढ़ा सकते हैं। यह अक्सर अन्य डेटाबेस सिस्टम का उपयोग करने की तुलना में प्रतिकूल होता है जहां आप प्रदर्शन को बेहतर बनाने के लिए बैचिंग का उपयोग कर सकते हैं।
कुशल श्रोताओं का प्रयोग करें
जैसे-जैसे आपके डेटाबेस के लिए लिखने की दरें बढ़ती हैं, क्लाउड फायरस्टोर डेटा प्रोसेसिंग को कई सर्वरों में विभाजित कर देता है। क्लाउड फायरस्टोर का शार्डिंग एल्गोरिदम एक ही संग्रह या संग्रह समूह से डेटा को एक ही चेंजलॉग सर्वर पर सह-पता लगाने का प्रयास करता है। सिस्टम किसी क्वेरी के प्रसंस्करण में शामिल सर्वरों की संख्या को यथासंभव कम रखते हुए संभावित लेखन थ्रूपुट को अधिकतम करने का प्रयास करता है।
हालाँकि, कुछ पैटर्न अभी भी स्नैपशॉट श्रोताओं के लिए उप-इष्टतम व्यवहार का कारण बन सकते हैं। उदाहरण के लिए, यदि आपका ऐप अपना अधिकांश डेटा एक बड़े संग्रह में संग्रहीत करता है, तो श्रोता को अपनी ज़रूरत का सारा डेटा प्राप्त करने के लिए कई सर्वर से कनेक्ट करने की आवश्यकता हो सकती है। यदि आप क्वेरी फ़िल्टर लागू करते हैं तो भी यह सत्य रहता है। कई सर्वरों से कनेक्ट होने से धीमी प्रतिक्रियाओं का खतरा बढ़ जाता है।
इन धीमी प्रतिक्रियाओं से बचने के लिए, अपना स्कीमा और ऐप डिज़ाइन करें ताकि सिस्टम कई अलग-अलग सर्वरों पर जाए बिना श्रोताओं को सेवा प्रदान कर सके। आपके डेटा को छोटी लेखन दरों के साथ छोटे संग्रहों में विभाजित करना सबसे अच्छा काम कर सकता है।
यह रिलेशनल डेटाबेस में प्रदर्शन प्रश्नों के बारे में सोचने के समान है जिसके लिए पूर्ण तालिका स्कैन की आवश्यकता होती है। एक रिलेशनल डेटाबेस में, एक क्वेरी जिसके लिए पूर्ण तालिका स्कैन की आवश्यकता होती है, वह एक स्नैपशॉट श्रोता के बराबर होती है जो उच्च-मंथन संग्रह को देखता है। यह किसी क्वेरी की तुलना में धीमी गति से कार्य कर सकता है जिसे डेटाबेस अधिक विशिष्ट सूचकांक का उपयोग करके प्रस्तुत कर सकता है। अधिक विशिष्ट सूचकांक वाली क्वेरी एक स्नैपशॉट श्रोता की तरह होती है जो किसी एकल दस्तावेज़ या संग्रह को देखता है जो कम बार बदलता है। आपको अपने उपयोग के मामले के व्यवहार और आवश्यकता को बेहतर ढंग से समझने के लिए अपने ऐप का परीक्षण लोड करना चाहिए।
मतदान संबंधी प्रश्न तेजी से रखें
प्रतिक्रियाशील वास्तविक समय प्रश्नों के एक अन्य महत्वपूर्ण भाग में यह सुनिश्चित करना शामिल है कि डेटा को बूटस्ट्रैप करने के लिए मतदान क्वेरी तेज़ और कुशल है। पहली बार जब कोई नया स्नैपशॉट श्रोता कनेक्ट होता है, तो श्रोता को संपूर्ण परिणाम सेट लोड करना होगा और इसे उपयोगकर्ता के डिवाइस पर भेजना होगा। धीमी क्वेरीज़ आपके ऐप को कम प्रतिक्रियाशील बनाती हैं. इसमें, उदाहरण के लिए, वे क्वेरीज़ शामिल हैं जो कई दस्तावेज़ों को पढ़ने का प्रयास करती हैं या ऐसी क्वेरीज़ जो उपयुक्त अनुक्रमणिका का उपयोग नहीं करती हैं।
कुछ परिस्थितियों में श्रोता सुनने की स्थिति से मतदान की स्थिति में वापस आ सकता है। यह स्वचालित रूप से होता है और एसडीके और आपके ऐप के लिए पारदर्शी है। निम्नलिखित स्थितियाँ मतदान की स्थिति को ट्रिगर कर सकती हैं:
- लोड में परिवर्तन के कारण सिस्टम चेंजलॉग को पुनः संतुलित करता है ।
- हॉटस्पॉट के कारण डेटाबेस में लेखन विफल या विलंबित हो जाता है।
- क्षणिक सर्वर पुनरारंभ श्रोताओं को अस्थायी रूप से प्रभावित करता है।
यदि आपकी पोलिंग क्वेरीज़ पर्याप्त तेज़ हैं, तो पोलिंग स्थिति आपके ऐप के उपयोगकर्ताओं के लिए पारदर्शी हो जाती है।
दीर्घजीवी श्रोताओं का पक्ष लें
क्लाउड फायरस्टोर का उपयोग करने वाला ऐप बनाने के लिए उसे खोलना और श्रोताओं को यथासंभव लंबे समय तक जीवित रखना अक्सर सबसे अधिक लागत प्रभावी तरीका होता है। क्लाउड फायरस्टोर का उपयोग करते समय, आपसे आपके ऐप पर लौटाए गए दस्तावेज़ों के लिए बिल लिया जाता है, न कि खुले कनेक्शन को बनाए रखने के लिए। एक लंबे समय तक रहने वाला स्नैपशॉट श्रोता अपने पूरे जीवनकाल में केवल वही डेटा पढ़ता है जिसकी उसे क्वेरी को पूरा करने के लिए आवश्यकता होती है। इसमें एक प्रारंभिक मतदान ऑपरेशन शामिल है जिसके बाद जब डेटा वास्तव में बदलता है तो सूचनाएं आती हैं। दूसरी ओर, एक-शॉट क्वेरीज़, उस डेटा को दोबारा पढ़ती हैं जो ऐप द्वारा अंतिम बार क्वेरी निष्पादित करने के बाद से नहीं बदला है।
ऐसे मामलों में जहां आपके ऐप को डेटा की उच्च दर का उपभोग करना होगा, स्नैपशॉट श्रोता उपयुक्त नहीं हो सकते हैं। उदाहरण के लिए, यदि आपका उपयोग मामला एक विस्तारित अवधि के लिए कनेक्शन के माध्यम से प्रति सेकंड कई दस्तावेज़ों को धकेलता है, तो कम आवृत्ति पर चलने वाली एक-शॉट क्वेरी का विकल्प चुनना बेहतर हो सकता है।
आगे क्या होगा
- स्नैपशॉट श्रोताओं का उपयोग करना सीखें।
- अधिक सर्वोत्तम प्रथाओं के बारे में पढ़ें.