আপনার ডাটাবেসে সংরক্ষণ করা ডেটা এবং OSI মডেলের সেশন লেয়ার (লেয়ার 5) এ সমস্ত আউটবাউন্ড নেটওয়ার্ক ট্র্যাফিকের জন্য ফায়ারবেস বিল করে। স্টোরেজ প্রতি GB/মাসের জন্য $5 হারে বিল করা হয়, যা প্রতিদিন মূল্যায়ন করা হয়। বিলিং আপনার ডাটাবেসের অবস্থান দ্বারা প্রভাবিত হয় না। আউটবাউন্ড ট্র্যাফিকের মধ্যে সমস্ত ডাটাবেস অপারেশন থেকে সংযোগ এবং এনক্রিপশন ওভারহেড এবং ডাটাবেস রিডের মাধ্যমে ডাউনলোড করা ডেটা অন্তর্ভুক্ত থাকে। ডাটাবেস রিড এবং রাইট উভয়ই আপনার বিলে সংযোগ খরচের কারণ হতে পারে। আপনার ডাটাবেসে এবং থেকে সমস্ত ট্র্যাফিক, নিরাপত্তা নিয়ম দ্বারা অস্বীকৃত অপারেশন সহ, বিলযোগ্য খরচের দিকে পরিচালিত করে।
বিল করা ট্র্যাফিকের কিছু সাধারণ উদাহরণের মধ্যে রয়েছে:
- ডেটা ডাউনলোড করা হয়েছে: যখন ক্লায়েন্টরা আপনার ডাটাবেস থেকে ডেটা পায়, তখন Firebase ডাউনলোড করা ডেটার জন্য চার্জ নেয়। সাধারণত, এটি আপনার ব্যান্ডউইথ খরচের বেশিরভাগ অংশ তৈরি করে, তবে এটি আপনার বিলের একমাত্র কারণ নয়।
- প্রোটোকল ওভারহেড: একটি সেশন স্থাপন এবং রক্ষণাবেক্ষণের জন্য সার্ভার এবং ক্লায়েন্টদের মধ্যে কিছু অতিরিক্ত ট্র্যাফিক প্রয়োজন। অন্তর্নিহিত প্রোটোকলের উপর নির্ভর করে, এই ট্র্যাফিকের মধ্যে অন্তর্ভুক্ত থাকতে পারে: ফায়ারবেস রিয়েলটাইম ডাটাবেসের রিয়েলটাইম প্রোটোকল ওভারহেড, ওয়েবসকেট ওভারহেড এবং HTTP হেডার ওভারহেড। প্রতিবার যখন কোনও সংযোগ স্থাপন করা হয়, তখন এই ওভারহেড, যেকোনো SSL এনক্রিপশন ওভারহেডের সাথে মিলিত হয়ে, সংযোগ খরচে অবদান রাখে। যদিও এটি একটি একক অনুরোধের জন্য খুব বেশি ব্যান্ডউইথ নয়, তবে আপনার পেলোডগুলি যদি ছোট হয় বা আপনি ঘন ঘন, সংক্ষিপ্ত সংযোগ করেন তবে এটি আপনার বিলের একটি উল্লেখযোগ্য অংশ হতে পারে।
- SSL এনক্রিপশন ওভারহেড: নিরাপদ সংযোগের জন্য প্রয়োজনীয় SSL এনক্রিপশন ওভারহেডের সাথে সম্পর্কিত একটি খরচ রয়েছে। গড়ে, প্রাথমিক হ্যান্ডশেকের জন্য এই খরচ প্রায় 3.5KB এবং প্রতিটি বহির্গামী বার্তায় TLS রেকর্ড হেডারের জন্য প্রায় দশ বাইট। বেশিরভাগ অ্যাপের জন্য, এটি আপনার বিলের একটি ছোট শতাংশ। তবে, যদি আপনার নির্দিষ্ট ক্ষেত্রে প্রচুর SSL হ্যান্ডশেকের প্রয়োজন হয় তবে এটি একটি বড় শতাংশ হতে পারে। উদাহরণস্বরূপ, যে ডিভাইসগুলি TLS সেশন টিকিট সমর্থন করে না সেগুলিতে প্রচুর সংখ্যক SSL সংযোগ হ্যান্ডশেকের প্রয়োজন হতে পারে।
- Firebase কনসোল ডেটা: যদিও এটি সাধারণত Realtime Database খরচের একটি উল্লেখযোগ্য অংশ নয়, তবুও Firebase কনসোল থেকে আপনি যে ডেটা পড়েন এবং লেখেন তার জন্য ফায়ারবেস চার্জ করে।
আপনার বিল করা ব্যবহারের হিসাব করুন
আপনার বর্তমান Realtime Database সংযোগ এবং ডেটা ব্যবহার দেখতে, Firebase কনসোলে "ব্যবহার" ট্যাবটি দেখুন। আপনি বর্তমান বিলিং সময়কাল, গত 30 দিন বা গত 24 ঘন্টার ব্যবহার পরীক্ষা করতে পারেন।
Firebase নিম্নলিখিত মেট্রিক্সের ব্যবহারের পরিসংখ্যান দেখায়:
- সংযোগ: আপনার ডাটাবেসে একযোগে, বর্তমানে খোলা, রিয়েলটাইম সংযোগের সংখ্যা। এর মধ্যে নিম্নলিখিত রিয়েলটাইম সংযোগগুলি অন্তর্ভুক্ত রয়েছে: ওয়েবসকেট, দীর্ঘ পোলিং এবং HTML সার্ভার-প্রেরিত ইভেন্ট। এতে RESTful অনুরোধগুলি অন্তর্ভুক্ত নয়।
- স্টোরেজ: আপনার ডাটাবেসে কত ডেটা সংরক্ষণ করা হয়েছে। এর মধ্যে ফায়ারবেস হোস্টিং বা অন্যান্য ফায়ারবেস পণ্যের মাধ্যমে সংরক্ষণ করা ডেটা অন্তর্ভুক্ত নয়।
- ডাউনলোড: প্রোটোকল এবং এনক্রিপশন ওভারহেড সহ আপনার ডাটাবেস থেকে ডাউনলোড করা সমস্ত বাইট।
- লোড: এই গ্রাফটি দেখায় যে আপনার ডাটাবেসের কতটা অংশ ব্যবহার করা হচ্ছে, অনুরোধগুলি প্রক্রিয়াকরণ করা হচ্ছে, নির্দিষ্ট ১ মিনিটের ব্যবধানে। আপনার ডাটাবেস ১০০% এর কাছাকাছি পৌঁছানোর সাথে সাথে আপনি কর্মক্ষমতা সংক্রান্ত সমস্যা দেখতে পেতে পারেন।
ব্যবহার অপ্টিমাইজ করুন
আপনার ডাটাবেস ব্যবহার এবং ব্যান্ডউইথ খরচ অপ্টিমাইজ করার জন্য আপনি কয়েকটি সেরা অনুশীলন ব্যবহার করতে পারেন।
- নেটিভ SDK ব্যবহার করুন: যখনই সম্ভব, REST API-এর পরিবর্তে আপনার অ্যাপের প্ল্যাটফর্মের সাথে সামঞ্জস্যপূর্ণ SDK ব্যবহার করুন। SDK-গুলি খোলা সংযোগ বজায় রাখে, SSL এনক্রিপশন খরচ কমায় যা সাধারণত REST API-এর সাথে যুক্ত হয়।
- বাগ পরীক্ষা করুন: যদি আপনার ব্যান্ডউইথের খরচ অপ্রত্যাশিতভাবে বেশি হয়, তাহলে যাচাই করুন যে আপনার অ্যাপটি আপনার মূল পরিকল্পনার চেয়ে বেশি ডেটা সিঙ্ক করছে না বা ঘন ঘন সিঙ্ক করছে না। সমস্যাগুলি চিহ্নিত করতে, আপনার রিড অপারেশন পরিমাপ করতে প্রোফাইলার টুল ব্যবহার করুন এবং Android , Objective-C এবং Web SDK-তে ডিবাগ লগিং চালু করুন। আপনার অ্যাপের ব্যাকগ্রাউন্ড এবং সিঙ্ক প্রক্রিয়াগুলি পরীক্ষা করে দেখুন যাতে নিশ্চিত হন যে সবকিছু আপনার ইচ্ছামতো কাজ করছে।
- সংযোগ হ্রাস করুন: যদি সম্ভব হয়, আপনার সংযোগ ব্যান্ডউইথটি অপ্টিমাইজ করার চেষ্টা করুন। ঘন ঘন, ছোট REST অনুরোধগুলি নেটিভ SDK ব্যবহার করে একক, অবিচ্ছিন্ন সংযোগের চেয়ে বেশি ব্যয়বহুল হতে পারে। আপনি যদি REST API ব্যবহার করেন, তাহলে HTTP keep-alive বা server-sent events ব্যবহার করার কথা বিবেচনা করুন, যা SSL হ্যান্ডশেকের খরচ কমাতে পারে।
- TLS সেশন টিকিট ব্যবহার করুন: TLS সেশন টিকিট ইস্যু করে পুনরায় চালু সংযোগের ক্ষেত্রে SSL এনক্রিপশনের ওভারহেড খরচ কমাতে পারেন। এটি বিশেষভাবে সহায়ক যদি আপনার ডাটাবেসে ঘন ঘন, নিরাপদ সংযোগের প্রয়োজন হয়।
- ইনডেক্স কোয়েরি: আপনার ডেটা ইনডেক্স করার ফলে কোয়েরির জন্য ব্যবহৃত মোট ব্যান্ডউইথ কমে যায়, যার দ্বিগুণ সুবিধা হল আপনার খরচ কমানো এবং আপনার ডাটাবেসের কর্মক্ষমতা বৃদ্ধি করা। আপনার ডাটাবেসে আনইনডেক্সড কোয়েরি খুঁজে পেতে প্রোফাইলার টুল ব্যবহার করুন।
- আপনার শ্রোতাদের অপ্টিমাইজ করুন: আপনার শ্রোতাদের যে ডেটা ফেরত দেয় তা সীমিত করতে কোয়েরি যোগ করুন এবং এমন শ্রোতাদের ব্যবহার করুন যারা শুধুমাত্র ডেটাতে আপডেট ডাউনলোড করে — উদাহরণস্বরূপ,
once()এর পরিবর্তেon()()। অতিরিক্তভাবে, আপনার শ্রোতাদের যতটা সম্ভব পথের নিচে রাখুন যাতে তারা যে পরিমাণ ডেটা সিঙ্ক করে তা সীমিত করতে পারে। - স্টোরেজ খরচ কমানো: পর্যায়ক্রমিক পরিষ্কারের কাজ চালান এবং আপনার ডাটাবেসে যেকোনো ডুপ্লিকেট ডেটা কমিয়ে আনুন।
- নিয়ম ব্যবহার করুন: আপনার ডাটাবেসে যেকোনো সম্ভাব্য ব্যয়বহুল, অননুমোদিত ক্রিয়াকলাপ প্রতিরোধ করুন। উদাহরণস্বরূপ, Firebase Realtime Database Security Rules ব্যবহার করলে এমন পরিস্থিতি এড়ানো যেতে পারে যেখানে একজন ক্ষতিকারক ব্যবহারকারী বারবার আপনার সম্পূর্ণ ডাটাবেস ডাউনলোড করে। Firebase Realtime Database Rules ব্যবহার সম্পর্কে আরও জানুন।
আপনার অ্যাপের জন্য সেরা অপ্টিমাইজেশন পরিকল্পনা আপনার নির্দিষ্ট ব্যবহারের ক্ষেত্রে নির্ভর করে। যদিও এটি সেরা অনুশীলনের একটি সম্পূর্ণ তালিকা নয়, আপনি আমাদের স্ল্যাক চ্যানেল বা স্ট্যাক ওভারফ্লোতে Firebase বিশেষজ্ঞদের কাছ থেকে আরও পরামর্শ এবং টিপস পেতে পারেন।