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

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

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

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

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

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

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

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

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

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

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

फ़ील्ड के नाम

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

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

इंडेक्स

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

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

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

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

इंडेक्स करने से जुड़ी छूट

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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