यहां बताए गए सबसे सही तरीकों को, क्विक रेफ़रंस के तौर पर इस्तेमाल करें का इस्तेमाल करें.
डेटाबेस की लोकेशन
डेटाबेस इंस्टेंस बनाते समय, डेटाबेस चुनें जगह की जानकारी हासिल करना. दूर तक पहुंचने वाले नेटवर्क हॉप, गड़बड़ी की संभावना ज़्यादा होती है. इससे क्वेरी में इंतज़ार का समय बढ़ जाता है.
प्रॉडक्ट की उपलब्धता और उसके लंबे समय तक काम करने के लिए, कोई एक से ज़्यादा इलाके वाला इलाका चुनें और कम से कम दो क्षेत्रों में महत्वपूर्ण कंप्यूट संसाधन रखें.
कम लागत में लिखने के लिए कोई क्षेत्रीय जगह चुनें अगर आपका ऐप्लिकेशन इंतज़ार के समय को लेकर संवेदनशील है, या अन्य GCP संसाधनों के साथ एक साथ लोकेशन सेट करने के लिए.
दस्तावेज़ के आईडी
- दस्तावेज़ आईडी
.और..का इस्तेमाल न करें. - दस्तावेज़ के आईडी में,
/फ़ॉरवर्ड स्लैश का इस्तेमाल करने से बचें. एक ही जगह पर बढ़ते दस्तावेज़ आईडी का इस्तेमाल न करें. जैसे:
Customer1,Customer2,Customer3, ...Product 1,Product 2,Product 3, ...
इस तरह के क्रम में चलने वाले आईडी, ऐसे हॉटस्पॉट बन सकते हैं जो इंतज़ार के समय पर असर डालते हैं.
फ़ील्ड के नाम
फ़ील्ड के नामों में इन वर्णों का इस्तेमाल करने से बचें, क्योंकि इनके लिए अतिरिक्त वर्ण की ज़रूरत होती है एस्केपिंग:
.फ़ुलस्टॉप[बायां ब्रैकेट]दायां ब्रैकेट*तारा`बैकटिक
इंडेक्स
कॉन्टेंट लिखने में लगने वाला समय कम करें
इंडेक्स फ़ैनआउट की वजह से, इंतज़ार का समय लिखने में सबसे ज़्यादा योगदान होता है. सबसे सही तरीके इंडेक्स के फ़ैनआउट को कम करने की प्रोसेस ये हैं:
शुरू कलेक्शन-लेवल के इंडेक्स में छूट. एक आसान डिफ़ॉल्ट विकल्प है अवरोही और कलेक्शन को इंडेक्स करना. इस्तेमाल नहीं की गई इंडेक्स की गई वैल्यू हटाने से, स्टोरेज का शुल्क भी कम हो जाएगा.
लेन-देन में दस्तावेज़ों की संख्या कम करें. बड़ी संख्या में लिखने के लिए इसलिए, ऐटॉमिक बैच के बजाय बल्क राइटर का इस्तेमाल करें लेखक.
इंडेक्स में छूट
ज़्यादातर ऐप्लिकेशन के लिए, अपने-आप इंडेक्स होने की सुविधा और गड़बड़ी के किसी भी मैसेज का इस्तेमाल किया जा सकता है लिंक पर क्लिक करें. हालांकि, हो सकता है कि आपको अपनी वेबसाइट पर सिंगल-फ़ील्ड छूट नीचे दिए गए मामलों में:
| कारक | ब्यौरा |
|---|---|
| बड़े स्ट्रिंग फ़ील्ड | अगर आपके पास कोई ऐसा स्ट्रिंग फ़ील्ड है जिसमें अक्सर ऐसी लंबी स्ट्रिंग वैल्यू होती हैं जिनमें क्वेरी करने के लिए इस्तेमाल नहीं किया जाता है, तो फ़ील्ड को छोड़कर, स्टोरेज की लागत कम की जा सकती है को इंडेक्स न कर सके. |
| क्रम से वैल्यू वाले दस्तावेज़ों वाले कलेक्शन के लिए, लिखने की ज़्यादा दर | अगर किसी फ़ील्ड को इंडेक्स किया जाता है, जो इनके बीच क्रम के मुताबिक बढ़ता या घटता है जैसे कि टाइमस्टैंप. तब आपके कलेक्शन में मौजूद दस्तावेज़ों के लिए, कलेक्शन 500 राइट्स प्रति सेकंड है. अगर क्रम के मुताबिक वैल्यू वाले फ़ील्ड के आधार पर क्वेरी नहीं की जाती है, तो फ़ील्ड को छूट दी जा सकती है को इंडेक्स करने से रोकने के लिए, उस सीमा को बायपास करें. उदाहरण के लिए, ज़्यादा राइट रेट वाले IoT इस्तेमाल के उदाहरण में, टाइमस्टैंप फ़ील्ड वाले दस्तावेज़ों वाले कलेक्शन में 500 राइट प्रति सेकंड की सीमा तक पहुंच सकते हैं. |
| TTL फ़ील्ड |
अगर टीटीएल (टीटीएल) (टाइम-टू-लाइव) नीतियों का इस्तेमाल किया जाता है, तो ध्यान रखें कि TTL (टीटीएल) फ़ील्ड में एक टाइमस्टैंप होना चाहिए. टीटीएल फ़ील्ड पर इंडेक्स करने की सुविधा डिफ़ॉल्ट रूप से चालू होती है. साथ ही, यह सुविधा होने से परफ़ॉर्मेंस पर असर पड़ता है. सबसे सही तरीका यह है कि आपके TTL फ़ील्ड के लिए सिंगल-फ़ील्ड छूट. |
| बड़ा अरे या मैप फ़ील्ड | बड़े अरे या मैप फ़ील्ड में, हर दस्तावेज़ के लिए 40,000 इंडेक्स एंट्री की सीमा पूरी हो सकती है. अगर बड़े अरे या मैप फ़ील्ड के आधार पर क्वेरी नहीं की जा रही है, तो आपको इसे इंडेक्स किए जाने से छूट देनी चाहिए. |
रीड और राइट ऑपरेशन
किसी ऐप्लिकेशन के लिए किसी एक दस्तावेज़ को अपडेट करने की ज़्यादा से ज़्यादा दर, वर्कलोड पर निर्भर करती है. ज़्यादा जानकारी के लिए, एक दस्तावेज़ में होने वाले अपडेट देखें.
सिंक्रोनस कॉल के बजाय जहां उपलब्ध हो वहां एसिंक्रोनस कॉल का इस्तेमाल करें. एसिंक्रोनस कॉल, इंतज़ार के समय के असर को कम करते हैं. उदाहरण के लिए, अगर आपको जिसके लिए पहले दस्तावेज़ के लुकअप और किसी क्वेरी के नतीजों की ज़रूरत होती है रेंडर हो गया है. अगर लुकअप और क्वेरी में डेटा डिपेंडेंसी नहीं है, तो तो आपको उससे पहले लुकअप के पूरा होने तक सिंक्रोनस रूप से इंतज़ार करने की ज़रूरत नहीं है क्वेरी शुरू कर रहा है.
ऑफ़सेट का इस्तेमाल न करें. इसके बजाय, कर्सर. ऑफ़सेट का इस्तेमाल करने से, सिर्फ़ इनसे बचा जा सकता है आपके आवेदन में छोड़े गए दस्तावेज़ लौटा रहा है, लेकिन ये दस्तावेज़ अभी भी आंतरिक रूप से पुनर्प्राप्त किया गया. स्किप किए गए दस्तावेज़, और आपके ऐप्लिकेशन को उन रीड ऑपरेशन के लिए बिल किया जाता है, जो उन्हें फिर से पाएं.
फिर से लेन-देन करने की कोशिश
Cloud Firestore एसडीके और क्लाइंट लाइब्रेरी का अपने-आप दोबारा कोशिश नहीं किया जा सका अस्थायी गड़बड़ियों से निपटने के लिए लेन-देन. अगर आपका ऐप्लिकेशन ऐक्सेस करता है Cloud Firestore ने REST या सीधे RPC एपीआई SDK टूल के बजाय, ऐप्लिकेशन पर भरोसे के लिए, फिर से लेन-देन की कोशिश की जानी चाहिए.
रीयल-टाइम अपडेट
रीयल-टाइम अपडेट से जुड़े सबसे सही तरीकों के बारे में जानने के लिए, यहां जाएं बड़े पैमाने पर रीयल-टाइम क्वेरी को समझना.
बड़े पैमाने पर काम करने के लिए लक्ष्य बनाना
यहां दिए गए सबसे सही तरीकों में, ऐसी स्थितियों से बचने के बारे में बताया गया है विवाद की समस्याएं पैदा करें.
एक दस्तावेज़ में अपडेट
अपना ऐप्लिकेशन डिज़ाइन करते समय, यह ध्यान रखें कि आपका ऐप्लिकेशन किसी दस्तावेज़ को कितनी जल्दी अपडेट करता है. लोड करना, आपके वर्कलोड की परफ़ॉर्मेंस की विशेषता बताने का सबसे अच्छा तरीका है टेस्टिंग हो रही है. किसी ऐप्लिकेशन के लिए, किसी एक दस्तावेज़ को अपडेट करने की ज़्यादा से ज़्यादा दर काम के बोझ पर बहुत ज़्यादा निर्भर करता है. फ़ैक्टर में कॉन्टेंट लिखने की दर, अनुरोधों के बीच का विवाद, और इंडेक्स पर असर डालने वाले इंडेक्स की संख्या शामिल है.
दस्तावेज़ लिखने की कार्रवाई, दस्तावेज़ और उससे जुड़े इंडेक्स को अपडेट करती है, और 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% की बढ़ोतरी हुई हर 5 मिनट में. इसी तरह, पब्लिशर के लिए लिखने वाले ट्रैफ़िक को भी बढ़ाया जा सकता है. हालांकि, ध्यान रखें Cloud Firestore की स्टैंडर्ड सीमाएं. पक्का करें कि कि कार्रवाइयां पूरी मुख्य रेंज में तुलनात्मक रूप से समान रूप से बांटी जाती हैं. यह "500/50/5" कहा जाता है नियम.
ट्रैफ़िक को नए कलेक्शन पर माइग्रेट करना
अगर आप अपने ऐप्लिकेशन ट्रैफ़िक को एक पहले से मौजूद हैं. इस माइग्रेशन को प्रबंधित करने का एक आसान तरीका यह है कि पुराना संग्रह है और अगर दस्तावेज़ मौजूद नहीं है, तो नए संग्रह से पढ़ें संग्रह. हालांकि, इसकी वजह से ट्रैफ़िक में अचानक बढ़ोतरी हो सकती है नए कलेक्शन में मौजूद दस्तावेज़ों को लेक्सिकोग्राफ़िक रूप से बंद किया जाता है. Cloud Firestore ज़्यादा ट्रैफ़िक के लिए, नए कलेक्शन को बेहतर तरीके से तैयार करने में समस्या आ सकती है. खासकर, जब उसमें कुछ ही दस्तावेज़ हों.
कई दस्तावेज़ों के दस्तावेज़ आईडी बदलने पर भी ऐसी ही समस्या आ सकती है एक ही संग्रह में रखें.
ट्रैफ़िक को नए कलेक्शन में माइग्रेट करने के लिए, सबसे अच्छी रणनीति आपके डेटा पर निर्भर करती है model. नीचे रणनीति का एक उदाहरण दिया गया है, जिसे पैरलल रीड के नाम से जाना जाता है. आपको इन चीज़ों की ज़रूरत होगी तय करें कि यह रणनीति आपके डेटा के लिए असरदार है या नहीं. साथ ही, विचार होगा कि समानांतर संचालन के लागत पर असर पड़ेगा माइग्रेशन.
पैरलल रीड
ट्रैफ़िक को नए कलेक्शन में माइग्रेट करते समय, पैरलल रीड लागू करने के लिए पढ़ें पुराने संग्रह से हटाया जा सकता है. अगर दस्तावेज़ मौजूद नहीं है, तो इस दस्तावेज़ से पढ़ें नया संग्रह. जो दस्तावेज़ मौजूद नहीं हैं उन्हें पढ़ने की दर ज़्यादा होने की वजह से हॉटस्पॉटिंग की सुविधा का इस्तेमाल कर रहे हैं, इसलिए पक्का करें कि आप धीरे-धीरे लोड को बढ़ा रहे हैं संग्रह. बेहतर रणनीति यह है कि पुराने दस्तावेज़ को नए कलेक्शन में कॉपी किया जाए तो पुराना दस्तावेज़ हटा दें. पैरलल रीड को धीरे-धीरे रैंप अप करें, ताकि यह पक्का किया जा सके कि Cloud Firestore, नए कलेक्शन पर आने वाले ट्रैफ़िक को मैनेज कर सकता है.
पढ़ने या लिखने की गतिविधि को किसी नए कलेक्शन में धीरे-धीरे बढ़ाने की संभावित रणनीति यूज़र आईडी के डिटरमिनिस्टिक हैश का इस्तेमाल करके, नए दस्तावेज़ लिखने की कोशिश करते हुए उपयोगकर्ता. पक्का करें कि उपयोगकर्ता को जो नतीजा मिला है आईडी हैश को आपके फ़ंक्शन या उपयोगकर्ता के व्यवहार के हिसाब से बदला नहीं जाता.
इस दौरान, ऐसे बैच जॉब चलाएं जो आपके पुराने दस्तावेज़ों का सारा डेटा कॉपी करके नया संग्रह बनाने के लिए प्रोत्साहित करते हैं. आपके बैच जॉब में, क्रम में चलने वाले दस्तावेज़ में लिखने से बचना चाहिए हॉटस्पॉट के इस्तेमाल को रोकने के लिए आईडी. बैच जॉब खत्म होने पर, आप केवल पढ़ सकते हैं नए संग्रह से हटाएं.
इस रणनीति को बेहतर बनाने का मकसद यह है कि एक बार में उपयोगकर्ताओं के छोटे बैच को माइग्रेट किया जाए. उपयोगकर्ता के दस्तावेज़ में वह फ़ील्ड जोड़ें जो उस उपयोगकर्ता के माइग्रेशन की स्थिति को ट्रैक करता है. यूज़र आईडी के हैश के आधार पर माइग्रेट करने के लिए, उपयोगकर्ताओं का बैच चुनें. इस्तेमाल की जाने वाली चीज़ें उपयोगकर्ताओं के उस बैच के लिए दस्तावेज़ों को माइग्रेट करने के लिए बैच जॉब इसमें उपयोगकर्ताओं के लिए पैरलल रीड माइग्रेशन के दौरान.
ध्यान दें कि आप आसानी से तब तक रोल बैक नहीं कर सकते, जब तक आप पुराने दोनों पर दो बार लेख नहीं लिखते और नई इकाइयों को भी शामिल किया जाएगा. इससे, Cloud Firestore की लागत.
निजता
- Cloud प्रोजेक्ट के आईडी में संवेदनशील जानकारी सेव न करें. क्लाउड प्रोजेक्ट आईडी सेव रखने में मदद मिलती है.
- डेटा का पालन करने के सबसे सही तरीके के तौर पर, हमारा सुझाव है कि आप संवेदनशील जानकारी को सेव न करें दस्तावेज़ के नाम और फ़ील्ड के नामों में जानकारी.
बिना अनुमति के ऐक्सेस रोकना
इसकी मदद से, अपने डेटाबेस पर बिना अनुमति वाली कार्रवाइयों को रोकें Cloud Firestore के सुरक्षा नियम. उदाहरण के लिए, नियमों का इस्तेमाल करने से ऐसी स्थिति से बचा जा सकता है जिसमें नुकसान पहुंचाने वाला उपयोगकर्ता बार-बार आपके पूरे डेटाबेस को डाउनलोड कर लेता है.
Cloud Firestore के सुरक्षा नियमों का इस्तेमाल करने के बारे में ज़्यादा जानें.