ron 用戶 自動 介紹 數據塊 結算 vpd 很大的 周末

POLARDB優勢解讀系列文章之——分鐘級彈性

無處不在的脈沖計算
阿裏有雙11，中國有春運，高考後有分數出來的那天，歌迷心中有周傑倫演唱會門票在線開售之時。。。。有人的地方就有江湖，有人的地方也有脈沖計算，這些熱點事件背後都需要大量的計算資源給予支撐，而這些突然急需的計算資源就像脈沖一樣，急迫而猛烈，我們稱之為脈沖計算。不僅ECS服務器，數據庫也需要應對這些突如其來的脈沖波動，才能保證整個系統的平滑穩定。

存儲與計算分離
我們知道POLARDB一個最大的特點是存儲與計算分離，所謂分離就是計算節點（DB Engine）和存儲節點（DB Store）在不同的物理服務器上，任何落地到存儲設備的I/O操作均為網絡I/O。可能會有人問，走網絡，延遲怎麽樣，性能好不好？在『性價比』這篇文章中簡單介紹過借助PolarFS經過網絡訪問PolarStore的測試效果，與本地單副本SSD幾乎持平，這裏就不再贅述。

POLARDB的存儲與計算分離的架構，除了可以降低存儲成本，保證主備數據強一致、不丟數據之外，還帶來了一個巨大的優勢，就是讓數據庫的『彈性伸縮』變得極為簡單、便捷。

做數據庫彈性的挑戰
雖然彈性伸縮是雲的一大特點，很多人也正是看上這一點，才把自己的IT系統搬遷到雲上。但數據庫的彈性伸縮一直都是業界難題，不同於純粹提供計算服務的ECS，數據庫要想做好彈性需要應對這些問題：

首先，橫向擴展難。數據庫往往是業務系統的核心。數據必須流動、共享才有價值，因此在規模還不算很大的時候，數據庫一般都是集中式部署，這樣用起來簡單，比如多個業務庫的查詢，一個SQL就出來了。所以，對於數據庫很難通過橫向增加服務器數量，達到線性的擴展能力。

其次，0宕機要求。數據庫的核心地位決定了一旦數據庫故障，真個業務就會癱瘓。因此數據庫是一定要做高可用，屏蔽任何的硬件故障，來保障業務不間斷。既要保障高可用，又要做彈性伸縮，就好像在高速飛行的飛機上換引擎，難度可想而知。
再次，數據比計算『重(zhong)』。數據庫的本質是存數據，但數據本質上是存儲在存儲設備上的，當你發現存儲設備I/O性能不夠時，升級存儲設備並不是一件容易的事。同樣，假如數據和計算在同一臺物理機時，這臺物理機的CPU核數和主頻，就決定了計算力的上限，很難擴容。
現在，當突破了存儲與計算分離的性能瓶頸後，結合多節點共享同一份數據的架構設計，我們終於可以在數據庫的彈性伸縮領域有了新的進展。

POLARDB的彈性優勢

如上圖，POLARDB是一個分層架構，從上層的代理PolarProxy提供了讀寫分離、SQL加速等功能，到中間的數據庫引擎節點PolarDB構造了一寫多讀的數據庫集群，再到底層的分布式存儲PolarStore為上層提供多節點掛載的數據共享，每一層各司其職，共同構建了POLARDB雲數據庫集群。

從POLARDB產品定義上看，用戶購買的節點數和規格大小（比如4核16G）指的是中間這一層PolarDB的配置，上層PolarProxy可以根據PolarDB的配置自適應調整，用戶不需購買也不用關心性能和容量。底層PolarStore的容量是自動擴容，只須按照實際使用容量付費。

通常意義的擴展性，一般有縱向（Scale up）和橫向（Scale out）和兩種方式，縱向是指提升配置，橫向是指配置不變，但增加節點。對於數據庫來說，都是先縱向，比如4核不夠升到8核。但終歸會遇到瓶頸，一方面性能提升非線性，跟數據庫引擎自身的設計和應用訪問模型有關（比如MySQL的多線程設計，如果只有一個session，那麽很難體現出多核的優勢），另一方面，計算物理服務器配置有上限，存在天花板。因此終極手段還是橫向擴展，增加節點數。

一句話概括，POLARDB橫向最多可以到16個節點，縱向最高可到88核 ，存儲容量動態擴展，毋須配置。

縱向擴展（升級/降級配置）
得益於存儲與計算分離，我們可以單獨升級或降級POLARDB數據庫節點的配置，如果當前服務器資源不足，還可以快速地遷移到其他服務器，整個過程只需要5-10分鐘（持續優化中），中間不需要任何的數據搬遷，只是如果涉及到跨機遷移，可能會有幾十秒的連接閃斷（未來，這個影響可以通過PolarProxy消除掉，升級對業務應用完全無影響）。

因為目前同一集群內的所有節點必須綁定升級，因此我們會采用非常柔和的Rolling Upgrade滾動升級的方式，通過控制升級的節奏、搭配主備切換來進一步減少不可用時間。

橫向擴展（增/減節點）
由於存儲是共享的，因此可以快速增加節點，而不需要任何的數據COPY。整個過程也只需要5-10分鐘（持續優化中），如果是增加節點，對業務應用沒有任何影響，如果是減少節點，那麽僅對落到該節點執行的連接有影響，重練即可。

當增加節點之後，PolarProxy可以動態感知並自動加入到讀寫分離後端的讀節點中，對於使用集群訪問地址（讀寫分離地址）連接POLARDB的應用程序可以立馬享受到更好的性能和吞吐。

毋須管理的存儲空間
POLARDB的存儲空間不需要關心，用多少付多少錢，每小時自動結算。

對於I/O能力，目前的設計是跟數據庫節點的規格有關系，規格越大，IOPS和I/O吞吐量越高，在節點上對I/O有隔離和限制，避免多個數據庫集群之間的I/O爭搶。

本質上，數據是被保存在由大量服務器構成的存儲池中，由於可靠性要求，每個數據塊復制出3個副本，保存在不同機架的不同服務器上。存儲池能夠進行自我管理，動態擴容、平衡，避免存儲碎片和數據熱點。

典型場景
某位於北京的在線教育公司在雲上部署了一個小學生在線答題考試系統，平時有5萬到10萬人在線，周末有20萬，考試高峰期能達到50萬到100萬，數據規模500G以內。主要難點在於高用戶並發訪問，讀寫爭用，I/O較高，如果一直買最高配置，成本又接受不了。通過使用POLARDB，借助快速彈性的能力，在高峰期臨時增加數據庫配置和集群規模，與之前的方案相比整體成本下降了70%。

雙11大考 POLARDB分鐘級彈性讓企業輕松擴展