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

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

डेटाबेस की लोकेशन

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

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

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

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

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

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

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

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

फ़ील्ड के नाम

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

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

इंडेक्स

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

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

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

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

इंडेक्स में छूट

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

कारक जानकारी
बड़े स्ट्रिंग फ़ील्ड

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

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

उदाहरण के लिए, ज़्यादा राइट रेट वाले IoT इस्तेमाल के उदाहरण में, टाइमस्टैंप फ़ील्ड वाले दस्तावेज़ों वाले कलेक्शन में 500 राइट प्रति सेकंड की सीमा तक पहुंच सकते हैं.
TTL फ़ील्ड

अगर टीटीएल (टीटीएल) (टाइम-टू-लाइव) नीतियों का इस्तेमाल किया जाता है, तो ध्यान दें कि टीटीएल फ़ील्ड में टाइमस्टैंप होना चाहिए. TTL फ़ील्ड पर इंडेक्स करने की सुविधा डिफ़ॉल्ट रूप से चालू होती है. इससे ज़्यादा ट्रैफ़िक दर मिलने पर पेज की परफ़ॉर्मेंस पर असर पड़ सकता है. सबसे सही तरीका यह है कि अपने TTL फ़ील्ड के लिए एक फ़ील्ड वाली छूट जोड़ें.

बड़ा अरे या मैप फ़ील्ड

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

रीड और राइट ऑपरेशन

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

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

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

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

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

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

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

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

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

निजता

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

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

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

Cloud Firestore के सुरक्षा नियमों का इस्तेमाल करने के बारे में ज़्यादा जानें.