এই পৃষ্ঠায় Firebase Realtime Database ব্যবহারের সমস্যা সমাধানে সাহায্য এবং প্রায়শই জিজ্ঞাসিত প্রশ্নের উত্তর দেওয়া হয়েছে। আপনি যা খুঁজছেন তা যদি খুঁজে না পান বা অতিরিক্ত সাহায্যের প্রয়োজন হয়, তাহলে ফায়ারবেস সাপোর্টের সাথে যোগাযোগ করুন।
"একযোগে ডাটাবেস সংযোগ" বলতে কী বোঝায়?
একই সাথে একাধিক সংযোগ বলতে বোঝায় একটি মোবাইল ডিভাইস, ব্রাউজার ট্যাব বা সার্ভার অ্যাপ ডেটাবেসের সাথে সংযুক্ত থাকা। Firebase আপনার অ্যাপের ডেটাবেসে একই সাথে সংযোগের সংখ্যার উপর কঠোর সীমা আরোপ করে। এই সীমাগুলো Firebase এবং আমাদের ব্যবহারকারী উভয়কে অপব্যবহার থেকে রক্ষা করার জন্য রাখা হয়েছে।
স্পার্ক প্রাইসিং প্ল্যানের সীমা ১০০ এবং এটি বাড়ানো যায় না। ব্লেজ প্রাইসিং প্ল্যানে প্রতি ডেটাবেসে ২,০০,০০০ যুগপৎ সংযোগের সীমা রয়েছে।
এই সীমাটি আপনার অ্যাপের মোট ব্যবহারকারীর সংখ্যার সমান নয়, কারণ আপনার ব্যবহারকারীরা সবাই একসাথে সংযোগ স্থাপন করেন না। আপনার যদি ২,০০,০০০-এর বেশি যুগপৎ সংযোগের প্রয়োজন হয়, তবে ‘একাধিক ডেটাবেসের সাথে স্কেল করুন’ (Scale with multiple databases) অংশে থাকা বিকল্পগুলো দেখুন।
আমার Realtime Database ব্যবহারের সীমা অতিক্রম করলে আমি কী করতে পারি?
আপনি যদি Firebase কনসোলে এমন কোনো ইমেল অ্যালার্ট বা নোটিফিকেশন পেয়ে থাকেন যে আপনি আপনার Realtime Database ব্যবহারের সীমা অতিক্রম করেছেন, তবে আপনি যে ব্যবহারের সীমা অতিক্রম করেছেন তার উপর ভিত্তি করে এর সমাধান করতে পারেন। আপনার Realtime Database ব্যবহার দেখতে, Firebase কনসোলের Realtime Database ইউসেজ ড্যাশবোর্ডে যান।
আপনার ডাউনলোডের সীমা অতিক্রম হয়ে গেলে, আপনি আপনার Firebase প্রাইসিং প্ল্যান আপগ্রেড করতে পারেন অথবা আপনার পরবর্তী বিলিং চক্রের শুরুতে ডাউনলোডের সীমা পুনরায় সেট হওয়া পর্যন্ত অপেক্ষা করতে পারেন। আপনার ডাউনলোড কমাতে, নিম্নলিখিত পদক্ষেপগুলি অনুসরণ করুন:
- আপনার লিসেন অপারেশনগুলো যে ডেটা ফেরত দেয়, তা সীমিত করতে কোয়েরি যোগ করুন।
- ইনডেক্স করা হয়নি এমন কোয়েরিগুলো পরীক্ষা করুন।
- এমন লিসেনার ব্যবহার করুন যা শুধু ডেটার আপডেট ডাউনলোড করে — উদাহরণস্বরূপ,
once পরিবর্তে on । - অননুমোদিত ডাউনলোড আটকাতে নিরাপত্তা বিধি ব্যবহার করুন।
আপনার স্টোরেজ সীমা অতিক্রম করলে, পরিষেবা বিঘ্ন এড়াতে আপনার প্রাইসিং প্ল্যান আপগ্রেড করুন। আপনার ডাটাবেসে ডেটার পরিমাণ কমাতে, নিম্নলিখিত পদক্ষেপগুলি চেষ্টা করুন:
- পর্যায়ক্রমিক পরিচ্ছন্নতার কাজগুলো চালান।
- আপনার ডাটাবেসে থাকা পুনরাবৃত্ত ডেটা হ্রাস করুন।
আপনার স্টোরেজ বরাদ্দে ডেটা মুছে ফেলার বিষয়টি প্রতিফলিত হতে কিছুটা সময় লাগতে পারে।
আপনার ডাটাবেসে একই সাথে একাধিক সংযোগ ব্যবহারের সীমা অতিক্রম করলে , পরিষেবা বিঘ্নিত হওয়া এড়াতে আপনার প্ল্যান আপগ্রেড করুন। আপনার ডাটাবেসে একই সাথে একাধিক সংযোগ পরিচালনা করতে, ব্যবহারকারীদের রিয়েল-টাইম সংযোগের প্রয়োজন না হলে REST API ব্যবহার করে সংযোগ করার চেষ্টা করুন।
Realtime Database জন্য স্পার্ক প্রাইসিং প্ল্যানের স্টোরেজ বা ডাউনলোড সীমা অতিক্রম করলে কী হবে?
আপনাকে একটি অনুমানযোগ্য মূল্য দেওয়ার জন্য, আপনার প্রজেক্টটি স্পার্ক প্রাইসিং প্ল্যানে থাকলে আপনার জন্য উপলব্ধ রিসোর্স সীমিত করা থাকে। এর মানে হলো, কোনো মাসে আপনি প্ল্যানের কোনো সীমা অতিক্রম করলে, আরও রিসোর্স ব্যবহার এবং অতিরিক্ত চার্জ এড়ানোর জন্য আপনার অ্যাপটি বন্ধ করে দেওয়া হবে।
Realtime Database জন্য স্পার্ক প্রাইসিং প্ল্যানের একযোগে সংযোগের সীমা অতিক্রম করলে কী হবে?
যখন আপনার অ্যাপ Spark প্রাইসিং প্ল্যানের কনকারেন্সি লিমিটে পৌঁছে যাবে, তখন বিদ্যমান সংযোগগুলোর মধ্যে কয়েকটি বন্ধ না করা পর্যন্ত পরবর্তী যেকোনো সংযোগ প্রত্যাখ্যান করা হবে। যেসব ব্যবহারকারী সংযুক্ত আছেন, তাদের জন্য অ্যাপটি কাজ করতে থাকবে।
স্বয়ংক্রিয় ব্যাকআপ বলতে কী বোঝায়? আপনারা কি Realtime Database জন্য ঘণ্টাভিত্তিক ব্যাকআপের সুবিধা দেন?
স্বয়ংক্রিয় ব্যাকআপ হলো ব্লেজ প্রাইসিং প্ল্যানে থাকা প্রোজেক্টগুলোর জন্য একটি উন্নত ফিচার। এই ফিচারটি আপনার Firebase Realtime Database ডেটা দিনে একবার ব্যাকআপ করে এবং তা Google Cloud Storage আপলোড করে।
আমরা ঘণ্টাভিত্তিক ব্যাকআপের ব্যবস্থা করি না।
সেপ্টেম্বর ২০১৬ থেকে মার্চ ২০১৭-এর মধ্যে আমার Realtime Database ব্যান্ডউইথ কেন গড়ের চেয়ে কম দেখানো হয়েছিল?
ব্যান্ডউইথ গণনার জন্য, আমরা সাধারণত SSL এনক্রিপশন ওভারহেড (OSI মডেলের লেয়ার ৫-এর উপর ভিত্তি করে) অন্তর্ভুক্ত করি। তবে, ২০১৬ সালের সেপ্টেম্বরে , আমরা একটি বাগ চালু করি যার ফলে আমাদের ব্যান্ডউইথ রিপোর্টিং এনক্রিপশন ওভারহেডকে উপেক্ষা করতে শুরু করে। এর ফলে কয়েক মাসের জন্য আপনার অ্যাকাউন্টে দেখানো ব্যান্ডউইথ এবং বিল কৃত্রিমভাবে কম হয়ে থাকতে পারে।
আমরা ২০১৭ সালের মার্চের শেষের দিকে বাগটির একটি সমাধান প্রকাশ করেছি, যার ফলে ব্যান্ডউইথ রিপোর্টিং এবং বিলিং তাদের স্বাভাবিক অবস্থায় ফিরে এসেছে।
