बड़े पैमाने पर पढ़े जाने और लिखने के बारे में जानकारी

अपने आवेदनों की अच्छी परफ़ॉर्मेंस और विश्वसनीयता बनाए रखने के लिए, सोच-समझकर फ़ैसले लेने के लिए यह दस्तावेज़ पढ़ें. इस दस्तावेज़ में Cloud Firestore के बेहतर विषय शामिल हैं. अगर आपने Cloud Firestore को इस्तेमाल करना अभी-अभी शुरू किया है, तो क्विकस्टार्ट गाइड देखें.

Cloud Firestore एक ऐसा डेटाबेस है जिसे ज़रूरत के हिसाब से बढ़ाया जा सकता है. इस डेटाबेस को Firebase और Google Cloud से मोबाइल डिवाइस, वेब, और सर्वर डेवलपमेंट के लिए इस्तेमाल किया जा सकता है. Cloud Firestore के साथ शुरुआत करना और बेहतरीन और असरदार ऐप्लिकेशन लिखना बहुत आसान है.

यह पक्का करने के लिए कि आपके ऐप्लिकेशन आपके डेटाबेस के साइज़ और ट्रैफ़िक में बढ़ोतरी के साथ अच्छा परफ़ॉर्म करते रहें, यह Cloud Firestore बैकएंड में पढ़ने और लिखने की तकनीक को समझने में मदद करता है. आपको स्टोरेज लेयर के साथ-साथ उन समस्याओं को भी समझना चाहिए जो पढ़ने और लिखने का आपके कॉन्टेंट की परफ़ॉर्मेंस पर असर डाल सकती हैं.

अपना आवेदन तैयार करने से पहले, सबसे सही तरीके जानने के लिए नीचे दिए गए सेक्शन देखें.

हाई लेवल कॉम्पोनेंट को समझना

नीचे दिया गया डायग्राम, Cloud Firestore एपीआई अनुरोध में शामिल हाई लेवल के कॉम्पोनेंट को दिखाता है.

Cloud Firestore SDK टूल और क्लाइंट लाइब्रेरी

Cloud Firestore, अलग-अलग प्लैटफ़ॉर्म के लिए SDK टूल और क्लाइंट लाइब्रेरी के साथ काम करता है. ऐप्लिकेशन, Cloud Firestore एपीआई को सीधे एचटीटीपी और आरपीसी कॉल कर सकता है, लेकिन क्लाइंट लाइब्रेरी, एपीआई के इस्तेमाल को आसान बनाने और सबसे सही तरीके लागू करने के लिए ऐब्स्ट्रैक्ट की एक लेयर उपलब्ध कराती है. इनमें ऑफ़लाइन ऐक्सेस, कैश मेमोरी वगैरह जैसी अन्य सुविधाएं भी मिल सकती हैं.

Google फ़्रंट एंड (जीएफ़ई)

यह बुनियादी ढांचा सेवा है, जो Google की सभी क्लाउड सेवाओं के लिए इस्तेमाल की जाती है. जीएफ़ई, आने वाले अनुरोधों को स्वीकार करता है और उन्हें संबंधित Google सेवा (इस संदर्भ में फ़ायरस्टोर सेवा) पर फ़ॉरवर्ड करता है. यह अन्य ज़रूरी फ़ंक्शन भी उपलब्ध कराता है, जिनमें डिनायल ऑफ़ सर्विस अटैक से सुरक्षा भी शामिल है.

Cloud Firestore की सेवा

Cloud Firestore सेवा, एपीआई अनुरोध पर जांच करती है. इसमें पुष्टि करना, अनुमति देना, कोटा की जांच, और सुरक्षा के नियम शामिल हैं. साथ ही, यह लेन-देन भी मैनेज करती है. इस Cloud Firestore सेवा में एक स्टोरेज क्लाइंट शामिल है, जो डेटा को पढ़ने और सेव करने के लिए, स्टोरेज लेयर से इंटरैक्ट करता है.

Cloud Firestore की स्टोरेज लेयर

Cloud Firestore की स्टोरेज लेयर, डेटा और मेटाडेटा, दोनों को सेव करने की ज़िम्मेदारी है. साथ ही, यह Cloud Firestore से मिलने वाली डेटाबेस सुविधाओं के साथ भी काम करता है. नीचे दिए गए सेक्शन में बताया गया है कि Cloud Firestore की स्टोरेज लेयर में डेटा को कैसे व्यवस्थित किया जाता है और सिस्टम कैसे स्केल करता है. डेटा को व्यवस्थित करने के तरीके के बारे में जानकर, बढ़ाने लायक डेटा मॉडल को डिज़ाइन किया जा सकता है. साथ ही, Cloud Firestore में इस्तेमाल किए जाने वाले सबसे सही तरीकों को बेहतर तरीके से समझा जा सकता है.

मुख्य रेंज और स्प्लिट

