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

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

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

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

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

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

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

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

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

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

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

फ़ील्ड के नाम

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

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

इंडेक्स

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

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

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

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

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

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

कारक	ब्यौरा
बड़े स्ट्रिंग फ़ील्ड	अगर आपके पास कोई स्ट्रिंग फ़ील्ड है, जिसमें अक्सर लंबी स्ट्रिंग वैल्यू होती हैं और जिनका इस्तेमाल आपने क्वेरी करने के लिए नहीं किया है, तो फ़ील्ड को इंडेक्स करने से छूट देकर, स्टोरेज के खर्च को कम किया जा सकता है.
क्रम से लगाई गई वैल्यू वाले दस्तावेज़ों वाले कलेक्शन में, डेटा लिखने की दर ज़्यादा होना	अगर आपने किसी ऐसे फ़ील्ड को इंडेक्स किया है जो किसी कलेक्शन में मौजूद दस्तावेज़ों के बीच क्रम से बढ़ता या घटता है, जैसे कि टाइमस्टैंप, तो कलेक्शन में डेटा लिखने की दर ज़्यादा से ज़्यादा 500 बार प्रति सेकंड हो सकती है. अगर क्रम से लगाई गई वैल्यू वाले फ़ील्ड के आधार पर क्वेरी नहीं की जाती है, तो इस सीमा को बायपास करने के लिए, फ़ील्ड को इंडेक्स करने से छूट दी जा सकती है. उदाहरण के लिए, ज़्यादा डेटा लिखने की दर वाले किसी IoT इस्तेमाल के उदाहरण में, टाइमस्टैंप फ़ील्ड वाले दस्तावेज़ों वाले कलेक्शन में, हर सेकंड 500 डेटा लिखने की सीमा तक पहुंचा जा सकता है.
TTL फ़ील्ड	अगर टीटीएल (टाइम-टू-लिव) नीतियों का इस्तेमाल किया जाता है, तो ध्यान दें कि टीटीएल फ़ील्ड में टाइमस्टैंप होना चाहिए. टीटीएल फ़ील्ड पर इंडेक्स करने की सुविधा डिफ़ॉल्ट रूप से चालू होती है. इससे ज़्यादा ट्रैफ़िक रेट पर परफ़ॉर्मेंस पर असर पड़ सकता है. सबसे सही तरीका यह है कि अपने टीटीएल फ़ील्ड के लिए, एक फ़ील्ड के लिए छूट जोड़ें.
बड़े ऐरे या मैप फ़ील्ड	बड़े कलेक्शन या मैप फ़ील्ड में, हर दस्तावेज़ के लिए 40,000 इंडेक्स एंट्री की सीमा तक पहुंचा जा सकता है. अगर किसी बड़े कलेक्शन या मैप फ़ील्ड के आधार पर क्वेरी नहीं की जा रही है, तो आपको उसे इंडेक्स करने से छूट देनी चाहिए.

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

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

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

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

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

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 नए कलेक्शन के ट्रैफ़िक को मैनेज कर सकता है.

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

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

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

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

निजता

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

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

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

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