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

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

原文連接