Cloud Firestore एक NoSQL, दस्तावेज़ आधारित डेटाबेस है. डेटा को दस्तावेज़ों में सेव किया जाता है. इन्हें कलेक्शन के क्रम में व्यवस्थित किया जाता है. हर दस्तावेज़ के लिए, कलेक्शन की हैरारकी और दस्तावेज़ के आईडी को एक ही कुंजी में बदल दिया जाता है. इस एक कुंजी की मदद से, दस्तावेज़ लॉजिकल तरीके से स्टोर किए जाते हैं और क्रम से लगाए जाते हैं. हम कुंजी की रेंज का इस्तेमाल, कुंजी की कोशिकीय सीमा के बारे में बताने के लिए करते हैं.

एक सामान्य Cloud Firestore डेटाबेस बहुत बड़ा होता है, इसलिए इसे किसी एक मशीन पर फ़िट नहीं किया जा सकता. कुछ मामलों में, एक मशीन पर डेटा को हैंडल करने के लिए बहुत ज़्यादा वर्कलोड भी हो सकता है. बड़ा वर्कलोड हैंडल करने के लिए, Cloud Firestore, डेटा को अलग-अलग हिस्सों में बांटता है. इन हिस्सों को एक से ज़्यादा मशीनों या स्टोरेज सर्वर पर सेव किया जा सकता है और उनसे सेवाएं दी जा सकती हैं. ये विभाजन, डेटाबेस टेबल पर मुख्य रेंज के ब्लॉक में बनाए जाते हैं. इन्हें स्प्लिट कहा जाता है.

अहम जानकारी: अगर आपको यह समझना है कि Cloud Firestore मुख्य रेंज और स्प्लिट को कैसे मैनेज करता है, तो बड़े पैमाने पर डेटा मॉडलिंग के लिए यह समझना ज़रूरी है.

सिंक्रोनस रेप्लिकेशन

इस बात पर ध्यान देना ज़रूरी है कि डेटाबेस को हमेशा अपने-आप और सिंक्रोनस तरीके से दोहराया जाता है. डेटा के अलग-अलग हिस्सों में अलग-अलग ज़ोन में कॉपी होती हैं, ताकि किसी ज़ोन को ऐक्सेस न करने पर भी डेटा उपलब्ध रहे. स्प्लिट की अलग-अलग कॉपी को एक जैसा बनाए रखने को, सभी की सहमति के लिए Paxos एल्गोरिदम मैनेज करता है. हर स्प्लिट की एक कॉपी को पैक्सोस लीडर के तौर पर चुना जाता है, जो उस बंटवारे के लिए जवाब मैनेज करने के लिए ज़िम्मेदार होता है. सिंक्रोनस रेप्लिकेशन की मदद से, आपको हमेशा Cloud Firestore से नए वर्शन के डेटा को पढ़ने की सुविधा मिलती है.

इसकी वजह से, बड़े पैमाने पर काम करने वाला यह सिस्टम उपलब्ध होता है. यह सिस्टम बहुत ज़्यादा काम करता है और पढ़ने-लिखने में देरी होती है. इस पर फिर से काम करना पड़ता है और बहुत ज़्यादा काम करना पड़ता है.

अहम जानकारी: Cloud Firestore की परफ़ॉर्मेंस के एक जैसे होने, उसकी उपलब्धता, और भरोसे के बारे में जानने के लिए यह समझना ज़रूरी है कि Cloud Firestore किस तरह एक जैसे काम करता है.

डेटा लेआउट

Cloud Firestore एक स्कीमालेस दस्तावेज़ डेटाबेस है. हालांकि, यह स्टोरेज लेयर में, डेटा को मुख्य रूप से दो रिलेशनल डेटाबेस-स्टाइल टेबल में इस तरह दिखाता है:

• दस्तावेज़ टेबल: दस्तावेज़ इस टेबल में स्टोर किए जाते हैं.
• इंडेक्स टेबल: इस टेबल में, इंडेक्स की गई ऐसी एंट्री सेव की जाती हैं जिनसे बेहतर तरीके से नतीजे मिल पाते हैं और उन्हें इंडेक्स वैल्यू के हिसाब से क्रम में लगाया जाता है.

नीचे दिया गया डायग्राम दिखाता है कि Cloud Firestore डेटाबेस के लिए टेबल, स्प्लिट के साथ कैसी दिख सकती हैं. स्प्लिट को तीन अलग-अलग ज़ोन में कॉपी किया जाता है और हर स्प्लिट के लिए एक Paxos लीडर असाइन किया जाता है.

एक क्षेत्र बनाम बहु-क्षेत्र

डेटाबेस बनाते समय, आपको कोई क्षेत्र या एक से ज़्यादा क्षेत्र चुनना होगा.

कोई एक जगह, कोई खास भौगोलिक जगह होती है, जैसे कि us-west1. जैसा कि पहले बताया गया है, Cloud Firestore डेटाबेस के डेटा के बंटवारे में, चुने गए इलाके के अलग-अलग ज़ोन में डुप्लीकेट डेटा मौजूद होते हैं.

