Cloud Firestore के लिए सबसे सही तरीके

Cloud Firestore का इस्तेमाल करने वाला ऐप्लिकेशन बनाते समय, यहां दिए गए सबसे सही तरीकों को क्विक रेफ़रंस के तौर पर इस्तेमाल करें.

डेटाबेस की जगह

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

अपने ऐप्लिकेशन की उपलब्धता और टिकाऊपन को बढ़ाने के लिए, एक से ज़्यादा क्षेत्रों वाली जगह चुनें. साथ ही, कंप्यूटिंग के ज़रूरी संसाधनों को कम से कम दो क्षेत्रों में रखें.

कम लागत के लिए, क्षेत्र के हिसाब से जगह चुनें. अगर आपका ऐप्लिकेशन लेटेन्सी के लिए संवेदनशील है, तो राइट लेटेन्सी कम करने के लिए जगह चुनें. इसके अलावा, अन्य GCP संसाधनों के साथ को-लोकेशन के लिए जगह चुनें.

दस्तावेज़ के आईडी

• दस्तावेज़ आईडी . और .. का इस्तेमाल न करें.
• दस्तावेज़ आईडी में / फ़ॉरवर्ड स्लैश का इस्तेमाल न करें.

• ऐसे दस्तावेज़ आईडी का इस्तेमाल न करें जो लगातार बढ़ते हों. जैसे:

  • Customer1, Customer2, Customer3, ...
  • Product 1, Product 2, Product 3, ...

  इस तरह के क्रम से दिए गए आईडी की वजह से, हॉटस्पॉट बन सकते हैं. इससे इंतज़ार के समय पर असर पड़ता है.

फ़ील्ड के नाम

