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