एक से ज़्यादा इलाकों वाली जगह में, ऐसे इलाकों का एक तय सेट होता है जहां डेटाबेस की कॉपी सेव होती हैं. Cloud Firestore के एक से ज़्यादा इलाकों के डिप्लॉयमेंट में, दो इलाकों के पास डेटाबेस में पूरे डेटा की पूरी नकल है. किसी तीसरे क्षेत्र में, गवाह का एक जैसा प्रतिरूप होता है, जिसमें डेटा का पूरा सेट नहीं होता. हालांकि, वह डेटा कॉपी करने की प्रक्रिया में शामिल होता है. एक से ज़्यादा क्षेत्रों के बीच डेटा की कॉपी बनाने से, पूरा क्षेत्र खो जाने के बाद भी डेटा को लिखा और पढ़ा जा सकता है.

किसी इलाके की जगह के बारे में ज़्यादा जानकारी के लिए, Cloud Firestore की जगहें देखें.

अहम जानकारी: एक क्षेत्र और एक से ज़्यादा इलाकों के लिए कॉन्फ़िगरेशन चुनने पर, परफ़ॉर्मेंस, उपलब्धता, और कीमतों में उतार-चढ़ाव होते हैं.

Cloud Firestore में लिखी गई चीज़ों की लाइफ़ को समझना

Cloud Firestore क्लाइंट, एक दस्तावेज़ बनाकर, अपडेट करके या मिटाकर डेटा लिख सकता है. किसी एक दस्तावेज़ पर लिखने के लिए, दस्तावेज़ और उससे जुड़ी इंडेक्स एंट्री, दोनों को स्टोरेज लेयर में अपडेट करना ज़रूरी होता है. Cloud Firestore, एक या एक से ज़्यादा दस्तावेज़ों को पढ़ने और/या लिखने से जुड़े ऐटॉमिक ऑपरेशन के साथ भी काम करता है.

सभी तरह के लेखन के लिए, Cloud Firestore, रिलेशनल डेटाबेस की ACID प्रॉपर्टी (ऐटॉमिसिटी, कंसिस्टेंसी, आइसोलेशन, और टिकाऊपन) मुहैया कराता है. Cloud Firestore, क्रम से लगाने की क्षमता भी उपलब्ध कराता है. इसका मतलब है कि सभी लेन-देन ऐसे दिखते हैं जैसे कि किसी सीरियल ऑर्डर में किए गए हों.

राइट ट्रांज़ैक्शन में हाई-लेवल चरण

जब Cloud Firestore क्लाइंट, ऊपर बताए गए किसी भी तरीके का इस्तेमाल करके, कोई डेटा लिखते हैं या लेन-देन करते हैं, तो अंदरूनी तौर पर इसे स्टोरेज लेयर में डेटाबेस के पढ़ने-लिखने के लेन-देन के तौर पर लागू किया जाता है. इस लेन-देन की मदद से Cloud Firestore, पहले बताई गई ACID प्रॉपर्टी उपलब्ध करा सकता है.

लेन-देन के पहले चरण के तौर पर, Cloud Firestore मौजूदा दस्तावेज़ को पढ़ता है और दस्तावेज़ों की टेबल में डेटा में किए जाने वाले बदलाव तय करता है.

इसके अलावा, इंडेक्स टेबल में इस तरह से ज़रूरी बदलाव भी किए जा सकते हैं:

• दस्तावेज़ों में जोड़े जा रहे फ़ील्ड को इंडेक्स टेबल में शामिल करना ज़रूरी है.
• दस्तावेज़ों से जो फ़ील्ड हटाए जा रहे हैं उन्हें इंडेक्स टेबल में जाकर मिटाना होगा.
• दस्तावेज़ों में जिन फ़ील्ड में बदलाव किए जा रहे हैं उन्हें इंडेक्स टेबल में मिटाना (पुरानी वैल्यू के लिए) और नई वैल्यू डालने (नई वैल्यू के लिए) दोनों की ज़रूरत होती है.

पहले बताए गए बदलाव का हिसाब लगाने के लिए, Cloud Firestore, प्रोजेक्ट के इंडेक्सिंग कॉन्फ़िगरेशन को पढ़ता है. इंडेक्स करने वाला कॉन्फ़िगरेशन, किसी प्रोजेक्ट के इंडेक्स के बारे में जानकारी सेव करता है. Cloud Firestore दो तरह के इंडेक्स का इस्तेमाल करता है: सिंगल-फ़ील्ड और कंपोज़िट. Cloud Firestore में बनाए गए इंडेक्स के बारे में ज़्यादा जानने के लिए, Cloud Firestore में इंडेक्स टाइप देखें.

म्यूटेशन का हिसाब लगाने के बाद, Cloud Firestore उन्हें एक ट्रांज़ैक्शन में इकट्ठा करता है और फिर उसे पूरा करता है.

अहम जानकारी: Cloud Firestore, लिखने के लिए ACID प्रॉपर्टी उपलब्ध कराने के लिए अंदरूनी तौर पर हमेशा लेन-देन का इस्तेमाल करता है.

स्टोरेज लेयर में राइट ट्रांज़ैक्शन को समझना

