ডাটাবেসের বিল হোক, তারা আসলে যতটুকু ব্যবহার করে

Mythex-এর প্রতিটি অ্যাপ যার ডেটা সংরক্ষণ দরকার, সেটি পায় নিজস্ব একটি Postgres ডাটাবেস, এবং একটি প্রকাশিত অ্যাপের ডাটাবেস ব্যবহার সেই একই ক্রেডিট ব্যালেন্স থেকে কাটা হয় যা দিয়ে তৈরির কাজ হয়। সেপ্টেম্বরের শেষ পর্যন্ত আমরা অ্যাপের সার্ভার কতক্ষণ চলেছে তা দেখে সেই ব্যবহার আন্দাজ করতাম। আন্দাজটি এমনভাবে ভুল প্রমাণিত হলো যা গুরুত্বপূর্ণ ছিল, তাই আমরা এটি বদলেছি: এখন প্রতিটি ডাটাবেস তার প্রদানকারীর মাপা কম্পিউট অনুযায়ী বিল হয়, একটি সম্পন্ন ঘণ্টা ধরে, এবং প্রতিটি ঘণ্টা কেবল একবারই বিল হতে পারে।

ডাটাবেসগুলো কীভাবে কাজ করে

প্রতিটি ডাটাবেস চলে সার্ভারলেস Postgres-এ, যা শূন্যে নামে: কিছুক্ষণ নিষ্ক্রিয় থাকলে এটি ঘুমিয়ে পড়ে, এবং পরের কোয়েরিতে জেগে ওঠে। জেগে থাকার সময় এটি লোড অনুযায়ী তার কম্পিউট বাড়াতে-কমাতে পারে। এভাবেই "প্রতি অ্যাপে একটি ডাটাবেস" সাশ্রয়ী হয় — বেশিরভাগ অ্যাপ বেশিরভাগ সময় শান্ত থাকে, আর ঘুমন্ত ডাটাবেসের খরচ প্রায় শূন্য।

এর মানে, ডাটাবেসের খরচ নির্ভর করে দুটি জিনিসের উপর, যা বাইরে থেকে আমরা দেখতে পারি না: এটি কতক্ষণ জেগে ছিল এবং জেগে থাকার সময় এটি কত বড় ছিল।

আন্দাজে কী ভুল ছিল

আমাদের আগের মিটারে একটি অনুমান ছিল: একটি প্রকাশিত অ্যাপের সার্ভার যতটা ঘণ্টা চলে, প্রতি ঘণ্টায় ডাটাবেসের জন্য সবচেয়ে ছোট কম্পিউট আকারের খরচ ধরা হতো।

সেটি তিনভাবে ভুল ছিল:

1. আকার ভুল ছিল। ডাটাবেসগুলো আসলে আন্দাজে ধরা আকারের চেয়ে বড় ডিফল্ট আকারে চলছিল।
2. ডাটাবেস স্বয়ংক্রিয়ভাবে মাপ বদলায়। লোডের নিচে এগুলো বড় হয়, আর আন্দাজ তা কখনো দেখেনি।
3. ডাটাবেস অ্যাপ সার্ভারের সঙ্গে চলে না। কেউ কোয়েরি করলেই ডাটাবেস জেগে থাকে — অ্যাপ, একটি নির্ধারিত কাজ, বা একটি স্ক্রিপ্ট যা বারবার জিজ্ঞাসা করে — অ্যাপের সার্ভার চালু থাকুক বা না থাকুক।

নিট ফল: আন্দাজটি ব্যবহারকারীদের কাছ থেকে ডাটাবেসের আসল খরচের প্রায় অর্ধেক নিচ্ছিল। এটি আমাদের জন্য টেকসই ছিল না, আর অ্যাপে দেখানো ব্যবহারের সংখ্যাগুলোও মানুষ যা ভাবত তা বোঝাত না।

আন্দাজ না করে মাপা

আমাদের ডাটাবেস প্রদানকারী প্রতিটি প্রজেক্টের কম্পিউট-ইউনিট-সেকেন্ড প্রতি ঘণ্টায় জানায় — অর্থাৎ আসলে কতটা কম্পিউট ব্যবহৃত হয়েছে, আকারসহ। তাই মিটারটি এখন এভাবে কাজ করে:

