आप अपने ऐप में फायरबेस रीयलटाइम डेटाबेस और क्लाउड फायरस्टोर दोनों का उपयोग कर सकते हैं, और अपनी आवश्यकताओं को पूरा करने के लिए प्रत्येक डेटाबेस समाधान के लाभों का लाभ उठा सकते हैं। उदाहरण के लिए, आप उपस्थिति के लिए रीयलटाइम डेटाबेस के समर्थन का लाभ उठाना चाह सकते हैं, जैसा कि क्लाउड फायरस्टोर में बिल्ड उपस्थिति में उल्लिखित है।
डेटाबेस के बीच अंतर के बारे में अधिक जानें।
डेटा को Cloud Firestore में ले जाया जा रहा है
यदि आपने निर्णय लिया है कि आप अपने कुछ डेटा को रीयलटाइम डेटाबेस से Cloud Firestore में माइग्रेट करना चाहते हैं, तो निम्न प्रवाह पर विचार करें। क्योंकि हर डेटाबेस की अनूठी ज़रूरतें और संरचनात्मक विचार होते हैं, इसलिए कोई स्वचालित माइग्रेशन पथ नहीं है। इसके बजाय, आप इस सामान्य प्रगति का अनुसरण कर सकते हैं:
रीयलटाइम डेटाबेस से क्लाउड फायरस्टोर तक डेटा संरचना और सुरक्षा नियमों को मैप करें। रीयलटाइम डेटाबेस और क्लाउड फायरस्टोर दोनों फायरबेस ऑथेंटिकेशन पर निर्भर करते हैं, इसलिए आपको अपने ऐप के लिए यूजर ऑथेंटिकेशन बदलने की जरूरत नहीं है। हालाँकि, सुरक्षा नियम और डेटा मॉडल अलग-अलग हैं और क्लाउड फायरस्टोर में डेटा ले जाने से पहले उन भिन्नताओं को सावधानीपूर्वक ध्यान में रखना महत्वपूर्ण है।
ऐतिहासिक डेटा ले जाएँ। जैसे ही आप Cloud Firestore में अपनी नई डेटा संरचना सेट कर रहे हैं, आप मौजूदा डेटा को रीयलटाइम डेटाबेस से अपने नए Cloud Firestore इंस्टेंस में मैप और स्थानांतरित कर सकते हैं। हालाँकि, यदि आप अपने ऐप में दोनों डेटाबेस का उपयोग कर रहे हैं, तो आपको ऐतिहासिक डेटा को रीयलटाइम डेटाबेस से बाहर ले जाने की आवश्यकता नहीं है।
रीयल टाइम में Firestore में नया डेटा मिरर करें। अपने नए क्लाउड फायरस्टोर डेटाबेस में नया डेटा लिखने के लिए क्लाउड फ़ंक्शंस का उपयोग करें क्योंकि यह रीयलटाइम डेटाबेस में जुड़ जाता है।
माइग्रेट किए गए डेटा के लिए Cloud Firestore को अपना प्राथमिक डेटाबेस बनाएं। एक बार जब आप अपना कुछ डेटा माइग्रेट कर लेते हैं, तो अपने प्राथमिक डेटाबेस के रूप में Cloud Firestore का उपयोग करें और माइग्रेट किए गए डेटा के लिए अपने रीयलटाइम डेटाबेस के उपयोग को कम करें। अपने ऐप के उन संस्करणों पर विचार करें जो अभी भी उस डेटा के लिए रीयलटाइम डेटाबेस से जुड़े हुए हैं और आप उनका समर्थन जारी रखने की योजना कैसे बना रहे हैं।
सुनिश्चित करें कि आप रीयलटाइम डेटाबेस और क्लाउड फायरस्टोर दोनों के लिए बिलिंग लागतों का हिसाब रखते हैं।
अपना डेटा मैप करें
रीयलटाइम डेटाबेस में डेटा को एक पेड़ के रूप में संरचित किया जाता है, जबकि क्लाउड फायरस्टोर दस्तावेज़ों, संग्रहों और उप-संग्रहों के माध्यम से अधिक स्पष्ट डेटा पदानुक्रमों का समर्थन करता है। अगर आप अपने कुछ डेटा को रीयलटाइम डेटाबेस से Cloud Firestore में ले जाते हैं, तो हो सकता है कि आप अपने डेटा के लिए एक अलग आर्किटेक्चर पर विचार करना चाहें।
विचार करने के लिए प्रमुख अंतर
यदि आप अपने मौजूदा रीयलटाइम डेटाबेस ट्री से डेटा को Cloud Firestore दस्तावेज़ों और संग्रह में ले जाते हैं, तो डेटाबेस के बीच निम्नलिखित प्रमुख अंतरों को ध्यान में रखें जो आपके द्वारा Cloud Firestore में डेटा की संरचना को प्रभावित कर सकते हैं:
- उथला प्रश्न पदानुक्रमित डेटा संरचनाओं में अधिक लचीलापन प्रदान करते हैं।
- जटिल प्रश्न अधिक ग्रैन्युलैरिटी प्रदान करते हैं और डुप्लिकेट डेटा की आवश्यकता को कम करते हैं।
- क्वेरी कर्सर अधिक मजबूत पृष्ठांकन प्रदान करते हैं।
- लेन-देन को अब आपके सभी डेटा के लिए एक सामान्य रूट की आवश्यकता नहीं है, और ये अधिक कुशल हैं।
- बिलिंग लागत रीयलटाइम डेटाबेस और क्लाउड फायरस्टोर के बीच भिन्न होती है। कई मामलों में, क्लाउड फायरस्टार रीयलटाइम डेटाबेस से अधिक महंगा हो सकता है, खासकर यदि आप कई छोटे परिचालनों पर भरोसा करते हैं। अपने डेटाबेस पर संचालन की संख्या कम करने और अनावश्यक लिखने से बचने पर विचार करें। रीयलटाइम डेटाबेस और क्लाउड फायरस्टोर के बीच बिलिंग में अंतर के बारे में और जानें।
कार्रवाई में सर्वोत्तम अभ्यास
निम्न उदाहरण उन कुछ विचारों को दर्शाता है जिन्हें आप डेटाबेस के बीच अपना डेटा स्थानांतरित करते समय कर सकते हैं। आप वास्तविक समय डेटाबेस के साथ उपयोग की जाने वाली तुलना में अधिक प्राकृतिक डेटा संरचनाओं के लिए उथली पठन और बेहतर क्वेरी क्षमताओं का लाभ उठा सकते हैं।
एक सिटी गाइड ऐप पर विचार करें जो उपयोगकर्ताओं को दुनिया भर के शहरों में उल्लेखनीय स्थलों को खोजने में मदद करता है। चूंकि रीयलटाइम डेटाबेस में उथली रीड्स की कमी होती है, इसलिए आपको डेटा को दो शीर्ष-स्तरीय नोड्स में निम्नानुसार संरचना करनी पड़ सकती है:
// /cities/$CITY_KEY
{
name: "New York",
population: 8000000,
capital: False
}
// /city-landmark/$CITY_KEY/$LANDMARK_KEY
{
name: "Empire State Building",
category: "Architecture"
}
Cloud Firestore में उथला रीड है, इसलिए किसी संग्रह में दस्तावेज़ों के लिए क्वेरी करने से उप-संग्रह से डेटा नहीं मिलता है। नतीजतन, आप उप-संग्रह में ऐतिहासिक जानकारी संग्रहीत कर सकते हैं:
// /cities/$CITY_ID
{
name: "New York",
population: 8000000,
capital: False,
landmarks: [... subcollection ...]
}
दस्तावेज़ों का अधिकतम आकार 1 एमबी है, जो नेस्टेड सूचियों के साथ दस्तावेजों को फुलाए जाने के बजाय प्रत्येक शहर के दस्तावेज़ को छोटा रखते हुए लैंडमार्क को एक उपसंग्रह के रूप में संग्रहीत करने का एक और कारण है।
क्लाउड फायरस्टोर की उन्नत पूछताछ क्षमताएं सामान्य एक्सेस पैटर्न के लिए डेटा को डुप्लीकेट करने की आवश्यकता को कम करती हैं। उदाहरण के लिए, सिटी गाइड ऐप में एक स्क्रीन पर विचार करें जो जनसंख्या के क्रम में सभी राजधानी शहरों को दिखाती है। रीयलटाइम डेटाबेस में, ऐसा करने का सबसे कुशल तरीका राजधानी शहरों की एक अलग सूची बनाए रखना है जो cities
सूची से डेटा को डुप्लिकेट करता है, इस प्रकार है:
{
cities: {
// ...
},
capital-cities: {
// ...
}
}
Cloud Firestore में, आप एक प्रश्न के रूप में जनसंख्या के क्रम में राजधानी शहरों की सूची व्यक्त कर सकते हैं:
db.collection('cities')
.where('capital', '==', true)
.orderBy('population')
क्लाउड फायरस्टोर डेटा मॉडल के बारे में अधिक पढ़ें और अपने क्लाउड फायरस्टोर डेटाबेस को कैसे संरचित करें, इस पर अधिक विचारों के लिए हमारे समाधानों पर एक नज़र डालें।
अपना डेटा सुरक्षित करें
चाहे आप Android, Apple, या वेब क्लाइंट के लिए क्लाउड फायरस्टोर सुरक्षा नियमों का उपयोग कर रहे हों, या सर्वर के लिए आइडेंटिटी एक्सेस मैनेजमेंट (IAM) , सुनिश्चित करें कि आप क्लाउड फायरस्टोर के साथ-साथ रीयलटाइम डेटाबेस में भी अपना डेटा सुरक्षित कर रहे हैं। उपयोगकर्ता प्रमाणीकरण दोनों डेटाबेस के लिए प्रमाणीकरण द्वारा नियंत्रित किया जाता है, इसलिए जब आप क्लाउड फायरस्टार का उपयोग करना शुरू करते हैं तो आपको प्रमाणीकरण के कार्यान्वयन को बदलने की आवश्यकता नहीं होती है।
विचार करने के लिए प्रमुख अंतर
- मोबाइल और वेब एसडीके क्लाउड फायरस्टोर सुरक्षा नियमों का उपयोग करते हैं, जबकि सर्वर एसडीके डेटा को सुरक्षित करने के लिए आइडेंटिटी एक्सेस मैनेजमेंट (आईएएम) का उपयोग करते हैं।
- जब तक आप वाइल्डकार्ड का उपयोग नहीं करते हैं, तब तक क्लाउड फायरस्टोर सुरक्षा नियम कैस्केड नहीं होते हैं। दस्तावेज़ और संग्रह अन्यथा नियमों को इनहेरिट नहीं करते हैं।
- अब आपको डेटा को अलग से सत्यापित करने की आवश्यकता नहीं है (जैसा कि आपने रीयलटाइम डेटाबेस में किया था)।
- क्लाउड फायरस्टोर किसी क्वेरी को निष्पादित करने से पहले यह सुनिश्चित करने के लिए नियमों की जांच करता है कि क्वेरी द्वारा लौटाए गए सभी डेटा के लिए उपयोगकर्ता के पास उपयुक्त एक्सेस है।
ऐतिहासिक डेटा को Cloud Firestore में ले जाएं
एक बार जब आप अपने डेटा और सुरक्षा संरचनाओं को Cloud Firestore के डेटा और सुरक्षा मॉडल से मैप कर लेते हैं, तो आप अपना डेटा जोड़ना शुरू कर सकते हैं। यदि आप अपने ऐप को रीयलटाइम डेटाबेस से क्लाउड फायरस्टोर में ले जाने के बाद ऐतिहासिक डेटा को क्वेरी करने की योजना बनाते हैं, तो अपने पुराने डेटा का निर्यात अपने नए क्लाउड फायरस्टोर डेटाबेस में जोड़ें। यदि आप अपने ऐप में रीयलटाइम डेटाबेस और क्लाउड फायरस्टोर दोनों का उपयोग करने की योजना बना रहे हैं, तो आप इस चरण को छोड़ सकते हैं।
नए डेटा को पुराने डेटा के साथ अधिलेखित करने से बचने के लिए, हो सकता है कि आप पहले अपना ऐतिहासिक डेटा जोड़ना चाहें. यदि आप दोनों डेटाबेस में एक साथ नया डेटा जोड़ते हैं, जैसा कि अगले चरण में चर्चा की गई है, तो सुनिश्चित करें कि आप क्लाउड फ़ंक्शंस द्वारा क्लाउड फायरस्टोर में जोड़े गए नए डेटा को प्राथमिकता देते हैं।
Cloud Firestore में ऐतिहासिक डेटा माइग्रेट करने के लिए, इन चरणों का पालन करें:
- रीयलटाइम डेटाबेस से अपना डेटा निर्यात करें या हाल ही के बैकअप का उपयोग करें ।
- फायरबेस कंसोल में रीयलटाइम डेटाबेस अनुभाग पर जाएं।
- डेटा टैब से, अपने डेटाबेस के रूट-लेवल नोड का चयन करें और मेनू से JSON निर्यात करें चुनें।
Cloud Firestore में अपना नया डेटाबेस बनाएं और अपना डेटा जोड़ें ।
जब आप अपने कुछ डेटा को Cloud Firestore में ले जाते हैं, तो निम्नलिखित रणनीतियों पर विचार करें:
- एक कस्टम स्क्रिप्ट लिखें जो आपके डेटा को आपके लिए पोर्ट करती है। जबकि हम इस स्क्रिप्ट के लिए एक टेम्प्लेट की पेशकश नहीं कर सकते हैं, क्योंकि प्रत्येक डेटाबेस की अनूठी ज़रूरतें होंगी, हमारे स्लैक चैनल या स्टैक ओवरफ़्लो पर क्लाउड फायरस्टोर विशेषज्ञ आपकी स्क्रिप्ट की समीक्षा कर सकते हैं या आपकी विशिष्ट स्थिति के लिए सलाह दे सकते हैं।
- Cloud Firestore में सीधे डेटा लिखने के लिए सर्वर SDKs (Node.js, Java, Python, या Go) का उपयोग करें। सर्वर SDK सेट अप करने के निर्देशों के लिए, प्रारंभ करें देखें।
- बड़े डेटा माइग्रेशन में तेजी लाने के लिए, बैच राइट्स का उपयोग करें और एक नेटवर्क अनुरोध में 500 ऑपरेशन तक भेजें।
- Cloud Firestore दर सीमा के अंतर्गत रहने के लिए, प्रत्येक संग्रह के लिए संचालन को 500 राइट/सेकंड तक सीमित करें।
क्लाउड फायरस्टोर में नया डेटा जोड़ें
अपने डेटाबेस के बीच समानता बनाए रखने के लिए, रीयलटाइम में दोनों डेटाबेस में नया डेटा जोड़ें। जब भी कोई क्लाइंट रीयलटाइम डेटाबेस को लिखता है, क्लाउड फायरस्टार पर राइट ट्रिगर करने के लिए क्लाउड फ़ंक्शंस का उपयोग करें। सुनिश्चित करें कि Cloud Firestore आपके ऐतिहासिक डेटा माइग्रेशन से आपके द्वारा किए जा रहे किसी भी लेखन पर क्लाउड फ़ंक्शंस से आने वाले नए डेटा को प्राथमिकता देता है।
हर बार जब कोई क्लाइंट रीयलटाइम डेटाबेस में डेटा लिखता है, तो क्लाउड फायरस्टोर में नया लिखने या डेटा बदलने के लिए एक फ़ंक्शन बनाएं। क्लाउड फ़ंक्शंस के लिए रीयलटाइम डेटाबेस ट्रिगर्स के बारे में और जानें।
माइग्रेट किए गए डेटा के लिए Cloud Firestore को अपना प्राथमिक डेटाबेस बनाएं
यदि आपने अपने कुछ डेटा के लिए अपने प्राथमिक डेटाबेस के रूप में Cloud Firestore का उपयोग करने का निर्णय लिया है, तो सुनिश्चित करें कि आप अपने द्वारा सेट किए गए किसी भी डेटा-मिररिंग फ़ंक्शन के लिए खाते हैं और अपने Cloud Firestore सुरक्षा नियमों को मान्य करते हैं।
यदि आपने अपने डेटाबेस के बीच समानता बनाए रखने के लिए क्लाउड फ़ंक्शंस का उपयोग किया है, तो सुनिश्चित करें कि आप लूप में दोनों डेटाबेस में लेखन कार्यों की नकल नहीं कर रहे हैं। एकल डेटाबेस में लिखने के लिए अपने फ़ंक्शन को स्विच करें, या फ़ंक्शन को पूरी तरह से हटा दें और रीयलटाइम डेटाबेस से जुड़े ऐप्स में माइग्रेट किए गए डेटा के लिए लिखने की कार्यक्षमता को चरणबद्ध रूप से समाप्त करना शुरू करें। आप इसे अपने ऐप के लिए कैसे प्रबंधित करते हैं यह आपकी विशिष्ट आवश्यकताओं और आपके उपयोगकर्ताओं पर निर्भर करता है।
सत्यापित करें कि आपका डेटा ठीक से सुरक्षित है। अपने क्लाउड फायरस्टोर सुरक्षा नियम या IAM सेटअप को मान्य करें।