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

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

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

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

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

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

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

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

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

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

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

फ़ील्ड के नाम

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

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

इंडेक्स

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

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

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

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

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

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

डेटा को ऐक्सेस करने और उसमें बदलाव करने की कार्रवाइयां

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

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

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

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

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

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