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

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

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

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

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

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

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

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

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

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

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

फ़ील्ड के नाम

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

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

इंडेक्स

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

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

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

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

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

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

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

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

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

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

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

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