जैसा कि पहले बताया जा चुका है, Cloud Firestore में लिखने के दौरान स्टोरेज लेयर में लेन-देन पढ़ने के साथ-साथ, उसे पढ़ने के लिए किया गया लेन-देन शामिल होता है. डेटा के लेआउट के आधार पर, डेटा में एक या एक से ज़्यादा स्प्लिट का इस्तेमाल किया जा सकता है, जैसा कि डेटा लेआउट में देखा जा सकता है.

यहां दिए गए डायग्राम में, Cloud Firestore के डेटाबेस में आठ स्प्लिट (1-8 मार्क किया गया है) को एक ज़ोन में तीन अलग-अलग स्टोरेज सर्वर पर होस्ट किया गया है और हर स्प्लिट को तीन या उससे ज़्यादा ज़ोन में कॉपी किया गया है. हर स्प्लिट में Paxos लीडर होता है, जो अलग-अलग स्प्लिट के लिए अलग ज़ोन में हो सकता है.

ऐसा Cloud Firestore डेटाबेस लें जिसमें Restaurants कलेक्शन इस तरह का हो:

Cloud Firestore क्लाइंट, priceCategory फ़ील्ड की वैल्यू अपडेट करके, Restaurant कलेक्शन में किसी दस्तावेज़ में इस बदलाव का अनुरोध करता है.

यहां दिए गए हाई-लेवल चरण से यह पता चलता है कि कॉन्टेंट लिखने के दौरान क्या होता है:

1. रीड-राइट ट्रांज़ैक्शन बनाएं.
2. स्टोरेज लेयर से, दस्तावेज़ टेबल में मौजूद Restaurants कलेक्शन में से restaurant1 दस्तावेज़ पढ़ें.
3. इंडेक्स टेबल से दस्तावेज़ के इंडेक्स पढ़ें.
4. डेटा में किए जाने वाले बदलाव का हिसाब लगाएं. इस मामले में, पांच म्यूटेशन होते हैं:
   • M1: priceCategory फ़ील्ड की वैल्यू में बदलाव दिखाने के लिए, दस्तावेज़ टेबल में restaurant1 की लाइन अपडेट करें.
   • M2 और M3: घटते और बढ़ते क्रम में इंडेक्स टेबल में, priceCategory की पुरानी वैल्यू की पंक्तियां मिटाएं.
   • M4 और M5: घटते और बढ़ते क्रम में इंडेक्स करने के लिए, इंडेक्स टेबल में priceCategory की नई वैल्यू के लिए पंक्तियां डालें.
5. ये बदलाव लागू करें.

Cloud Firestore सेवा में स्टोरेज क्लाइंट, उन स्प्लिट को देखता है जिनमें बदली जाने वाली लाइनों की कुंजियों का मालिकाना हक होता है. चलिए, एक मामले को ध्यान में रखते हैं, जहां स्प्लिट 3 का इस्तेमाल M1 और स्प्लिट 6 के ज़रिए M2 से M5 के बीच किया जाता है. यह लेन-देन डिस्ट्रिब्यूट किया गया है. इसमें हिस्सा लेने वाले लोगों के तौर पर ये सभी स्प्लिट मौजूद हैं. हिस्सा लेने वाले लोगों की संख्या में, ऐसी कोई अन्य स्प्लिट भी शामिल हो सकती है जिससे डेटा को रीड-राइट ट्रांज़ैक्शन के हिस्से के तौर पर पहले पढ़ा गया था.

यहां दिए गए चरण में बताया गया है कि समझौते के तहत क्या होता है:

1. स्टोरेज क्लाइंट, तय की गई एक शर्त जारी करता है. कमिट में M1-M5 म्यूटेशन शामिल होते हैं.
2. इस लेन-देन में, स्प्लिट 3 और 6 का इस्तेमाल किया जाएगा. मीटिंग में हिस्सा लेने वाले किसी एक व्यक्ति को कोऑर्डिनेटर के तौर पर चुना जाता है, जैसे कि Split 3. कोऑर्डिनेटर का काम यह पक्का करना है कि हिस्सा लेने वाले सभी लोगों के लिए, लेन-देन अपने-आप पूरा हो जाए या रद्द हो जाए.
   • इन स्प्लिट की लीडर कॉपी, मीटिंग में हिस्सा लेने वाले लोगों और कोऑर्डिनेटर के काम के लिए ज़िम्मेदार हैं.
3. इसमें हिस्सा लेने वाला हर व्यक्ति और कोऑर्डिनेटर, अपनी-अपनी कॉपी के साथ Paxos एल्गोरिदम चलाता है.
   • लीडर, कॉपी के साथ Paxos एल्गोरिदम चलाता है. कोरम तब पूरा होता है, जब ज़्यादातर मिलते-जुलते टेक्स्ट लीडर को जवाब में ok to commit के साथ जवाब देते हैं.
   • इसके बाद, हर व्यक्ति तैयार हो जाने पर, कोऑर्डिनेटर को इसकी सूचना देता है. यह दो चरणों में होने वाली गतिविधियों का पहला चरण है. अगर कोई व्यक्ति लेन-देन नहीं कर सकता, तो पूरा लेन-देन aborts.
