আপনি আপনার অ্যাপে Firebase Realtime Database এবং Cloud Firestore উভয়ই ব্যবহার করতে পারেন এবং আপনার প্রয়োজন অনুসারে প্রতিটি ডেটাবেস সলিউশনের সুবিধাগুলো কাজে লাগাতে পারেন। উদাহরণস্বরূপ, আপনি Realtime Database প্রেজেন্স সাপোর্ট কাজে লাগাতে চাইতে পারেন, যেমনটি Cloud Firestore বিল্ড প্রেজেন্স অংশে বর্ণনা করা হয়েছে।
ডাটাবেসগুলোর মধ্যে পার্থক্য সম্পর্কে আরও জানুন।
Cloud Firestore ডেটা স্থানান্তর করা হচ্ছে
আপনি যদি আপনার কিছু ডেটা Realtime Database থেকে Cloud Firestore স্থানান্তর করার সিদ্ধান্ত নিয়ে থাকেন, তবে নিম্নলিখিত প্রক্রিয়াটি বিবেচনা করুন। যেহেতু প্রতিটি ডেটাবেসের নিজস্ব চাহিদা এবং কাঠামোগত বিবেচ্য বিষয় রয়েছে, তাই এর কোনো স্বয়ংক্রিয় স্থানান্তর পথ নেই। এর পরিবর্তে, আপনি এই সাধারণ ক্রমটি অনুসরণ করতে পারেন:
Realtime Database থেকে Cloud Firestore ডেটা স্ট্রাকচার এবং সিকিউরিটি রুলস ম্যাপ করুন। Realtime Database এবং Cloud Firestore উভয়ই ফায়ারবেস অথেনটিকেশনের উপর নির্ভর করে, তাই আপনার অ্যাপের জন্য ইউজার অথেনটিকেশন পরিবর্তন করার প্রয়োজন নেই। তবে, সিকিউরিটি রুলস এবং ডেটা মডেল ভিন্ন এবং ক্লাউড ফায়ারস্টোরে ডেটা স্থানান্তর শুরু করার আগে এই পার্থক্যগুলো সতর্কতার সাথে বিবেচনা করা গুরুত্বপূর্ণ।
ঐতিহাসিক ডেটা স্থানান্তর করুন। আপনি যখন Cloud Firestore আপনার নতুন ডেটা কাঠামো সেট আপ করছেন, তখন আপনি Realtime Database থেকে বিদ্যমান ডেটা আপনার নতুন Cloud Firestore ইনস্ট্যান্সে ম্যাপ এবং স্থানান্তর করতে পারেন। তবে, আপনি যদি আপনার অ্যাপে উভয় ডেটাবেস ব্যবহার করেন, তাহলে Realtime Database থেকে ঐতিহাসিক ডেটা সরানোর প্রয়োজন নেই।
রিয়েলটাইমে ফায়ারস্টোরে নতুন ডেটা মিরর করুন। Realtime Database ডেটা যুক্ত হওয়ার সাথে সাথে আপনার নতুন Cloud Firestore ডেটাবেসে নতুন ডেটা লেখার জন্য ক্লাউড ফাংশন ব্যবহার করুন।
স্থানান্তরিত ডেটার জন্য 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 ...]
}
ডকুমেন্টগুলোর সর্বোচ্চ আকার ১ মেগাবাইট, আর একারণেই ল্যান্ডমার্কগুলোকে একটি সাব-কালেকশন হিসেবে সংরক্ষণ করা হয়, যাতে প্রতিটি শহরের ডকুমেন্ট ছোট থাকে এবং নেস্টেড লিস্ট দিয়ে ডকুমেন্টগুলো স্ফীত না হয়ে যায়।
Cloud Firestore উন্নত কোয়েরি করার ক্ষমতা সাধারণ অ্যাক্সেস প্যাটার্নের জন্য ডেটা ডুপ্লিকেট করার প্রয়োজনীয়তা কমিয়ে দেয়। উদাহরণস্বরূপ, সিটি গাইড অ্যাপের একটি স্ক্রিনের কথা ভাবুন যেখানে জনসংখ্যার ক্রমানুসারে সমস্ত রাজধানী শহর দেখানো হয়। Realtime Database , এটি করার সবচেয়ে কার্যকর উপায় হলো রাজধানী শহরগুলির একটি পৃথক তালিকা বজায় রাখা, যা cities তালিকা থেকে ডেটা ডুপ্লিকেট করে, যেমনটি নিচে দেখানো হলো:
{
cities: {
// ...
},
capital-cities: {
// ...
}
}
Cloud Firestore , আপনি জনসংখ্যার ক্রমানুসারে রাজধানী শহরগুলির একটি তালিকা একটি একক কোয়েরি হিসাবে প্রকাশ করতে পারেন:
db.collection('cities')
.where('capital', '==', true)
.orderBy('population')
Cloud Firestore ডেটা মডেল সম্পর্কে আরও পড়ুন এবং আপনার Cloud Firestore ডেটাবেস কীভাবে গঠন করবেন সে সম্পর্কে আরও ধারণা পেতে আমাদের সলিউশনগুলো দেখুন।
আপনার ডেটা সুরক্ষিত করুন
আপনি অ্যান্ড্রয়েড, অ্যাপল বা ওয়েব ক্লায়েন্টের জন্য Cloud Firestore Security Rules ব্যবহার করুন, কিংবা সার্ভারের জন্য আইডেন্টিটি অ্যাক্সেস ম্যানেজমেন্ট (IAM) ব্যবহার করুন, Cloud Firestore এবং Realtime Database উভয় জায়গাতেই আপনার ডেটা সুরক্ষিত আছে কিনা তা নিশ্চিত করুন। উভয় ডেটাবেসের জন্যই ব্যবহারকারীর প্রমাণীকরণ ‘অথেনটিকেশন’ দ্বারা পরিচালিত হয়, তাই Cloud Firestore ব্যবহার শুরু করার সময় আপনার ‘অথেনটিকেশন’-এর বাস্তবায়নে কোনো পরিবর্তন আনার প্রয়োজন নেই।
বিবেচনা করার মতো প্রধান পার্থক্যগুলো
- মোবাইল ও ওয়েব এসডিকে-গুলো ডেটা সুরক্ষিত করার জন্য Cloud Firestore Security Rules ব্যবহার করে, অন্যদিকে সার্ভার এসডিকে-গুলো আইডেন্টিটি অ্যাক্সেস ম্যানেজমেন্ট (আইএএম) ব্যবহার করে।
- ওয়াইল্ডকার্ড ব্যবহার না করলে 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 কনসোলের Realtime Database বিভাগে যান।
- ডেটা ট্যাব থেকে, আপনার ডাটাবেসের রুট-লেভেল নোডটি নির্বাচন করুন এবং মেনু থেকে এক্সপোর্ট JSON নির্বাচন করুন।
Cloud Firestore আপনার নতুন ডেটাবেস তৈরি করুন এবং আপনার ডেটা যোগ করুন ।
আপনার কিছু ডেটা Cloud Firestore স্থানান্তর করার সময় নিম্নলিখিত কৌশলগুলো বিবেচনা করুন:
- একটি কাস্টম স্ক্রিপ্ট লিখুন যা আপনার ডেটা স্থানান্তর করবে। যদিও আমরা এই স্ক্রিপ্টের জন্য কোনো টেমপ্লেট দিতে পারি না, কারণ প্রতিটি ডেটাবেসের নিজস্ব চাহিদা থাকে, আমাদের স্ল্যাক চ্যানেলে বা স্ট্যাক ওভারফ্লোতে থাকা Cloud Firestore বিশেষজ্ঞরা আপনার স্ক্রিপ্টটি পর্যালোচনা করতে পারেন অথবা আপনার নির্দিষ্ট পরিস্থিতির জন্য পরামর্শ দিতে পারেন।
- সরাসরি Cloud Firestore ডেটা লেখার জন্য সার্ভার SDK (Node.js, Java, Python, বা Go) ব্যবহার করুন। সার্ভার SDK সেট আপ করার নির্দেশাবলীর জন্য, 'Get Started' দেখুন।
- বৃহৎ ডেটা স্থানান্তর দ্রুত করার জন্য, ব্যাচড রাইট ব্যবহার করুন এবং একটিমাত্র নেটওয়ার্ক অনুরোধে ৫০০টি পর্যন্ত অপারেশন পাঠান।
- Cloud Firestore রেট লিমিটের মধ্যে থাকতে, প্রতিটি কালেকশনের জন্য অপারেশন প্রতি সেকেন্ডে ৫০০ রাইটে সীমিত রাখুন।
Cloud Firestore নতুন ডেটা যোগ করুন
আপনার ডেটাবেসগুলোর মধ্যে সামঞ্জস্য বজায় রাখতে, উভয় ডেটাবেসে রিয়েলটাইমে নতুন ডেটা যোগ করুন। যখনই কোনো ক্লায়েন্ট Realtime Database লেখে, তখন Cloud Firestore একটি রাইট ট্রিগার করতে Cloud Functions ব্যবহার করুন। নিশ্চিত করুন যে, আপনার হিস্টোরিক্যাল ডেটা মাইগ্রেশন থেকে করা যেকোনো রাইটের চেয়ে Cloud Firestore Cloud Functions থেকে আসা নতুন ডেটাকে অগ্রাধিকার দেয়।
যখনই কোনো ক্লায়েন্ট Realtime Database ডেটা লেখে, তখন নতুন বা পরিবর্তনশীল ডেটা Cloud Firestore লেখার জন্য একটি ফাংশন তৈরি করুন। Cloud Functions জন্য Realtime Database ট্রিগার সম্পর্কে আরও জানুন।
স্থানান্তরিত ডেটার জন্য Cloud Firestore আপনার প্রাথমিক ডেটাবেস হিসেবে ব্যবহার করুন।
আপনি যদি আপনার কিছু ডেটার জন্য প্রাথমিক ডেটাবেস হিসেবে Cloud Firestore ব্যবহার করার সিদ্ধান্ত নিয়ে থাকেন, তাহলে আপনার সেট আপ করা যেকোনো ডেটা-মিররিং ফাংশনের বিষয়টি নিশ্চিত করুন এবং আপনার Cloud Firestore Security Rules যাচাই করে নিন।
আপনি যদি আপনার ডেটাবেসগুলোর মধ্যে সামঞ্জস্য বজায় রাখতে Cloud Functions ব্যবহার করে থাকেন, তবে নিশ্চিত করুন যে আপনি একটি লুপের মধ্যে উভয় ডেটাবেসে একই রাইট অপারেশন বারবার করছেন না। আপনার ফাংশনটিকে একটিমাত্র ডেটাবেসে লেখার জন্য পরিবর্তন করুন, অথবা ফাংশনটি সম্পূর্ণরূপে সরিয়ে ফেলুন এবং Realtime Database সাথে সংযুক্ত অ্যাপগুলোতে স্থানান্তরিত ডেটার জন্য রাইট কার্যকারিতা পর্যায়ক্রমে বন্ধ করা শুরু করুন। আপনার অ্যাপের জন্য আপনি এটি কীভাবে সামলাবেন তা আপনার নির্দিষ্ট প্রয়োজন এবং ব্যবহারকারীদের উপর নির্ভর করে।
আপনার ডেটা যথাযথভাবে সুরক্ষিত আছে কিনা তা যাচাই করুন। আপনার Cloud Firestore Security Rules বা আইএএম সেটআপ যাচাই করুন।