用戶使用雲端資料庫現行有幾種方法,包括在虛擬機器或是Kubernetes上執行,或甚至是直接採用完全託管的記憶體服務,Google對此提供了一些建議,供用戶在選擇資料庫之前做參考

Kubernetes的應用越來越熱門,許多應用程式被容器化,甚至專門將軟體容器化的服務也熱門起來,但這個熱潮並沒有發生在資料庫上,Google提到,可以容器化的工作負載,通常具有能適應頻繁地重新啟動、橫向擴展、虛擬化等其他限制,因此資料庫在服務的可用性等要求,限制了資料在分散式環境中執行的發展。

Google提到,但是仍有不少開發團隊,希望資料庫可以使用與應用程式相同的堆疊,而營運人員也能使用相同的工具管理。比起完全託管的資料庫服務Cloud Spanner、Cloud Bigtable和Cloud SQL等,和在虛擬機器上全自營運的選項,在Kubernetes上執行資料庫雖然偏向全自營運,但是Kubernetes提供的自動化功能,是能為營運人員省掉一些麻煩,但Google提醒,營運人員要有心理準備,因為Pod狀態僅為暫時性的,而且資料庫應用程式重新啟動與故障轉移機率比較高,且資料庫管理員的工作像是備份、擴展和調校等工作,會因為容器化新增的抽象層而不同。

由於Kubernetes的Pod是會消失的,因此故障轉移事件性的可能性,會高於傳統託管或是完全託管的資料庫,而換得的好處是,當要執行的資料庫,需要包含分片、故障轉移選擇或是內建的複製等功能,那在Kubernetes上營運將會更容易,部分開源專案還提供自訂義資源以及營運工具,以幫助使用者管理資料庫。

Google製作了一個決策樹圖,供用戶評估並選擇適合的雲端資料庫的方案,要在Kubernetes上建置資料庫,最先需要了解的是,資料庫的功能以及生態系的專案是否對Kubernetes友善,再來還需要評估組織營運工作負載的能量,有充足的營運能力再選擇在Kubernetes上自建資料庫。

在資料庫的選擇上,Google表示,開發人員需要考慮資料庫在應用程式和業務環境中執行的功能,儲存較多暫時狀態以及快取層的資料庫,更適合在Kubernetes上運作,因為該類型的資料庫通常擁有較高的彈性,因此也能夠在Kubernetes上提供較好的服務品質。另外,營運人員需要考量資料庫支援的複製模式,非同步複製可能產生資料遺失等問題,因為交易可能只提交到主資料庫,而沒有傳送給輔助資料庫,營運人員需要靠考慮資料遺失,以及可接受遺失的資料量。

熱門新聞

Advertisement