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