4. जब कोऑर्डिनेटर को पता चल जाता है कि हिस्सा लेने वाले और उसके सभी लोग तैयार हैं, तो वह accept के लेन-देन के नतीजे की जानकारी सभी लोगों को देता है. यह दो चरणों में होने वाले लेन-देन का दूसरा चरण है. इस चरण में, सभी भागीदार यह तय करते हैं कि उन्होंने स्थायी स्टोरेज का वादा किया है और लेन-देन पूरा किया है.
5. कोऑर्डिनेटर, Cloud Firestore में स्टोरेज क्लाइंट से जवाब देता है कि लेन-देन हो गया है. साथ ही, कोऑर्डिनेटर और मीटिंग में शामिल सभी लोग, डेटा में बदलाव लागू करते हैं.

जब Cloud Firestore का डेटाबेस छोटा होता है, तो ऐसा हो सकता है कि M1-M5 के म्यूटेशन की सभी कुंजियों का मालिकाना हक एक ही स्प्लिट के पास हो. ऐसे मामले में, ट्रांज़ैक्शन में सिर्फ़ एक ही व्यक्ति शामिल होता है और पहले बताए गए दो चरणों में होने वाले पेमेंट की ज़रूरत नहीं होती. इससे, लेन-देन में ज़्यादा समय नहीं लगता.

एक से ज़्यादा क्षेत्रों में लिखते हैं

कई क्षेत्रों में डिप्लॉयमेंट में, कई क्षेत्रों में डुप्लीकेट कॉपी बनाने से उपलब्धता बढ़ जाती है. हालांकि, यह कीमत परफ़ॉर्मेंस की लागत के साथ आती है. अलग-अलग क्षेत्रों में प्रतिकृति के बीच संचार करने में ज़्यादा दोतरफ़ा यात्रा समय लगता है. इसलिए, एक इलाके में डिप्लॉयमेंट की तुलना में, Cloud Firestore के काम करने के दौरान इंतज़ार का समय थोड़ा ज़्यादा होता है.

हम कॉपी को इस तरह से कॉन्फ़िगर करते हैं कि स्प्लिट के लिए लीडरशिप मुख्य क्षेत्र में हमेशा बनी रहे. मुख्य क्षेत्र वह है जहां से Cloud Firestore सर्वर पर ट्रैफ़िक आता है. लीडरशिप का यह फ़ैसला, Cloud Firestore में स्टोरेज क्लाइंट और रेप्लिका लीडर (या कई हिस्सों में बंटे लेन-देन के कोऑर्डिनेटर) के बीच कम्यूनिकेशन में होने वाली दोतरफ़ा यात्रा में होने वाली देरी को कम करता है.

Cloud Firestore के हर जवाब में, Cloud Firestore के रीयल-टाइम इंजन के साथ कुछ इंटरैक्शन भी शामिल होता है. रीयल-टाइम क्वेरी के बारे में ज़्यादा जानकारी के लिए, बड़े पैमाने पर रीयल-टाइम क्वेरी को समझना लेख पढ़ें.

अहम जानकारी: Cloud Firestore, लिखने के लिए लेन-देन का इस्तेमाल करता है. इसमें, पढ़ने के लिए शेयर किए गए लॉक और लिखने के लिए खास लॉक पाने की ज़रूरत होती है. जब किसी ट्रांज़ैक्शन में कई पंक्तियां होती हैं, तो उस सेट को कोई दूसरा लेन-देन तब तक नहीं लिख सकता, जब तक कि यह लेन-देन पूरा नहीं हो जाता या यह लेन-देन रद्द हो जाता है. इस वजह से, इंतज़ार का समय बढ़ जाता है और/या मालिकाना हक लॉक होने की गड़बड़ियां होती हैं. इसलिए, ट्रांज़ैक्शन में बड़े पैमाने पर पढ़ने से बचें.

अहम जानकारी: स्प्लिट या मीटिंग में हिस्सा लेने वाले लोगों की संख्या बढ़ने पर, लिखने या लेन-देन में लगने वाला समय भी बढ़ता है. मीटिंग में हिस्सा लेने वाले लोगों की संख्या को कंट्रोल करने के लिए कोई खास तरीका नहीं है. हालांकि, मीटिंग में हिस्सा लेने वाले लोगों की संख्या कम करने के लिए, ये काम किए जा सकते हैं:

