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

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

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

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