فوترة قواعد البيانات حسب ما تستخدمه فعلاً

يحصل كل تطبيق في Mythex يحتاج إلى تخزين بيانات على قاعدة Postgres خاصة به، ويُخصم استهلاك قاعدة بيانات التطبيق المنشور من رصيد الأرصدة نفسه المستخدم في البناء. وحتى أواخر سبتمبر، كنا نُقدّر هذا الاستهلاك من مدة تشغيل خادم التطبيق. وتبين أن التقدير خاطئ بطريقة مهمة، فاستبدلناه: تُحتسب كل قاعدة بيانات الآن من الحوسبة التي قاسها مزودها فعلاً، ساعة مكتملة في كل مرة، ولا يمكن أن تُحتسب كل ساعة إلا مرة واحدة.

كيف تعمل قواعد البيانات

تعمل كل قاعدة بيانات على Postgres بلا خادم يحدّث حجمه تلقائياً إلى الصفر: بعد بضع دقائق من الخمول تنام، وتستيقظ مع الاستعلام التالي. وأثناء اليقظة يمكنها زيادة حوسبتها وتقليلها حسب الحمل. وهذا ما يجعل «قاعدة بيانات لكل تطبيق» في المتناول، فمعظم التطبيقات هادئة معظم الوقت، وقاعدة النوم تكاد لا تكلّف شيئاً.

وهذا يعني أيضاً أن تكلفة قاعدة البيانات تعتمد على أمرين لا نراهما من الخارج: كم مدة بقائها مستيقظة، ومدى حجمها أثناء اليقظة.

ما الذي أخطأ فيه التقدير

كان مقياسنا الأصلي يقوم على افتراض: عن كل ساعة يعمل فيها خادم تطبيق منشور، تُحتسب قاعدة البيانات بأصغر حجم حوسبة.

وكان ذلك خاطئاً بثلاث طرق:

1. الحجم كان خاطئاً. كانت قواعد البيانات تعمل فعلاً بحجم افتراضي أكبر من الذي افترضه التقدير.
2. قواعد البيانات تتوسع تلقائياً. تنمو تحت الحمل، ولم يرَ التقدير ذلك أبداً.
3. قواعد البيانات لا تتبع خادم التطبيق. تبقى القاعدة مستيقظة كلما استعلم عنها أي شيء، سواء التطبيق أو مهمة مجدولة أو سكربت يستطلعها، سواء كان خادم التطبيق يعمل أم لا.

والنتيجة الصافية: كان التقدير يحتسب على المستخدمين نحو نصف ما تكلفه قواعد البيانات فعلاً. وهذا غير مستدام بالنسبة لنا، كما أن أرقام الاستخدام في التطبيق لم تعنِ ما كان الناس يظنون أنها تعنيه.

القياس بدلاً من التخمين

يُبلغ مزود قواعد البيانات لدينا عن ثواني وحدات الحوسبة في الساعة لكل مشروع، أي مقدار الحوسبة التي استخدمها فعلاً، بما فيها الحجم. لذلك يعمل المقياس الآن على النحو التالي:

1. لكل تطبيق منشور لديه قاعدة بيانات، يُجلب الاستخدام المقاس لكل ساعة مكتملة منذ إطلاق التطبيق.
2. يُحوَّل ذلك الاستخدام إلى تكلفة وفق سعر المزود، ويُطبَّق سعر الخطة، ويُخصم من أرصدة مالك التطبيق.
3. ينظر المقياس إلى الوراء حتى يوماً كاملاً في كل مرة، فالساعات التي فاتت أثناء إعادة تشغيل واجهة البرمجة لدينا تُحتسب لاحقاً.

أما التخزين فيُحتسب بشكل منفصل، حسب الحجم، لأنه لا يعتمد على النشاط.

عدم احتساب الساعة مرتين أبداً

يجب أن يكون مقياس الفوترة الذي يعمل على أكثر من خادم، ويمكن أن ينهار ويعيد المحاولة، حذراً كي لا يحتسب مرتين. تُحجَز كل ساعة من كل قاعدة بيانات في صف قاعدة البيانات الخاص بها قبل أن تُحتسب، مع قيد فريد على الزوج (قاعدة البيانات، الساعة). وإذا حاول خادمان، أو إعادة محاولة، احتساب الساعة نفسها، فإن حجزاً واحداً فقط ينجح.

وقد اتخذنا أيضاً قراراً متعمداً لحالة الفشل النادرة: إذا انهارت العملية بين حجز الساعة واحتسابها، تبقى الساعة محجوزة وغير مفوترة. خسارة جزء صغير من الإيراد في انهيار نادر أفضل من أن نحتسب على أحد مرتين أبداً.

وعندما فُعّلت الفوترة المقاسة، بدأت من الساعة المكتملة التالية. فالساعات التي سبقتها احتُسبت بالفعل بالتقدير القديم، وإعادة احتسابها من البيانات المقاسة كانت ستحتسب تلك الفترة مرتين.

ماذا يعني ذلك إذا كنت تبني على Mythex

• فاتورة قاعدة البيانات تعكس الآن ما فعلته قاعدتك. التطبيق الذي يُستخدم نادراً يكلّف قليلاً جداً، والتطبيق الذي يستعلم عن قاعدته باستمرار سيبقيها مستيقظة ويكلّف أكثر.
• أكبر أداة تأثير هي طريقة استخدام تطبيقك لقاعدة البيانات. استطلاع القاعدة كل بضع ثوانٍ يبقيها مستيقظة طوال الساعة. أما أن تطلب من الذكاء الاصطناعي جلب البيانات عند الطلب، أو تخزينها مؤقتاً، فيسمح لقاعدة البيانات بالنوم. ويغطي دليلنا عن قاعدة البيانات الأساسيات.
• تدفع خطط Pro نصف سعر Free للاستضافة وقواعد البيانات والتخزين. التفاصيل في وثائق الأرصدة.

ما استخلصناه

• تقديرات التكاليف المرتبطة بالاستخدام تنحرف. عندما يستطيع المزود الأعلى أن يخبرك بما استُخدم، فاحتسب من ذلك.
• اجعل الفوترة idempotent عند أصغر وحدة تحتسبها. بالنسبة لنا، هذه ساعة واحدة من قاعدة بيانات.
• عندما لا بد أن تفشل، فاجعل الفشل لصالح العميل.