我在以前的博客里說過我的LuckyDraw app在數據存儲方面使用的是 Azure Table Storage，當時選擇這個的原因是成本考慮，因為它實在是便宜，對于我這種個人開發維護的免費的teams app來說，成本是一個很重要的考量點。

當然，我也為這個運營成本的節省，付出了很多開發成本。因為針對Table Storage，在代碼開發，業務邏輯處理，開源庫的支持度等方面，比傳統的數據庫復雜很多。最簡單的一個例子是，當需要保存一個大的json的時候，在SQL，我們可以簡單的使用nvarchar(max)，在table storage里，需要把列拆分成很多小的列進行保存，讀取時也需要讀取多個列的數據然后進行拼接處理。十分復雜。而且自動化測試的時候，也沒有類似 EntityFramework Core的in-memory db。

當時在設計時，我也考慮過CosmosDB，這個是更加符合未來發展趨勢的數據庫，它的優點我就不再在這里重復了。我最后沒有采用它的唯一的原因就是當時太貴了，最最起步的配置是400RU/s，也就是說我的測試環境和開發環境，即使平時不怎么使用，這400RU/s的錢還是要付的。

隨著cosmos db的普及和發現，最近有一些新的收費方式出來，我就在第一時間去研究了一下。

下圖是傳統的方式Provisioned throughput，灰色的上下浮動變化的線是假設的使用量，為了保證這個使用量，一般就需要配置一個略高于使用量的RU值，這里就用 5000 RU/s 作為例子。所以系統收費的時候就按照 5000 RU/s 來收費。

但是我們通常的系統不會上上圖那樣負載一直保持在一個相對穩定的高位，真實的情況更像下圖，使用量隨著時間有高有低，比如晚上或者周末可能低一些，這個時候為了滿足最高的使用峰值，如果使用傳統方式，我們還是需要配置成 5000 RU/s，但是大家可能已經發現了，在使用低谷時，5000 RU/s 是一種很大的浪費。

針對上面這種情況，Cosmos DB推出了 Autoscale 收費模式，我們可以設置一個最大值，比如 5000 RU/s，Cosmos DB平臺會自動根據你的使用量的高低來變化 RU/s，當你的使用量不大的時候，RU/s就降低，但是最低不會低于最高值的10%，這里是 500 RU/s，當使用量增加時，Cosmos DB自動增加 RU/s，最高可以達到你設置的上限。這樣在收費時，就是根據實際分配的 RU 來計算。可以看到這種模式下，我們可以省下很多費用。

但是如果對于一個使用率很低的系統來說，比如下圖，如果是一個測試環境，那可能用戶在測試時才用一會兒，大多數時間都是空置狀態。

如果還是使用Autoscale模式，可以看到如下圖。因為有一個最低的10%的保留量，和auto scale的時間問題，cosmos db收取的費用還是有一部分浪費了。?

好在Cosmos DB最近推出了 serverless 模式，雖然在我寫這篇文章的時候還是在 preview 狀態。可以看到如下圖，serverless收費是真正按照調用量來的，有一次算一次，用多少算多少。

看到這里，我相信大家和我有一樣的想法，還在等什么呢？是時候開始使用CosmosDB了！

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的LuckyDraw app使用CosmosDB的成本分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。