अपने ऐप्लिकेशन में Firebase Realtime Database और Cloud Firestore, दोनों का इस्तेमाल किया जा सकता है. साथ ही, अपनी ज़रूरतों के हिसाब से हर डेटाबेस समाधान के फ़ायदों का इस्तेमाल किया जा सकता है. उदाहरण के लिए, आपको Realtime Database की मौजूदगी की सुविधा का इस्तेमाल करना पड़ सकता है. इसके बारे में Cloud Firestore में मौजूदगी बढ़ाना लेख में बताया गया है.
डेटाबेस के बीच के अंतर के बारे में ज़्यादा जानें.
डेटा को Cloud Firestore में ले जाना
अगर आपको Realtime Database से Cloud Firestore में कुछ डेटा माइग्रेट करना है, तो यह तरीका अपनाएं. हर डेटाबेस की ज़रूरतें और स्ट्रक्चर अलग-अलग होते हैं. इसलिए, माइग्रेट करने का कोई ऑटोमेटेड तरीका नहीं है. इसके बजाय, इस सामान्य प्रोग्रेशन का पालन किया जा सकता है:
Realtime Database से Cloud Firestore तक डेटा स्ट्रक्चर और सुरक्षा नियमों को मैप करें. Realtime Database और Cloud Firestore, दोनों Firebase Authentication पर निर्भर करते हैं. इसलिए, आपको अपने ऐप्लिकेशन के लिए उपयोगकर्ता की पुष्टि करने की सुविधा में बदलाव करने की ज़रूरत नहीं है. हालांकि, सुरक्षा के नियम और डेटा मॉडल अलग-अलग होते हैं. इसलिए, Cloud Firestore में डेटा ट्रांसफ़र करने से पहले, इन अंतरों को ध्यान में रखना ज़रूरी है.
पुराना डेटा ट्रांसफ़र करना. Cloud Firestore में नया डेटा स्ट्रक्चर सेट अप करते समय, Cloud Firestore से अपने मौजूदा डेटा को नए Cloud Firestore इंस्टेंस में मैप और ट्रांसफ़र किया जा सकता है.Realtime Database हालांकि, अगर आपके ऐप्लिकेशन में दोनों डेटाबेस का इस्तेमाल किया जा रहा है, तो आपको पुराने डेटा को Realtime Database से बाहर ले जाने की ज़रूरत नहीं है.
नए डेटा को रीयलटाइम में Firestore में मिरर करें. Cloud Functions का इस्तेमाल करके, अपने नए Cloud Firestore डेटाबेस में नया डेटा लिखें. ऐसा तब करें, जब उसे Realtime Database में जोड़ा जा रहा हो.
माइग्रेट किए गए डेटा के लिए, Cloud Firestore को अपना प्राइमरी डेटाबेस बनाएं. कुछ डेटा माइग्रेट करने के बाद, Cloud Firestore को अपने मुख्य डेटाबेस के तौर पर इस्तेमाल करें. साथ ही, माइग्रेट किए गए डेटा के लिए Realtime Database का इस्तेमाल कम करें. अपने ऐप्लिकेशन के उन वर्शन के बारे में सोचें जो अब भी उस डेटा के लिए Realtime Database से जुड़े हैं. साथ ही, यह भी सोचें कि आपको उन्हें कैसे सपोर्ट करना है.
पक्का करें कि आपने Realtime Database और Cloud Firestore, दोनों के लिए बिलिंग की लागत शामिल की हो.
अपने डेटा को मैप करना
Realtime Database में डेटा को एक ट्री के तौर पर स्ट्रक्चर किया जाता है. वहीं, Cloud Firestore में दस्तावेज़ों, कलेक्शन, और सब-कलेक्शन के ज़रिए डेटा के क्रम को ज़्यादा साफ़ तौर पर दिखाया जाता है. अगर आपको Realtime Database से Cloud Firestore में कुछ डेटा ट्रांसफ़र करना है, तो हो सकता है कि आपको अपने डेटा के लिए किसी दूसरे आर्किटेक्चर का इस्तेमाल करना पड़े.
मुख्य अंतर
अगर आपको अपने मौजूदा Realtime Database ट्री से डेटा को Cloud Firestore दस्तावेज़ों और कलेक्शन में ले जाना है, तो डेटाबेस के बीच इन मुख्य अंतरों को ध्यान में रखें. इनसे Cloud Firestore में डेटा को स्ट्रक्चर करने के तरीके पर असर पड़ सकता है:
- शैलो क्वेरी, क्रम के हिसाब से व्यवस्थित किए गए डेटा स्ट्रक्चर में ज़्यादा आसानी से काम करती हैं.
- जटिल क्वेरी से ज़्यादा सटीक जानकारी मिलती है और डुप्लीकेट डेटा की ज़रूरत कम हो जाती है.
- क्वेरी कर्सर से, पेजों में बांटने की बेहतर सुविधा मिलती है.
- लेन-देन के लिए, अब आपके सभी डेटा के लिए एक ही रूट की ज़रूरत नहीं होती. साथ ही, ये ज़्यादा असरदार होते हैं.
- Realtime Database और Cloud Firestore के बीच बिलिंग की लागत अलग-अलग होती है. कई मामलों में, Cloud Firestore की तुलना में Realtime Database ज़्यादा महंगा हो सकता है. खास तौर पर, अगर आपको कई छोटे-छोटे ऑपरेशंस पर निर्भर रहना पड़ता है. अपने डेटाबेस पर होने वाले ऑपरेशन की संख्या कम करें और गैर-ज़रूरी राइट ऑपरेशन से बचें. Realtime Database और Cloud Firestore के बीच बिलिंग में अंतर के बारे में ज़्यादा जानें.
कार्रवाई करने के सबसे सही तरीके
यहां दिए गए उदाहरण में, डेटा को एक डेटाबेस से दूसरे डेटाबेस में ट्रांसफ़र करते समय ध्यान रखने वाली कुछ बातों के बारे में बताया गया है. Realtime Database के मुकाबले, ज़्यादा नैचुरल डेटा स्ट्रक्चर के लिए शैलो रीड और बेहतर क्वेरी करने की सुविधाओं का फ़ायदा लिया जा सकता है.
किसी ऐसे सिटी गाइड ऐप्लिकेशन के बारे में सोचें जो दुनिया भर के शहरों में मौजूद मशहूर लैंडमार्क खोजने में लोगों की मदद करता है. Realtime Database में शैलो रीड की सुविधा नहीं है. इसलिए, आपको डेटा को दो टॉप-लेवल नोड में इस तरह से स्ट्रक्चर करना पड़ सकता है:
// /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 एमबी हो सकता है. इसलिए, लैंडमार्क को सब-कलेक्शन के तौर पर सेव करना बेहतर होता है. इससे हर शहर के दस्तावेज़ का साइज़ कम रहता है. इसके बजाय, नेस्ट की गई सूचियों वाले दस्तावेज़ों का साइज़ बढ़ जाता है.
Cloud Firestore की बेहतर क्वेरी क्षमताएं, सामान्य ऐक्सेस पैटर्न के लिए डेटा को डुप्लीकेट करने की ज़रूरत को कम करती हैं. उदाहरण के लिए, शहर की गाइड वाले ऐप्लिकेशन में मौजूद एक स्क्रीन पर गौर करें. इसमें सभी राजधानियों को आबादी के हिसाब से क्रम में दिखाया गया है.
Realtime Database में, ऐसा करने का सबसे सही तरीका यह है कि राजधानी शहरों की एक अलग सूची बनाई जाए. इसमें cities सूची से डेटा कॉपी किया जाता है. यह सूची इस तरह से बनाई जाती है:
{
cities: {
// ...
},
capital-cities: {
// ...
}
}
Cloud Firestore में, राजधानी शहरों की सूची को जनसंख्या के हिसाब से क्रम में लगाने के लिए, एक ही क्वेरी का इस्तेमाल किया जा सकता है:
db.collection('cities')
.where('capital', '==', true)
.orderBy('population')
Cloud Firestore डेटा मॉडल के बारे में ज़्यादा पढ़ें. साथ ही, अपने Cloud Firestore डेटाबेस को स्ट्रक्चर करने के बारे में ज़्यादा आइडिया पाने के लिए, हमारे समाधान देखें.
अपने डेटा को सुरक्षित रखना
चाहे Android, Apple या वेब क्लाइंट के लिए Cloud Firestore Security Rules का इस्तेमाल किया जा रहा हो या सर्वर के लिए पहचान और ऐक्सेस मैनेजमेंट (आईएएम) का, पक्का करें कि Cloud Firestore के साथ-साथ Realtime Database में भी आपका डेटा सुरक्षित हो. दोनों डेटाबेस के लिए, उपयोगकर्ता की पुष्टि करने की प्रोसेस को Authentication हैंडल करता है. इसलिए, Cloud Firestore का इस्तेमाल शुरू करते समय, आपको Authentication के तरीके में बदलाव करने की ज़रूरत नहीं है.
मुख्य अंतर
- मोबाइल और वेब एसडीके, डेटा को सुरक्षित रखने के लिए Cloud Firestore Security Rules का इस्तेमाल करते हैं. वहीं, सर्वर एसडीके, डेटा को सुरक्षित रखने के लिए Identity Access Management (IAM) का इस्तेमाल करते हैं.
- Cloud Firestore Security Rules वाइल्डकार्ड का इस्तेमाल करने पर ही कैस्केड होते हैं. दस्तावेज़ और कलेक्शन, नियमों को इनहेरिट नहीं करते.
- अब आपको डेटा की पुष्टि अलग से करने की ज़रूरत नहीं है. ऐसा Realtime Database में किया जाता था.
- Cloud Firestore क्वेरी को लागू करने से पहले नियमों की जांच करता है, ताकि यह पक्का किया जा सके कि क्वेरी से मिले सभी डेटा के लिए, उपयोगकर्ता के पास सही ऐक्सेस हो.
पुराने डेटा को Cloud Firestore में ले जाना
अपने डेटा और सुरक्षा स्ट्रक्चर को Cloud Firestore के डेटा और सुरक्षा मॉडल से मैप करने के बाद, डेटा जोड़ना शुरू किया जा सकता है. अगर आपको अपने ऐप्लिकेशन को Realtime Database से Cloud Firestore पर ले जाने के बाद, पुराने डेटा के बारे में क्वेरी करनी है, तो अपने पुराने डेटा को नए Cloud Firestore डेटाबेस में एक्सपोर्ट करें. अगर आपको अपने ऐप्लिकेशन में Realtime Database और Cloud Firestore, दोनों का इस्तेमाल करना है, तो इस चरण को छोड़ा जा सकता है.
पुराने डेटा से नया डेटा ओवरराइट होने से बचाने के लिए, आपको पहले अपना पुराना डेटा जोड़ना चाहिए. अगर आपको दोनों डेटाबेस में एक साथ नया डेटा जोड़ना है, तो अगले चरण में बताए गए तरीके का इस्तेमाल करें. साथ ही, यह पक्का करें कि Cloud Functions के ज़रिए Cloud Firestore में जोड़े गए नए डेटा को प्राथमिकता दी जाए.
पुराने डेटा को Cloud Firestore पर माइग्रेट करने के लिए, यह तरीका अपनाएं:
- Realtime Database से अपना डेटा एक्सपोर्ट करें या हाल ही के बैकअप का इस्तेमाल करें.
- Firebase कंसोल में, डेटाबेस और स्टोरेज > रीयलटाइम डेटाबेस पर जाएं.
- डेटा टैब में जाकर, अपने डेटाबेस का रूट-लेवल नोड चुनें. इसके बाद, मेन्यू से JSON एक्सपोर्ट करें को चुनें.
Cloud Firestore में अपना नया डेटाबेस बनाएं और अपना डेटा जोड़ें.
अपने कुछ डेटा को Cloud Firestore में ट्रांसफ़र करते समय, इन रणनीतियों का इस्तेमाल करें:
- एक कस्टम स्क्रिप्ट लिखें, जो आपके डेटा को पोर्ट कर सके. हम इस स्क्रिप्ट के लिए कोई टेंप्लेट नहीं दे सकते, क्योंकि हर डेटाबेस की ज़रूरतें अलग-अलग होती हैं. हालांकि, Cloud Firestore हमारे Slack चैनल या Stack Overflow पर मौजूद विशेषज्ञ, आपकी स्क्रिप्ट की समीक्षा कर सकते हैं या आपकी खास स्थिति के लिए सलाह दे सकते हैं.
- डेटा को सीधे Cloud Firestore में लिखने के लिए, सर्वर एसडीके (Node.js, Java, Python या Go) का इस्तेमाल करें. सर्वर एसडीके सेट अप करने के निर्देशों के लिए, शुरू करें देखें.
- बड़े डेटा माइग्रेशन को तेज़ी से पूरा करने के लिए, बैच में लिखे गए डेटा का इस्तेमाल करें. साथ ही, एक नेटवर्क अनुरोध में ज़्यादा से ज़्यादा 500 कार्रवाइयां भेजें.
- Cloud Firestore दर की सीमाओं के तहत रहने के लिए, हर कलेक्शन के लिए 500 राइट/सेकंड तक के ऑपरेशन सीमित करें.
Cloud Firestore में नया डेटा जोड़ना
अपने डेटाबेस में एक जैसा डेटा रखने के लिए, दोनों डेटाबेस में नया डेटा रीयलटाइम में जोड़ें. Cloud Functions का इस्तेमाल करके, Cloud Firestore में लिखने की प्रोसेस को ट्रिगर करें. ऐसा तब करें, जब कोई क्लाइंट Realtime Database में लिखता है. पक्का करें कि Cloud Firestore, Cloud Functions से मिलने वाले नए डेटा को प्राथमिकता देता हो. साथ ही, यह भी पक्का करें कि यह प्राथमिकता, पुराने डेटा के माइग्रेशन के दौरान किए जा रहे किसी भी बदलाव से ज़्यादा हो.
एक ऐसा फ़ंक्शन बनाएं जो Cloud Firestore में नया या बदला हुआ डेटा लिख सके. ऐसा तब होना चाहिए, जब कोई क्लाइंट Realtime Database में डेटा लिखता है. Cloud Functions के लिए Realtime Database ट्रिगर के बारे में ज़्यादा जानें.
माइग्रेट किए गए डेटा के लिए, Cloud Firestore को अपना प्राइमरी डेटाबेस बनाएं
अगर आपने अपने कुछ डेटा के लिए, Cloud Firestore को मुख्य डेटाबेस के तौर पर इस्तेमाल करने का फ़ैसला किया है, तो पक्का करें कि आपने डेटा मिररिंग के उन सभी फ़ंक्शन को ध्यान में रखा हो जिन्हें आपने सेट अप किया है. साथ ही, अपने Cloud Firestore Security Rules की पुष्टि करें.
अगर आपने अपने डेटाबेस के बीच समानता बनाए रखने के लिए Cloud Functions का इस्तेमाल किया है, तो पक्का करें कि लूप में दोनों डेटाबेस में राइट ऑपरेशन को डुप्लीकेट न किया जा रहा हो. अपने फ़ंक्शन को एक ही डेटाबेस में डेटा सेव करने के लिए स्विच करें या फ़ंक्शन को पूरी तरह से हटा दें. साथ ही, Realtime Database से जुड़े ऐप्लिकेशन में माइग्रेट किए गए डेटा को सेव करने की सुविधा को धीरे-धीरे बंद करें. आपके ऐप्लिकेशन के लिए इसे कैसे मैनेज किया जाता है, यह आपकी ज़रूरतों और उपयोगकर्ताओं पर निर्भर करता है.
पुष्टि करें कि आपका डेटा सुरक्षित है. अपने Cloud Firestore Security Rules या आईएएम सेटअप की पुष्टि करें.