• हाई इंडेक्स फ़ैनआउट तब होता है, जब इंडेक्स में कई एंट्री को लिखने की ज़रूरत होती है. किसी दस्तावेज़ में बदलाव करने के लिए इंडेक्स फ़ैनआउट की संख्या ज़्यादा होने पर, डेटाबेस की पंक्तियों या संख्या में बदलाव होने की संभावना बढ़ जाती है. इससे मीटिंग में हिस्सा लेने वाले लोगों की संख्या बढ़ जाती है. क्वेरी करने के लिए इस्तेमाल नहीं किए जाने वाले फ़ील्ड को इंडेक्स करना बंद करें.
• राइटिंग ट्रांज़ैक्शन बढ़ाने के साथ-साथ, अपडेट किए गए दस्तावेज़ों की संख्या बढ़ने पर, प्रोग्राम में हिस्सा लेने वालों की संख्या भी बढ़ती है. इंतज़ार का समय कम रखने के लिए, एक बार में किए जाने वाले लेन-देन के दौरान अपडेट किए गए दस्तावेज़ों की संख्या कम रखें.

Cloud Firestore में पढ़ने की गतिविधि को समझना

यह सेक्शन, Cloud Firestore में मौजूद स्टैंडअलोन और नॉन-रीयल टाइम डेटा के बारे में बताता है. अंदरूनी तौर पर, Cloud Firestore सर्वर इनमें से ज़्यादातर क्वेरी को दो मुख्य स्टेज में हैंडल करता है:

1. इंडेक्स टेबल पर सिंगल रेंज स्कैन
2. पिछले स्कैन के नतीजे के आधार पर दस्तावेज़ टेबल में पॉइंट लुकअप

ऐसा हो सकता है कि कुछ क्वेरी के लिए Cloud Firestore में कम या ज़्यादा प्रोसेसिंग की ज़रूरत हो. उदाहरण के लिए, IN क्वेरी.

स्टोरेज लेयर से डेटा को इंटरनल तौर पर प्रोसेस किया जाता है. इसके लिए, डेटाबेस ट्रांज़ैक्शन का इस्तेमाल किया जाता है, ताकि यह पक्का किया जा सके कि डेटा एक जैसा हो. हालांकि, लिखने के लिए इस्तेमाल किए जाने वाले लेन-देन के उलट, ये लेन-देन लॉक नहीं होते हैं. इसके बजाय, वे टाइमस्टैंप को चुनकर, उस टाइमस्टैंप पर सभी रीड को एक्ज़ीक्यूट करते हैं. इससे लॉक हासिल नहीं होते, इसलिए वे एक साथ कई रीड-राइट लेन-देन ब्लॉक नहीं करते. इस लेन-देन को पूरा करने के लिए, Cloud Firestore में स्टोरेज क्लाइंट, टाइमस्टैंप की सीमा तय करता है. इससे स्टोरेज लेयर को पता चलता है कि पढ़ने के लिए टाइमस्टैंप कैसे चुना जा सकता है. Cloud Firestore में स्टोरेज क्लाइंट ने टाइमस्टैंप की जो सीमा चुनी है वह पढ़ने के अनुरोध के लिए पढ़ने के विकल्पों से तय होती है.

स्टोरेज लेयर में, पढ़े गए लेन-देन के बारे में जानकारी

इस सेक्शन में बताया गया है कि किस तरह के लेख पढ़े जाते हैं. साथ ही, यह भी बताया गया है कि Cloud Firestore के स्टोरेज लेयर में उन्हें कैसे प्रोसेस किया जाता है.

अच्छी किताबें

डिफ़ॉल्ट रूप से, Cloud Firestore के लेख पूरी तरह एक जैसे होते हैं. लगातार एक जैसे होने का मतलब है कि Cloud Firestore, पढ़ने से जुड़े डेटा का सबसे नया वर्शन दिखाता है. इसमें, पढ़े जाने से पहले किए गए सभी लेख दिखते हैं.

सिंगल स्प्लिट रीड

Cloud Firestore में स्टोरेज क्लाइंट, उन स्प्लिट को देखता है जिनके पास पढ़ी जाने वाली पंक्तियों की कुंजियों का मालिकाना हक होता है. मान लें कि इसके लिए पिछले सेक्शन को स्प्लिट 3 से पढ़ना ज़रूरी है. दोतरफ़ा यात्रा में लगने वाले समय को कम करने के लिए क्लाइंट, पढ़ने का अनुरोध सबसे पास वाली कॉपी को भेजता है.

इस समय, चुनी गई कॉपी के आधार पर ये मामले हो सकते हैं:

• पढ़ने का अनुरोध, लीडर की कॉपी (ज़ोन A) को भेजा जाता है.
  • लीडर हमेशा अप-टू-डेट रहता है, इसलिए रीड सीधे आगे बढ़ सकती है.
• पढ़ने का अनुरोध, बिना लीडर की तरह काम करने वाली किसी इकाई को भेजा जाता है. जैसे, ज़ोन B
  • स्प्लिट 3 को अपनी अंदरूनी स्थिति से पता चल सकता है कि इसमें पढ़ने के लिए ज़रूरी जानकारी मौजूद है और स्प्लिट ऐसा करता है.
  • स्प्लिट 3 को पक्के तौर पर यह पता नहीं है कि इसने नया डेटा देखा है या नहीं. यह लीडर को मैसेज भेजता है. इसमें वह आखिरी लेन-देन का टाइमस्टैंप मांगता है जिसे पढ़ने के लिए लागू करना ज़रूरी है. वह ट्रांज़ैक्शन लागू होने के बाद, रीड आगे बढ़ सकती है.

