صورتحساب پایگاه‌داده بر اساس میزان واقعی استفاده
هر اپ Mythex که نیاز به ذخیره‌ی داده دارد، پایگاه‌داده‌ی Postgres اختصاصی خودش را می‌گیرد، و مصرف پایگاه‌داده‌ی یک اپ منتشرشده از همان موجودی اعتبار ساخت اپ کسر می‌شود. تا اواخر سپتامبر، آن مصرف را از مدت زمانی که سرور اپ در حال اجرا بود تخمین می‌زدیم. این تخمین به شکلی اشتباه درآمد که اهمیت داشت، پس آن را عوض کردیم: حالا هر پایگاه‌داده بر اساس محاسباتی که ارائه‌دهنده‌اش واقعاً اندازه‌گیری کرده صورتحساب می‌شود، یک ساعت کامل تمام‌شده در هر بار، و هر ساعت فقط یک بار قابل شارژ است.
پایگاه‌های داده چطور کار می‌کنند
هر پایگاه‌داده روی Postgres بی‌سرور اجرا می‌شود که به صفر مقیاس می‌یابد: بعد از چند دقیقه‌ی بی‌کاری می‌خوابد و با اولین کوئری بیدار می‌شود. وقتی بیدار است، محاسباتش می‌تواند با بار بالا و پایین برود. همین است که «یک پایگاه‌داده برای هر اپ» را مقرون‌به‌صرفه می‌کند — بیشتر اپ‌ها بیشتر وقت‌ها ساکت‌اند، و یک پایگاه‌داده‌ی خوابیده تقریباً هیچ هزینه‌ای ندارد.
یعنی هزینه‌ی یک پایگاه‌داده به دو چیزی بستگی دارد که از بیرون قابل دیدن نیستند: چقدر بیدار بوده و وقتی بیدار بوده چقدر بزرگ بوده.
تخمین قبلی کجا اشتباه بود
متر اولیه‌ی ما یک فرض داشت: برای هر ساعتی که سرور یک اپ منتشرشده در حال اجرا بود، هزینه‌ی یک پایگاه‌داده را با کوچک‌ترین اندازه‌ی محاسباتی حساب می‌کرد.
این سه جای اشتباه داشت:
- اندازه اشتباه بود. پایگاه‌داده‌ها در واقع روی اندازه‌ی پیش‌فرض بزرگ‌تری از آنچه تخمین فرض می‌کرد اجرا می‌شدند.
- پایگاه‌داده‌ها خودکار مقیاس می‌گیرند. زیر بار بزرگ می‌شوند، و تخمین هرگز آن را ندید.
- پایگاه‌داده تابع سرور اپ نیست. پایگاه‌داده هر وقت هر چیزی به آن کوئری بزند بیدار می‌ماند — خود اپ، یک job زمان‌بندی‌شده، یک اسکریپت که مرتب آن را چک می‌کند — چه سرور اپ بالا باشد چه نباشد.
نتیجه‌ی خالص این بود که تخمین، از کاربران تقریباً نصف هزینه‌ی واقعی پایگاه‌داده‌ها را گرفت. این برای ما پایدار نبود، و همچنین باعث می‌شد عددهای مصرف داخل اپ معنایی را که مردم فکر می‌کردند نداشته باشند.
اندازه‌گیری به‌جای حدس زدن
ارائه‌دهنده‌ی پایگاه‌داده‌ی ما برای هر پروژه ثانیه‌های واحد محاسباتی در هر ساعت را گزارش می‌دهد — یعنی چقدر محاسبه واقعاً مصرف شده، با احتساب اندازه. پس متر حالا این‌طور کار می‌کند:
- برای هر اپ منتشرشده‌ای که پایگاه‌داده دارد، مصرف اندازه‌گیری‌شده را برای هر ساعت تمام‌شده از زمان زنده شدن اپ می‌گیرد.
- آن مصرف را با قیمت ارائه‌دهنده به هزینه تبدیل می‌کند، نرخ پلن را اعمال می‌کند، و آن را از اعتبار صاحب اپ کم می‌کند.
- هر بار تا یک روز به عقب نگاه می‌کند، تا ساعت‌هایی که هنگام راه‌اندازی مجدد API ما از دست رفته‌اند بعداً صورتحساب شوند.
ذخیره‌سازی جداگانه بر اساس اندازه صورتحساب می‌شود، چون به فعالیت وابسته نیست.
هرگز یک ساعت را دو بار شارژ نکن
یک متر صورتحساب که روی بیش از یک سرور اجرا می‌شود و می‌تواند کرش کند و دوباره امتحان کند، باید مراقب باشد که دوبار شارژ نکند. هر ساعت از هر پایگاه‌داده، پیش از شارژ شدن، در ردیف پایگاه‌داده‌ی خودش گرفته می‌شود، با یک محدودیت یکتایی روی جفت (پایگاه‌داده، ساعت). اگر دو سرور، یا یک تلاش مجدد، بخواهند همان ساعت را صورتحساب کنند، فقط یکی موفق به گرفتن می‌شود.
در مورد حالت نادر شکست هم یک انتخاب عمدی داشتیم: اگر پروسه بین گرفتن یک ساعت و شارژ کردنش کرش کند، آن ساعت گرفته‌شده و بی‌صورتحساب باقی می‌ماند. از دست دادن یک تکه درآمد در یک کرش نادر بهتر از این است که کسی دوبار شارژ شود.
و وقتی صورتحساب اندازه‌گیری‌شده روشن شد، از ساعت کامل بعدی شروع کرد. ساعت‌های قبل از آن قبلاً با تخمین قدیمی شارژ شده بودند؛ صورتحساب دوباره‌ی آن بازه از روی داده‌ی اندازه‌گیری‌شده، همان بازه را دو بار شارژ می‌کرد.
این برای شما که روی Mythex می‌سازید یعنی چه
- صورتحساب پایگاه‌داده‌ی شما حالا منعکس‌کننده‌ی کاری است که پایگاه‌داده‌تان انجام داده. اپی که به ندرت استفاده می‌شود هزینه‌ی خیلی کمی دارد؛ اپی که دائماً به پایگاه‌داده‌اش کوئری می‌زند، آن را بیدار نگه می‌دارد و هزینه‌ی بیشتری می‌دهد.
- بزرگ‌ترین اهرم، نحوه‌ی استفاده‌ی اپ شماست از پایگاه‌داده. هر چند ثانیه پایگاه‌داده را پینگ کردن، آن را شبانه‌روز بیدار نگه می‌دارد. از AI بخواهید داده را وقت نیاز بگیرد، یا آن را کش کند، تا پایگاه‌داده بخوابد. راهنمای ما درباره‌ی پایگاه‌داده چیست مبانی را پوشش می‌دهد.
- پلن‌های Pro نصف نرخ Free را برای میزبانی، پایگاه‌داده و ذخیره‌سازی می‌پردازند. جزئیات در مستندات اعتبار است.
آنچه از این ماجرا یاد گرفتیم
- تخمین‌های هزینه‌هایی که بر اساس مصرف‌اند، دور می‌افتند. وقتی ارائه‌دهنده‌ی بالادستی می‌تواند بگوید چه چیزی مصرف شده، از همان صورتحساب بگیرید.
- صورتحساب را idempotent کنید در کوچک‌ترین واحدی که شارژ می‌کنید. برای ما این یک ساعت پایگاه‌داده است.
- وقتی ناچارید شکست بخورید، به نفع مشتری شکست بخورید.