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

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

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

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

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

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

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

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

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

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

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

फ़ील्ड के नाम

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

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

इंडेक्स

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

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

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

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

इंडेक्स के लिए छूट

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

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

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

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

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

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

Cloud Firestore Cloud Firestore SDK टूल और क्लाइंट लाइब्रेरी, अस्थायी गड़बड़ियों से निपटने के लिए, फ़ेल हुए लेन-देन को अपने-आप फिर से करने की कोशिश करती हैं. अगर आपका ऐप्लिकेशन, SDK टूल के बजाय सीधे Cloud Firestore 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 कार्रवाइयों से शुरुआत करें. इसके बाद, हर 5 मिनट में ट्रैफ़िक को 50% बढ़ाएं. इसी तरह, डेटा लिखने के लिए ट्रैफ़िक को बढ़ाया जा सकता है. हालांकि, Cloud Firestore स्टैंडर्ड सीमाओं का ध्यान रखें. पक्का करें कि कार्रवाइयां, की रेंज में अपेक्षाकृत समान रूप से बांटी गई हों. इसे "500/50/5" का नियम कहा जाता है.

ट्रैफ़िक को नए कलेक्शन पर माइग्रेट करना

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

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

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

पैरलल रीड

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

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

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

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

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

निजता

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

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

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

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