डेटाबेस की बिलिंग उनके असली इस्तेमाल के हिसाब से
Mythex का हर ऐप जिसे डेटा स्टोर करना है, उसे अपना Postgres डेटाबेस मिलता है, और पब्लिश किए गए ऐप के डेटाबेस का उपयोग उसी क्रेडिट बैलेंस से कटता है जिससे ऐप बनाने का खर्च। सितंबर के आखिर तक हम इस उपयोग का अनुमान लगाते थे, जो ऐप के सर्वर के चलने की अवधि से निकाला जाता था। वह अनुमान एक ऐसे तरीके से गलत निकला जिससे फ़र्क पड़ता था, इसलिए हमने उसे बदल दिया: अब हर डेटाबेस की बिलिंग उस कंप्यूट से होती है जिसे उसके प्रोवाइडर ने असल में मापा है, एक पूरे हुए घंटे के हिसाब से, और हर घंटे का शुल्क केवल एक बार ही लग सकता है।
डेटाबेस कैसे काम करते हैं
हर डेटाबेस एक सर्वरलेस Postgres पर चलता है जो शून्य पर स्केल होता है: कुछ मिनट निष्क्रिय रहने के बाद वह सो जाता है, और अगली क्वेरी पर जाग जाता है। जागते समय वह लोड के हिसाब से अपना कंप्यूट बढ़ा और घटा सकता है। इसी से "हर ऐप के लिए एक डेटाबेस" किफ़ायती बनता है: ज़्यादातर ऐप ज़्यादातर समय शांत रहते हैं, और सोए हुए डेटाबेस की लागत लगभग कुछ नहीं होती।
इसका मतलब यह भी है कि डेटाबेस की लागत दो ऐसी चीज़ों पर निर्भर करती है जो बाहर से दिखती नहीं: वह कितनी देर जागा रहा और जागते समय वह कितना बड़ा था।
अनुमान में क्या गलत था
हमारे मूल मीटर में एक धारणा थी: पब्लिश किए गए ऐप का सर्वर जितने भी घंटे चलता है, हर घंटे के लिए डेटाबेस का सबसे छोटा कंप्यूट साइज़ चार्ज करना।
यह तीन तरह से गलत था:
- साइज़ गलत था। डेटाबेस असल में अनुमान में मानी गई साइज़ से बड़े डिफ़ॉल्ट साइज़ पर चल रहे थे।
- डेटाबेस ऑटोस्केल होते हैं। लोड के तहत वे बढ़ते हैं, और अनुमान ने उसे कभी देखा ही नहीं।
- डेटाबेस ऐप सर्वर के पीछे-पीछे नहीं चलते। डेटाबेस तब भी जागा रहता है जब कोई भी उससे क्वेरी करता है: ऐप, कोई शेड्यूल्ड जॉब, या उसे पोल करने वाली कोई स्क्रिप्ट, चाहे ऐप का सर्वर चालू हो या नहीं।
कुल असर यह था कि अनुमान उपयोगकर्ताओं से डेटाबेस की असली लागत का लगभग आधा ही वसूल रहा था। हमारे लिए यह टिकाऊ नहीं था, और इसका मतलब यह भी था कि ऐप में दिखाए गए उपयोग के आँकड़े वह नहीं कहते थे जो लोग समझते थे।
अनुमान की जगह माप
हमारा डेटाबेस प्रोवाइडर हर प्रोजेक्ट के प्रति घंटे compute-unit-seconds की रिपोर्ट देता है, यानी उसने असल में कितना कंप्यूट इस्तेमाल किया, साइज़ समेत। तो अब मीटर इस तरह काम करता है:
- डेटाबेस वाले हर पब्लिश ऐप के लिए, ऐप लाइव होने के बाद से हर पूरे हुए घंटे का मापा गया उपयोग लाएँ।
- वह उपयोग प्रोवाइडर की कीमत पर लागत में बदलें, प्लान की दर लगाएँ, और ऐप के मालिक के क्रेडिट से काटें।
- हर बार एक दिन तक पीछे देखें, ताकि वे घंटे जो हमारे API के रीस्टार्ट होने के दौरान छूट गए थे, बाद में भी बिल हो जाएँ।
स्टोरेज अलग से बिल होता है, साइज़ के हिसाब से, क्योंकि वह गतिविधि पर निर्भर नहीं करता।
कोई घंटा दो बार न चार्ज हो
एक बिलिंग मीटर जो एक से ज़्यादा सर्वर पर चलता है, और क्रैश होकर दोबारा कोशिश कर सकता है, उसे दोहरा चार्ज करने से सावधानी से बचना होता है। हर डेटाबेस का हर घंटा चार्ज होने से पहले अपनी ही डेटाबेस पंक्ति में क्लेम होता है, जिसमें (डेटाबेस, घंटा) की जोड़ी पर एक यूनिकनेस कंस्ट्रेंट है। अगर दो सर्वर, या एक रीट्राई, एक ही घंटे को बिल करने की कोशिश करें, तो केवल एक क्लेम सफल होता है।
एक दुर्लभ विफलता के मामले के लिए हमने जानबूझकर एक चुनाव भी किया है: अगर प्रोसेस घंटा क्लेम करने और उसे चार्ज करने के बीच में क्रैश हो जाए, तो वह घंटा क्लेम्ड लेकिन बिना बिल का रहता है। किसी दुर्लभ क्रैश में राजस्व का थोड़ा हिस्सा खोना, किसी को दो बार चार्ज करने से बेहतर है।
और जब मापी गई बिलिंग चालू हुई, तो वह अगले पूरे घंटे से शुरू हुई। उससे पहले के घंटे पुराने अनुमान से पहले ही चार्ज हो चुके थे; उन्हें मापे गए डेटा से फिर से बिल करने पर वह हिस्सा दो बार चार्ज होता।
अगर आप Mythex पर बनाते हैं तो इसका मतलब
- आपका डेटाबेस बिल अब दिखाता है कि आपके डेटाबेस ने क्या किया। जो ऐप शायद ही इस्तेमाल होता है, उसकी लागत बहुत कम है; जो ऐप अपने डेटाबेस को लगातार क्वेरी करता है, वह उसे जगाए रखेगा और ज़्यादा लागत आएगी।
- सबसे बड़ा लीवर यह है कि आपका ऐप डेटाबेस का इस्तेमाल कैसे करता है। डेटाबेस को हर कुछ सेकंड में पोल करने से वह चौबीसों घंटे जागा रहता है। AI से डिमांड पर डेटा लाने के लिए कहना, या उसे कैश करना, डेटाबेस को सोने देता है। डेटाबेस क्या है, इसकी बुनियादी जानकारी हमारी गाइड में है।
- Pro प्लान होस्टिंग, डेटाबेस और स्टोरेज के लिए Free दर का आधा भुगतान करते हैं। विवरण क्रेडिट डॉक्स में हैं।
हमने इससे क्या सीखा
- उपयोग-आधारित लागत के अनुमान बहक जाते हैं। जब ऊपर का प्रोवाइडर बता सकता है कि क्या इस्तेमाल हुआ, तो उसी से बिल करें।
- जो सबसे छोटी इकाई आप चार्ज करते हैं, उस पर बिलिंग को idempotent बनाएँ। हमारे लिए वह एक डेटाबेस-घंटा है।
- जब विफल होना ही पड़े, तो ग्राहक के पक्ष में विफल हों।