बड़े पैमाने पर पढ़े और लिखे गए कॉन्टेंट को समझना

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

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

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

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

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

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

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

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

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

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

Cloud Firestore सेवा

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

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

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

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

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

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

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

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

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

Cloud Firestore के डेटाबेस का बंटवारा">

ऐसा 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 सर्वर, इनमें से ज़्यादातर क्वेरी को अंदरूनी तौर पर दो मुख्य स्टेज में मैनेज करता है:

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

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

स्टोरेज लेयर से डेटा को अंदरूनी रूप से प्रोसेस किया जाता है. इसके लिए, डेटाबेस ट्रांज़ैक्शन का इस्तेमाल किया जाता है, ताकि यह पक्का किया जा सके कि डेटा एक जैसा हो. हालांकि, लिखने के लिए इस्तेमाल किए गए लेन-देन के उलट, ये लेन-देन लॉक नहीं होते. इसके बजाय, वे टाइमस्टैंप को चुनकर, उस टाइमस्टैंप पर सभी रीड को एक्ज़ीक्यूट करते हैं. इससे लॉक हासिल नहीं होते, इसलिए वे एक साथ कई रीड-राइट लेन-देन ब्लॉक नहीं करते. इस ट्रांज़ैक्शन को पूरा करने के लिए, 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 नियम कहा जाता है. यह डेटाबेस को आपके वर्कलोड के हिसाब से बेहतर तरीके से स्केल करने के लिए सेट करती है.

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

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

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

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

समस्या का हल

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

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

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