इसके बाद, Cloud Firestore अपने क्लाइंट को जवाब देता है.

मल्टी-स्प्लिट रीड

ऐसी स्थिति में जहां रीड को एक से ज़्यादा स्प्लिट से करना होता है, सभी स्प्लिट में एक ही तरीका अपनाया जाता है. सभी स्प्लिट से डेटा वापस आने के बाद, Cloud Firestore में स्टोरेज क्लाइंट नतीजों को जोड़ देता है. इसके बाद, Cloud Firestore इस डेटा के साथ अपने क्लाइंट को जवाब देता है.

अहम जानकारी: डेटा को पढ़ने में लगने वाले समय में बढ़ोतरी होने पर, स्प्लिट की संख्या भी बढ़ती है. जब भी मुमकिन होगा, अपनी क्वेरी के नतीजों को छोटा रखने से मदद मिलेगी.

पुरानी जानकारी

Cloud Firestore में अच्छे से पढ़ना डिफ़ॉल्ट मोड है. हालांकि, लीडर से संपर्क करने की ज़रूरत पड़ सकती है. इस वजह से, इंतज़ार का समय बढ़ सकता है. अक्सर आपके Cloud Firestore ऐप्लिकेशन को डेटा का सबसे नया वर्शन पढ़ने की ज़रूरत नहीं होती. इसलिए, यह सुविधा ऐसे डेटा के साथ अच्छे से काम करती है जो कुछ सेकंड पुराना हो सकता है.

ऐसे मामले में, क्लाइंट read_time पढ़ने के विकल्पों का इस्तेमाल करके पुरानी जानकारी पाने का विकल्प चुन सकता है. इस मामले में, रीड तब किए जाते हैं, जब डेटा read_time पर था. साथ ही, इस बात की काफ़ी संभावना है कि सबसे नज़दीकी रेप्लिका ने यह पुष्टि कर ली हो कि उसमें बताए गए read_time पर डेटा मौजूद है. साफ़ तौर पर बेहतर परफ़ॉर्मेंस के लिए, 15 सेकंड पुरानी जानकारी को खारिज करने वाला मान है. यहां तक कि पुरानी जानकारी के लिए भी, जनरेट की गई लाइनें एक-दूसरे से मेल खाती हैं.

अहम जानकारी: अच्छी क्वालिटी का रीड ओनली डेटा का इस्तेमाल करके यह पक्का किया जाता है कि किसी व्यक्ति ने नया डेटा देखा हो. हालांकि, इसमें लीडर से संपर्क करने के लिए की जाने वाली कॉपी की दोतरफ़ा यात्रा में देरी हो सकती है. साथ ही, ट्रांज़ैक्शन के ट्रांज़ैक्शन को लागू करने के लिए इंतज़ार करना पड़ सकता है. बेहतर परफ़ॉर्मेंस के लिए, ऐसे रीड का इस्तेमाल करें जो पुराना डेटा लौटाने में आपकी मदद करते हैं.

हॉटस्पॉट से बचें

Cloud Firestore में स्प्लिट अपने-आप छोटे-छोटे हिस्सों में बंट जाते हैं. इसकी वजह यह है कि ज़रूरत के समय या मुख्य स्पेस का दायरा बढ़ने पर, ट्रैफ़िक को ज़्यादा स्टोरेज सर्वर पर उपलब्ध कराया जाता है. ज़्यादा ट्रैफ़िक को मैनेज करने के लिए, स्प्लिट करीब 24 घंटे तक सेव रहते हैं. भले ही, ट्रैफ़िक कम हो गया हो. इसलिए, अगर ट्रैफ़िक में बार-बार बढ़ोतरी होती है, तो इसे बांटा जा सकता है. साथ ही, ज़रूरत पड़ने पर इसे बांटा जा सकता है और स्प्लिट भी किए जा सकते हैं. ये तरीके, Cloud Firestore डेटाबेस को बढ़ते हुए ट्रैफ़िक लोड या डेटाबेस के साइज़ को अपने-आप स्केल करने में मदद करते हैं. हालांकि, आपको कुछ सीमाओं की जानकारी होनी चाहिए, जैसा कि नीचे बताया गया है.

स्टोरेज और लोड को अलग-अलग हिस्सों में बांटने में समय लगता है. साथ ही, ट्रैफ़िक को तेज़ी से बढ़ाने पर, इंतज़ार का समय ज़्यादा हो सकता है या समयसीमा पार हो सकती है. आम तौर पर, इसे हॉटस्पॉट कहा जाता है, जबकि सेवा में बदलाव होता है. सबसे सही तरीका यह है कि मुख्य रेंज में ऑपरेशन को डिस्ट्रिब्यूट किया जाए. साथ ही, डेटाबेस में मौजूद कलेक्शन पर ट्रैफ़िक को 500 ऑपरेशन प्रति सेकंड के हिसाब से बढ़ाया जाए. इसे धीरे-धीरे बढ़ाने के बाद, हर पांच मिनट में ट्रैफ़िक को 50% तक बढ़ाएं. इस प्रोसेस को 500/50/5 नियम कहा जाता है. यह डेटाबेस को आपके वर्कलोड के हिसाब से बेहतर तरीके से स्केल करने के लिए सेट करती है.

