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