• फ़ील्ड के नामों में यहां दिए गए वर्णों का इस्तेमाल न करें, क्योंकि इनके लिए अतिरिक्त एस्केपिंग की ज़रूरत होती है:

  • . फ़ुलस्टॉप
  • [ लेफ़्ट ब्रैकेट
  • ] राइट स्क्वेयर ब्रैकेट
  • * तारा
  • ` बैकटिक

इंडेक्स

डेटा लिखने में लगने वाला समय कम करना

लिखने में लगने वाले समय पर इंडेक्स फ़ैनआउट का सबसे ज़्यादा असर पड़ता है. इंडेक्स फ़ैनआउट को कम करने के सबसे सही तरीके ये हैं:

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

• लेन-देन में शामिल दस्तावेज़ों की संख्या कम करें. ज़्यादा दस्तावेज़ लिखने के लिए, एटॉमिक बैच राइटर के बजाय बल्क राइटर का इस्तेमाल करें.

इंडेक्सिंग से जुड़ी छूट

ज़्यादातर ऐप्लिकेशन के लिए, इंडेक्स मैनेज करने के लिए ऑटोमैटिक इंडेक्सिंग के साथ-साथ गड़बड़ी के मैसेज वाले लिंक का इस्तेमाल किया जा सकता है. हालांकि, इन मामलों में एक फ़ील्ड के लिए छूट जोड़ी जा सकती है:

पढ़ने और लिखने की कार्रवाइयां

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

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

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

लेन-देन फिर से करने की कोशिशें

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

रीयल-टाइम अपडेट

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

बड़े पैमाने पर इस्तेमाल करने के लिए डिज़ाइन करना

यहां दिए गए सबसे सही तरीकों से, विवाद की स्थिति पैदा करने वाली समस्याओं से बचा जा सकता है.

किसी एक दस्तावेज़ में किए गए अपडेट

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

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

दस्तावेज़ की किसी छोटी रेंज में पढ़ने, लिखने, और मिटाने की ज़्यादा दरें

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

• यह बहुत तेज़ी से नए दस्तावेज़ बनाता है और उन्हें अपने आईडी असाइन करता है.

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

• यह कम दस्तावेज़ों वाले कलेक्शन में, ज़्यादा तेज़ी से नए दस्तावेज़ बनाता है.

• यह बहुत ज़्यादा फ़्रीक्वेंसी पर, ऐसे फ़ील्ड के साथ नए दस्तावेज़ बनाता है जिसकी वैल्यू लगातार बढ़ती रहती है. जैसे, टाइमस्टैंप.

• यह किसी कलेक्शन में मौजूद दस्तावेज़ों को तेज़ी से मिटाता है.

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

मिटाए गए डेटा को स्किप न करें

ऐसी क्वेरी से बचें जिनमें हाल ही में मिटाए गए डेटा को शामिल न किया गया हो. अगर क्वेरी के शुरुआती नतीजे हाल ही में मिटाए गए हैं, तो हो सकता है कि क्वेरी को इंडेक्स की कई एंट्री छोड़नी पड़ें.

ऐसे वर्कलोड का उदाहरण जिसमें मिटाए गए डेटा को स्किप करना पड़ सकता है, वह है जो सबसे पुराने क्यू किए गए वर्क आइटम ढूंढने की कोशिश करता है. क्वेरी कुछ ऐसी दिख सकती है:

docs = db.collection('WorkItems').order_by('created').limit(100)
delete_batch = db.batch()
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
delete_batch.commit()

जब भी यह क्वेरी चलती है, तो यह हाल ही में मिटाए गए किसी भी दस्तावेज़ के created फ़ील्ड के लिए इंडेक्स एंट्री को स्कैन करती है. इससे क्वेरी की प्रोसेस धीमी हो जाती है.

परफ़ॉर्मेंस को बेहतर बनाने के लिए, start_at तरीके का इस्तेमाल करके यह पता लगाएं कि कहां से शुरुआत करनी है. उदाहरण के लिए:

completed_items = db.collection('CompletionStats').document('all stats').get()
docs = db.collection('WorkItems').start_at(
    {'created': completed_items.get('last_completed')}).order_by(
        'created').limit(100)
delete_batch = db.batch()
last_completed = None
for doc in docs.stream():
  finish_work(doc)
  delete_batch.delete(doc.reference)
  last_completed = doc.get('created')

if last_completed:
  delete_batch.update(completed_items.reference,
                      {'last_completed': last_completed})
  delete_batch.commit()

ध्यान दें: ऊपर दिए गए उदाहरण में, लगातार बढ़ने वाले फ़ील्ड का इस्तेमाल किया गया है. यह ज़्यादा राइट रेट के लिए सही नहीं है.

ट्रैफ़िक बढ़ाना

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

ट्रैफ़िक को नए कलेक्शन पर माइग्रेट करना

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

अगर एक ही कलेक्शन में मौजूद कई दस्तावेज़ों के आईडी बदल दिए जाते हैं, तो भी ऐसी समस्या हो सकती है.

किसी नए कलेक्शन में ट्रैफ़िक माइग्रेट करने की सबसे सही रणनीति, आपके डेटा मॉडल पर निर्भर करती है. यहां पैरलल रीड के नाम से जानी जाने वाली रणनीति का एक उदाहरण दिया गया है. आपको यह तय करना होगा कि यह रणनीति आपके डेटा के लिए कारगर है या नहीं. साथ ही, माइग्रेशन के दौरान पैरलल ऑपरेशन की लागत पर पड़ने वाले असर पर भी ध्यान देना होगा.

पैरलल रीड

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

किसी नए कलेक्शन में धीरे-धीरे रीड या राइट करने के लिए, उपयोगकर्ता आईडी के डिटरमिनिस्टिक हैश का इस्तेमाल किया जा सकता है. इससे, नए दस्तावेज़ लिखने की कोशिश करने वाले उपयोगकर्ताओं में से कुछ को रैंडम तरीके से चुना जा सकता है. पक्का करें कि आपके फ़ंक्शन या उपयोगकर्ता के व्यवहार की वजह से, उपयोगकर्ता आईडी हैश का नतीजा गलत न हो.

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

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

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

निजता

• Cloud प्रोजेक्ट आईडी में संवेदनशील जानकारी सेव न करें. Cloud प्रोजेक्ट आईडी को आपके प्रोजेक्ट की लाइफ़टाइम के बाद भी सेव करके रखा जा सकता है.
• डेटा के अनुपालन से जुड़े सबसे सही तरीके के तौर पर, हमारा सुझाव है कि दस्तावेज़ के नामों और दस्तावेज़ के फ़ील्ड के नामों में संवेदनशील जानकारी सेव न करें.

बिना अनुमति के ऐक्सेस करने से रोकना

Cloud Firestore Security Rules की मदद से, अपने डेटाबेस पर बिना अनुमति के होने वाली कार्रवाइयों को रोकें. उदाहरण के लिए, नियमों का इस्तेमाल करके ऐसी स्थिति से बचा जा सकता है जहां कोई दुर्भावनापूर्ण उपयोगकर्ता बार-बार आपका पूरा डेटाबेस डाउनलोड करता है.

Cloud Firestore Security Rules का इस्तेमाल करने के बारे में ज़्यादा जानें.