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%。