คิดค่าฐานข้อมูลตามสิ่งที่ใช้จริง

ทุกแอป Mythex ที่ต้องเก็บข้อมูลจะได้ฐานข้อมูล Postgres ของตัวเอง และการใช้ฐานข้อมูลของแอปที่ publish แล้วจะถูกหักจากยอดเครดิตเดียวกับการสร้างแอป จนถึงปลายเดือนกันยายน เราประมาณการใช้งานนั้นจากระยะเวลาที่เซิร์ฟเวอร์ของแอปทำงาน การประมาณนั้นผิดในลักษณะที่สำคัญ เราจึงแทนที่มัน ตอนนี้ทุกฐานข้อมูลถูกคิดเงินจาก compute ที่ผู้ให้บริการวัดได้จริง ทีละหนึ่งชั่วโมงที่เสร็จสิ้น และแต่ละชั่วโมงสามารถถูกเรียกเก็บได้เพียงครั้งเดียวเท่านั้น

ฐานข้อมูลทำงานอย่างไร

แต่ละฐานข้อมูลรันบน serverless Postgres ที่ลดเหลือศูนย์ได้ หลังจากไม่มีการใช้งานไม่กี่นาที มันจะหลับ และตื่นขึ้นเมื่อมี query ถัดไป ขณะที่ตื่นอยู่ มันสามารถปรับ compute ขึ้นลงตามโหลดได้ นี่คือสิ่งที่ทำให้ "ฐานข้อมูลหนึ่งตัวต่อแอป" มีราคาที่จ่ายได้ เพราะแอปส่วนใหญ่เงียบอยู่เกือบตลอดเวลา และฐานข้อมูลที่หลับแทบไม่มีค่าใช้จ่าย

สิ่งนี้ยังหมายความว่าค่าใช้จ่ายของฐานข้อมูลขึ้นอยู่กับสองสิ่งที่เรามองไม่เห็นจากภายนอก: มันตื่นอยู่นานเท่าไร และมันใหญ่แค่ไหนขณะที่ตื่นอยู่

การประมาณการเดิมผิดตรงไหน

ตัววัดเดิมของเราตั้งสมมติฐานหนึ่งข้อ: ทุกชั่วโมงที่เซิร์ฟเวอร์ของแอปที่ publish แล้วทำงาน จะคิดค่าฐานข้อมูลในขนาด compute ที่เล็กที่สุด

นั่นผิดในสามทาง:

1. ขนาดผิด ฐานข้อมูลจริงรันที่ขนาดเริ่มต้นที่ใหญ่กว่าที่การประมาณสมมติไว้
2. ฐานข้อมูลปรับขนาดอัตโนมัติ เมื่อมีโหลดมันจะโตขึ้น และการประมาณไม่เคยเห็นสิ่งนี้
3. ฐานข้อมูลไม่ได้ทำตามเซิร์ฟเวอร์แอป ฐานข้อมูลจะตื่นทุกครั้งที่ มีอะไรบางอย่าง query มัน ไม่ว่าจะเป็นแอป job ที่ตั้งเวลาไว้ หรือสคริปต์ที่ poll มัน โดยไม่ขึ้นกับว่าเซิร์ฟเวอร์ของแอปทำงานอยู่หรือไม่

ผลสุทธิคือ การประมาณคิดเงินผู้ใช้เพียงประมาณครึ่งหนึ่งของค่าใช้จ่ายจริงของฐานข้อมูล นั่นไม่ยั่งยืนสำหรับเรา และยังหมายความว่าตัวเลขการใช้งานในแอปไม่ได้หมายความอย่างที่คนคิดว่ามันหมายถึง

วัดแทนการเดา

ผู้ให้บริการฐานข้อมูลของเรารายงาน compute-unit-seconds ต่อชั่วโมง ของแต่ละโปรเจกต์ ซึ่งคือปริมาณ compute ที่ใช้จริง รวมถึงขนาดด้วย ดังนั้นตัววัดตอนนี้ทำงานดังนี้:

1. สำหรับแต่ละแอปที่ publish แล้วและมีฐานข้อมูล ให้ดึงการใช้งานที่วัดได้สำหรับทุกชั่วโมงที่เสร็จสิ้นแล้วนับตั้งแต่แอปเริ่มใช้งาน
2. แปลงการใช้งานนั้นเป็นค่าใช้จ่ายตามราคาของผู้ให้บริการ ใช้อัตราของแพลน และหักจากเครดิตของเจ้าของแอป
3. ย้อนดูได้สูงสุดหนึ่งวันทุกครั้ง เพื่อให้ชั่วโมงที่พลาดไปขณะที่ API ของเรารีสตาร์ต ยังถูกคิดเงินในภายหลัง

ที่เก็บข้อมูลถูกคิดเงินแยกต่างหาก ตามขนาด เพราะไม่ขึ้นกับการใช้งาน

ไม่คิดเงินชั่วโมงเดียวกันสองครั้ง

ตัววัดการเรียกเก็บเงินที่ทำงานบนเซิร์ฟเวอร์มากกว่าหนึ่งตัว และอาจล่มแล้วลองใหม่ ต้องระวังไม่ให้เรียกเก็บซ้ำ ชั่วโมงของฐานข้อมูลแต่ละชั่วโมงจะถูกจองในแถวฐานข้อมูลของตัวเองก่อนที่จะคิดเงิน โดยมีข้อจำกัดความไม่ซ้ำกันบนคู่ (ฐานข้อมูล, ชั่วโมง) หากเซิร์ฟเวอร์สองตัวหรือการลองใหม่พยายามเรียกเก็บชั่วโมงเดียวกัน จะมีเพียงการจองเดียวที่สำเร็จ

เรายังเลือกอย่างตั้งใจสำหรับกรณีความล้มเหลวที่เกิดขึ้นน้อย หากโปรเซสล่มระหว่างการจองชั่วโมงและการเรียกเก็บเงิน ชั่วโมงนั้นจะยังถูกจองและไม่ได้เรียกเก็บ การเสียรายได้เล็กน้อยในการล่มที่หาได้ยาก ดีกว่าการเรียกเก็บเงินจากใครสองครั้ง

และเมื่อการคิดเงินตามการวัดเปิดใช้งาน มันเริ่มจากชั่วโมงเต็มถัดไป ชั่วโมงก่อนหน้านั้นถูกคิดเงินด้วยการประมาณเดิมไปแล้ว และการคิดเงินซ้ำจากข้อมูลที่วัดได้จะเรียกเก็บช่วงเวลานั้นเป็นสองเท่า

สิ่งนี้หมายความว่าอย่างไรหากคุณสร้างบน Mythex

• ค่าฐานข้อมูลของคุณตอนนี้สะท้อนสิ่งที่ฐานข้อมูลของคุณทำจริง แอปที่ใช้น้อยมีค่าใช้จ่ายน้อยมาก ส่วนแอปที่ query ฐานข้อมูลตลอดเวลาจะทำให้มันตื่นอยู่ตลอดและมีค่าใช้จ่ายมากขึ้น
• ปัจจัยที่มีผลมากที่สุดคือวิธีที่แอปของคุณใช้ฐานข้อมูล การ poll ฐานข้อมูลทุกไม่กี่วินาทีทำให้มันตื่นตลอดเวลา การให้ AI ดึงข้อมูลเมื่อต้องการ หรือแคชข้อมูล ทำให้ฐานข้อมูลหลับได้ คู่มือฐานข้อมูลคืออะไรของเราครอบคลุมพื้นฐาน
• แพลน Pro จ่ายครึ่งหนึ่งของอัตรา Free สำหรับโฮสติ้ง ฐานข้อมูล และที่เก็บไฟล์ รายละเอียดอยู่ใน เอกสารเครดิต

สิ่งที่เราได้เรียนรู้

• การประมาณค่าใช้จ่ายที่ขึ้นกับการใช้งานจะคลาดเคลื่อน เมื่อผู้ให้บริการต้นทางบอกคุณได้ว่ามีการใช้อะไรไปบ้าง ให้คิดเงินจากข้อมูลนั้น
• ทำให้การเรียกเก็บเงินเป็น idempotent ที่หน่วยที่เล็กที่สุดที่คุณคิดเงิน สำหรับเราคือหนึ่งชั่วโมงของฐานข้อมูล
• เมื่อจำเป็นต้องล้มเหลว ให้ล้มเหลวในทางที่เป็นประโยชน์ต่อลูกค้า