अहम जानकारी: बेहतर स्केलिंग के लिए, ट्रैफ़िक को 500/50/5 नियम का पालन करके बढ़ाना चाहिए.

हालांकि, लोड बढ़ने के साथ स्प्लिट अपने-आप बन जाते हैं, लेकिन Cloud Firestore, मुख्य रेंज को सिर्फ़ तब तक बांट सकता है, जब तक वह कॉपी किए गए स्टोरेज सर्वर के सेट का इस्तेमाल करके एक दस्तावेज़ पेश नहीं करता. इस वजह से, किसी दस्तावेज़ पर एक साथ बहुत ज़्यादा और लंबे समय तक कार्रवाइयां करने से उस दस्तावेज़ पर हॉटस्पॉट बन सकता है. अगर आपको किसी एक दस्तावेज़ के लिए इंतज़ार का समय ज़्यादा रहता है, तो आपको अपने डेटा मॉडल में बदलाव करना चाहिए, ताकि डेटा को कई दस्तावेज़ों में बांटा जा सके या उसकी कॉपी बनाई जा सके.

कंटेंशन गड़बड़ियां तब होती हैं, जब एक से ज़्यादा कार्रवाइयां एक ही दस्तावेज़ को एक साथ पढ़ने और/या लिखने की कोशिश करती हैं.

अहम जानकारी: किसी एक दस्तावेज़ या मुख्य रेंज में मौजूद दस्तावेज़ों को पढ़ने या लिखने की ज़्यादा दर देने से बचें. ऐसा न करने पर, आपके ऐप्लिकेशन में देरी और/या विवाद से जुड़ी गड़बड़ियां हो सकती हैं.

हॉटस्पॉटिंग का एक और खास मामला तब होता है, जब Cloud Firestore में दस्तावेज़ आईडी के तौर पर, लगातार बढ़ने या घटने वाली कुंजी का इस्तेमाल किया जाता है और हर सेकंड काफ़ी ज़्यादा कार्रवाइयां होती हैं. ज़्यादा स्प्लिट बनाने से यहां कोई फ़ायदा नहीं होता, क्योंकि ट्रैफ़िक में बढ़ोतरी तो नए स्प्लिट में ही होती है. Cloud Firestore, डिफ़ॉल्ट रूप से दस्तावेज़ में सभी फ़ील्ड को अपने-आप इंडेक्स कर लेता है. इसलिए, दस्तावेज़ फ़ील्ड के लिए ऐसे मूविंग हॉटस्पॉट भी इंडेक्स किए जा सकते हैं जिनमें टाइमस्टैंप जैसी वैल्यू क्रम के हिसाब से बढ़ती या घटती हो.

अहम जानकारी: दस्तावेज़ आईडी को तेज़ी से बनाने से बचें, क्योंकि आईडी को एक ही बार में बढ़ाना या कम करना, क्योंकि इससे हॉटस्पॉट बन सकते हैं. हॉटस्पॉटिंग से बचने के लिए, Cloud Firestore के अपने-आप बनने वाले दस्तावेज़ आईडी इस्तेमाल किए जा सकते हैं. ये आईडी स्कैटर एल्गोरिदम का इस्तेमाल करते हैं, ताकि उन्हें लेक्सिकोग्राफ़िक रूप से अलग-अलग भाषाओं में बांटा जा सके.

अहम जानकारी: एक ही तरह से बढ़ाई या घटती वैल्यू वाले इंडेक्स फ़ील्ड में ऐसे हॉटस्पॉट मिल सकते हैं जिनका कॉन्टेंट पढ़ने और लिखने की दर ज़्यादा होती है. अगर क्रम के मुताबिक वैल्यू वाले फ़ील्ड पर क्वेरी नहीं की जाती है, तो इस सीमा को बायपास करने के लिए, फ़ील्ड को इंडेक्स करने से छूट दी जा सकती है.

ध्यान दें कि ऊपर बताए गए तरीके इस्तेमाल करने से, किसी कॉन्फ़िगरेशन में बदलाव किए बिना Firebase बड़े पैमाने पर काम कर सकता है.

समस्या हल करना

Firestore, की विज़ुअलाइज़र को गड़बड़ी की जानकारी देने वाले टूल के तौर पर उपलब्ध कराता है. इसे खास तौर पर, इस्तेमाल के पैटर्न का विश्लेषण करने और हॉटस्पॉटिंग से जुड़ी समस्याओं को हल करने के लिए डिज़ाइन किया गया है.

आगे क्या करना है

• सबसे सही तरीकों के बारे में जानें
• बड़े पैमाने पर रीयल-टाइम क्वेरी के बारे में जानें