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

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

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

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

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

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

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

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

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

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

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

फ़ील्ड के नाम

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

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

इंडेक्स

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

डेटा डालने में लगने वाले समय में, इंडेक्स फ़ैनआउट की मुख्य भूमिका होती है. इंडेक्स फ़ैनआउट को कम करने के सबसे सही तरीके ये हैं:

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

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

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

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

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

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

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

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

लेन-देन दोबारा किए गए

Cloud Firestore SDK टूल और क्लाइंट लाइब्रेरी, कुछ समय के लिए होने वाली गड़बड़ियों को ठीक करने के लिए, पूरे नहीं हुए लेन-देन को अपने-आप फिर से आज़माते हैं. अगर आपका ऐप्लिकेशन, SDK टूल के बजाय सीधे 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 नए कलेक्शन के ट्रैफ़िक को मैनेज कर सकता है.

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

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

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

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

निजता

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

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

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

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