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

अपने आवेदनों की अच्छी परफ़ॉर्मेंस और विश्वसनीयता बनाए रखने के लिए, सोच-समझकर फ़ैसले लेने के लिए यह दस्तावेज़ पढ़ें. इस दस्तावेज़ में 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 फ़्रंट एंड (GFE)

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

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

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

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

इस सेक्शन में, रीड के टाइप और Cloud Firestore में स्टोरेज लेयर में उन्हें प्रोसेस करने के तरीके के बारे में बताया गया है.

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

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

एक बार में स्प्लिट करके पढ़ना

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

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

• पढ़ने का अनुरोध, लीडर रिप्लिक (ज़ोन A) को भेजा जाता है.
  • लीडर हमेशा अप-टू-डेट रहता है, इसलिए उसे सीधे तौर पर पढ़ा जा सकता है.
• रीड रिक्वेस्ट, लीडर रिप्लिकेशन (जैसे, ज़ोन B) पर जाता है
  • स्प्लिट 3 को अपनी इंटरनल स्थिति से पता चल सकता है कि उसके पास रीड को दिखाने के लिए ज़रूरी जानकारी है और स्प्लिट ऐसा करता है.
  • Split 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, डाइग्नोस्टिक्स टूल के तौर पर की-विज़ुअलाइज़र उपलब्ध कराता है. इसे इस्तेमाल के पैटर्न का विश्लेषण करने और हॉटस्पॉट से जुड़ी समस्याओं को हल करने के लिए डिज़ाइन किया गया है.

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

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