1. ডাটাবেসওয়ালা প্রতিটি প্রকাশিত অ্যাপের জন্য, লাইভ হওয়ার পর থেকে প্রতিটি সম্পন্ন ঘণ্টার মাপা ব্যবহার আনা হয়।
2. সেই ব্যবহারকে প্রদানকারীর দামে খরচে রূপান্তর করা হয়, প্ল্যানের হার প্রয়োগ করা হয়, এবং অ্যাপ-মালিকের ক্রেডিট থেকে কাটা হয়।
3. প্রতিবার সর্বোচ্চ এক দিন পিছনে তাকানো হয়, যাতে আমাদের API পুনরায় চালু হওয়ার সময় বাদ পড়া ঘণ্টাগুলো পরে বিল হয়।

স্টোরেজ আলাদাভাবে বিল হয়, আকার অনুযায়ী, কারণ এটি কার্যকলাপের উপর নির্ভর করে না।

একই ঘণ্টা দু'বার কখনো বিল না হওয়া

একাধিক সার্ভারে চলে এবং ক্র্যাশ করে আবার চেষ্টা করতে পারে এমন একটি বিলিং মিটারকে সাবধান থাকতে হয় যাতে দুইবার বিল না হয়। প্রতিটি ডাটাবেসের প্রতিটি ঘণ্টা বিল হওয়ার আগে নিজস্ব একটি ডাটাবেস রো-তে দাবি করা হয়, যেখানে (ডাটাবেস, ঘণ্টা) জোড়ায় একটি ইউনিকনেস সীমাবদ্ধতা আছে। দুটি সার্ভার, বা একটি পুনঃচেষ্টা, একই ঘণ্টা বিল করতে গেলে কেবল একটি দাবিই সফল হয়।

বিরল ব্যর্থতার ক্ষেত্রে আমরা একটি ইচ্ছাকৃত সিদ্ধান্ত নিয়েছি: যদি ঘণ্টা দাবি করার পর কিন্তু বিল করার আগে প্রক্রিয়াটি ক্র্যাশ করে, সেই ঘণ্টা দাবি করা কিন্তু অবিল রয়ে যায়। বিরল ক্র্যাশে সামান্য রাজস্ব হারানো, কারও কাছ থেকে দুইবার টাকা নেওয়ার চেয়ে ভালো।

আর মাপা বিলিং চালু হলে এটি পরের পূর্ণ ঘণ্টা থেকে শুরু হয়েছে। তার আগের ঘণ্টাগুলো পুরনো আন্দাজে আগেই বিল হয়ে গেছে; সেগুলো মাপা তথ্য দিয়ে আবার বিল করলে সেই সময়টুকু দুইবার বিল হতো।

Mythex-এ তৈরি করলে এর মানে কী

• আপনার ডাটাবেস বিল এখন আপনার ডাটাবেস কী করেছে তা প্রতিফলিত করে। কম ব্যবহৃত অ্যাপের খরচ খুব কম; যে অ্যাপ তার ডাটাবেসে ক্রমাগত কোয়েরি করে, সেটি ডাটাবেসকে জাগিয়ে রাখবে এবং বেশি খরচ হবে।
• সবচেয়ে বড় লিভার হলো আপনার অ্যাপ ডাটাবেস কীভাবে ব্যবহার করে। ডাটাবেসকে প্রতি কয়েক সেকেন্ডে পোল করলে সেটি সারাক্ষণ জেগে থাকে। AI-কে দিয়ে প্রয়োজনমতো ডেটা আনালে, বা ক্যাশ করলে, ডাটাবেস ঘুমাতে পারে। ডাটাবেস কী, তার মূল বিষয়গুলো জানতে দেখুন আমাদের গাইড।
• Pro প্ল্যান হোস্টিং, ডাটাবেস ও স্টোরেজের জন্য Free রেটের অর্ধেক দেয়। বিস্তারিত আছে ক্রেডিট ডক্স-এ।

আমরা যা শিখলাম

• ব্যবহার-ভিত্তিক খরচের আন্দাজ সময়ের সঙ্গে ভুল হয়ে যায়। যখন উপরের প্রদানকারী বলতে পারে কী ব্যবহৃত হয়েছে, তখন সেখান থেকেই বিল করুন।
• আপনি যে ক্ষুদ্রতম একক বিল করেন, সেখানে বিলিংকে ইডেম্পোটেন্ট করুন। আমাদের ক্ষেত্রে সেটি এক ডাটাবেস-ঘণ্টা।
• যখন ব্যর্থ হতেই হয়, গ্রাহকের পক্ষে ব্যর্থ হোন।