依實際用量計費的資料庫

每個需要儲存資料的 Mythex 應用程式，都會擁有自己的 Postgres 資料庫；已發布應用程式的資料庫用量，會從與建置相同的點數餘額中扣除。直到 9 月底為止，我們都是根據應用程式伺服器的執行時間來估算這部分用量。結果發現，這個估算在某些重要的方面是錯的，因此我們把它換掉了：現在每個資料庫都依供應商實際量測到的運算量計費，每次只計算已完成的一小時，而且每個小時只能被計費一次。

資料庫如何運作

每個資料庫都運行在會縮減至零的無伺服器 Postgres 上：閒置幾分鐘後會進入休眠，下一次查詢時再喚醒。喚醒期間，它會根據負載調整運算資源的大小。正因為如此，「每個應用程式一個資料庫」才得以負擔得起：大多數應用程式大部分時間都很安靜，而休眠中的資料庫幾乎不花錢。

這也意味著，資料庫的成本取決於兩件從外部看不見的事：它醒著的時間有多長，以及醒著時的規模有多大。

估算錯在哪裡

我們最初的計量器做了一個假設：只要已發布應用程式的伺服器在執行，每一個小時都以最小的運算規格來計算資料庫費用。

這個假設在三方面都有錯：

**規模錯了。**資料庫實際上運行在比估算所假設的更大的預設規格上。
**資料庫會自動調整大小。**在負載下，它會擴大，而估算從未考慮到這一點。
**資料庫不會跟著應用程式伺服器走。**只要任何東西查詢它，資料庫就會保持清醒，無論是應用程式、排程工作，還是一個不斷輪詢它的腳本，而與應用程式伺服器是否在運行無關。

最終結果是，估算向使用者收取的費用，大約只有資料庫實際成本的一半。這對我們來說是不可持續的，而且應用程式裡顯示的用量數字，也和人們以為它們代表的意思不一致。

量測，而不是猜測

我們的資料庫供應商會回報每個專案每小時的運算單位秒數，也就是它實際使用的運算量，包含規模在內。因此計量器現在的運作方式如下：

對於每個帶有資料庫的已發布應用程式，取得自上線以來每一個已完成小時的實際用量。
依供應商的價格換算成費用，套用方案的費率，然後從應用程式擁有者的點數中扣除。
每次最多回溯一天，因此在 API 重新啟動期間遺漏的小時，之後仍會被計費。

儲存空間則另外依大小計費，因為它並不取決於活動量。

絕不重複計費一小時

一個在多部伺服器上運行、而且可能當機並重試的計費計量器，必須小心不要重複收費。每個資料庫的每一小時，都會先在它自己的資料庫列中認領，然後才會計費，並對（資料庫、小時）這組配對設下唯一性限制。如果兩部伺服器或一次重試同時嘗試計費同一小時，只有一次認領會成功。

對於罕見的失敗情況，我們也做了刻意的選擇：如果程序在認領某個小時**之後、**計費之前當機，那個小時會保持已認領但未計費的狀態。在罕見的當機中損失一小部分收入，好過向某人重複收費。

而且，當量測計費開始啟用時，它是從下一個完整小時開始的。之前的那些小時已經依舊有的估算計過費；如果再根據量測數據計費，就會對那一段時間重複收費。

這對在 Mythex 上建置的人意味著什麼

**你的資料庫帳單現在反映的是資料庫實際的運作情況。**很少使用的應用程式費用極低；持續查詢資料庫的應用程式，會讓它保持清醒，費用也會更高。
**最大的影響因素是應用程式如何使用資料庫。**每隔幾秒輪詢一次資料庫，會讓它整天保持清醒。改為視需要由 AI 取得資料，或加以快取，就能讓資料庫休眠。我們的什麼是資料庫指南涵蓋了基礎知識。
Pro 方案在託管、資料庫與儲存上的費率是免費方案的一半。詳情請見點數文件。

我們的收穫

**以用量為基礎的成本，估算容易失準。**當上游供應商能告訴你實際用量時，就應該依據該數據計費。
**在你收費的最小單位上，讓計費具有冪等性。**對我們來說，那就是一個資料庫小時。
如果一定要失敗，就要朝有利於客戶的方向失敗。