本文分享自天翼雲開發者社區《如何計算真實的資料庫成本》

作者:王****乾

       在雲計算占主導地位之前，計算資料庫的成本是一個非常簡單的等式：軟體成本+硬體成本=資料庫成本。如果你選擇了一個開源產品，軟體成本可能會消失。雖然雲計算已經從根本上改變了我們使用和部署軟體的方式，但仍有太多人在使用這種過時的計算方法。

       事實上，在為資料庫的總成本定價時，需要考慮的事情還有很多。硬體和軟體成本仍然存在，但您還需要考慮擴展資料庫、與現有和未來系統集成以及計劃內或計劃外停機的成本。 

       在為雲資料庫的成本定價時，預先詢問這些問題至關重要。在The Cockroach Hour()的一個線上研討會中，我們提出了一個完整的大綱，列出了在計算資料庫的真實成本時要問的所有問題。費用分為三大類：硬成本、運營成本和軟成本。

       如果你想看到一個完全詳盡的報告，可以看看這份50頁的報告。該報告評估了七家不同的公司，收集的見解將幫助您降低成本，提高正常運行時間，並加快創新步伐。

       在我們的原始資料庫成本網路研討會的回顧中，我們將提到各個成本項，並提供使您可以在自己的計算中應用的模板。

資料庫的硬成本

       從錶面上看，這個等式的這一部分自雲出現以來沒有太大變化。資料庫的硬成本分為兩類：軟體許可證和硬體。

雲資料庫軟成本

       市場上有許多軟體許可證，可分為三類：  

       1、傳統企業：在雲之前，這已經是企業軟體領域三十多年的模式。您需要為企業軟體許可證支付一大筆預付費（通常為數十萬美元，外加支持和維護費）。購買後，您需要為添加的功能和升級支付額外的費用。

        2、完全開源：完全免費的Apache許可證。然而，與自由軟體許可證相關的成本並非不存在。你需要支付維護、支持和降低風險的費用。我們稍後會討論這些費用。 

        3、商業開源：這種模式出現在大約10-15年前，作為一種可行的解決方案，可以解決公司在完全開源許可證中遇到的一些問題，如賠償和支持。

雲資料庫硬成本

       今天的硬體成本看起來與30年前不同。但是，這些硬體成本並沒有消失，只是因為不用安裝巨大伺服器在機房嗡嗡作響。當然，也有不同之處：你可能會與供應商談判價格，或者利用規模經濟（不要貶低這一點），但這是你需要考慮的成本。 

       您還需要管理和操作所有這些。運營成本不會就這麼消失。在這些雲提供商的界面上花費了相當多的時間來實際管理這些事情，並從操作的角度進行理解，因此易用性非常重要。

業務資料庫費用

       除了硬體和軟體成本之外，還有運行資料庫所產生的日常成本。根據您選擇的供應商（及其定價結構），這些差異很大，但源於同一個問題：當我們將來要做某項任務時會發生什麼？ 

       在使用資料庫的過程中，您將不得不處理災難恢復、擴展以及將系統與其他工具集成。人們很容易認為“船到橋頭自然直”。但是，在計算資料庫的真實成本時，您需要考慮這些不可避免性，並計算出當您需要跨越這些橋梁時所需的成本。

災難恢復：資料庫失敗的代價是什麼？

       無論你在硬體上放置多少抽象層，最終，我們都是在處理機械設備。這些設備總會發生故障。在選擇資料庫來部署應用程式時，需要考慮臨時或災難性挑戰的成本。雖然應用程式可能失敗的原因有很多，但資料庫是許多停機的主要原因。舊版本、寫入瓶頸、記憶體問題、鎖定事務、錯誤配置、硬體故障。你需要為這些不可避免的事情做好準備，因為它們會在某個時候發生。

       計劃內和計劃外的停機時間都可能導致巨大的成本，雖然這一支出可能不容易計算，但仍應將其視為資料庫選擇的一部分。每個企業都是不同的，停機時間的影響也各不相同，但在計算企業的停機成本時，需要考慮以下幾項： 

• 收入損失：錯失開展線上商務或與前景接洽的機會
• 聲譽影響：消費者可能轉向你的競爭對手
• 客戶滿意度：由於觀察到的問題而對您的產品或服務失去信任
• 監管成本：司法法規有時會因數據問題對組織進行罰款
• 法律的責任：在極端情況下，可能會提起與數據丟失相關的訴訟

       有一些非常簡單和更直接的技術原因可以解釋為什麼數據丟失和停機會成為一個問題。我們經常發現自己需要處理延長的RPO（恢復點目標）/RTO（恢復時間目標），並將承受高昂的技術成本。

擴展：分片的成本是多少？

       對於大多數雲資料庫，擴展是通過增加實例的大小來實現的。但是，使用這種方法，您將受到可用的最大大小的限制。當你想超越這個規模，或者需要全球規模時，會發生什麼？ 

       某些資料庫（如AWS Aurora）允許您擴展到單個實例（RDS）之外，並允許多個實例。但是，這僅用於讀取，並且限制了您可以處理的事務量，因為沒有擴展寫入節點的功能。你仍然面臨著容量限制。此外，這種單寫節點配置限制了您跨廣泛地理區域擴展訪問的可用性，因為您總是會遇到寫訪問的物理延遲。  

       如果您選擇擴展PostgreSQL或MySQL等開源資料庫，則最終需要對資料庫進行分片。與這種方法相關的成本很高。首先，您需要修改應用程式，這會帶來風險。您還需要配置一個新實例，併在某個時候切換到這個新配置，通常是在半夜。您將有與硬體相關的額外成本以及它給團隊帶來的痛苦...而這都是最好的情況。如果在此過程中出現問題，您將面臨計劃外停機。此外，分片資料庫的管理成本隨著每個新分片呈指數級增加。

整合：使用其他工具的成本是多少？

       您的資料庫並不存在於真空中。它將被集成到您的IT平臺的其他部分。您不會在OLTP資料庫中運行OLAP。數據倉庫的出現是有原因的。因此，資料庫和其他工具（如數據倉庫）之間的集成非常重要。根據您的資料庫，它可能會很昂貴。你的用例是否需要Kafka或某種流處理？你在使用數據湖嗎？

購買前評估隱藏的資料庫成本

       除了運營成本之外，還有一些更難量化的問題，這些問題構成了雲資料庫的隱藏成本。其中包括合規成本、競爭風險、供應商鎖定的可能性以及吸引人才的能力。考慮部署、管理和擴展傳統關係資料庫的所有隱藏成本的最佳方法是使用此報告進行評估。

原文鏈接：https://www.cockroachlabs.com/blog/true-cost-cloud-database/

作者：Dan Kelly，如需轉載，請聯繫作者。