基於POLARDB數據庫的壓測實踐

POLARDB架構簡介

PolarDB是阿里雲ApsaraDB數據庫團隊研發的基於雲計算架構的下一代關係型數據庫(暫時僅支持MySQL，PostgreSQL正在緊鑼密鼓的開發中)，其最大的特點是計算節點(主要作SQL解析以及存儲引擎計算的服務器)與存儲節點(主要作數據塊存儲，數據庫快照的服務器)分離，其次，與傳統的雲數據庫一個實例一份數據拷貝不一樣，同一個實例的全部節點(包括讀寫節點和只讀節點)都訪問存儲節點上的同一份數據，最後，藉助優秀的RDMA網絡以及最新的塊存儲技術，PolarDB的數據備份耗時能夠作到秒級別(備份時間與底層數據量無關)，這三點相結合，咱們能夠推斷出PolarDB不但知足了公有云計算環境下用戶業務快速彈性擴展的剛性需求(只讀實例擴展時間與底層數據量無關)，同時也知足了互聯網環境下用戶對數據庫服務器高可用的需求(服務器宕機後無需搬運數據重啓進程便可服務)。

DB Server: 即數據庫進程(Polar DataBase, 簡稱PolarDB)。PolarDB數據庫內核區分實例角色，目前包括三種角色，Primary，Standby和Replica。Primary即爲擁有讀寫權限的讀寫庫，Replica即爲只讀實例，僅僅擁有讀取數據的權限(後臺線程也不能修改數據)，Primary和Replica採用Shared Everything架構，即底層共享同一份數據文件和日誌文件。StandBy節點擁有一份獨立的數據和日誌文件(如圖2所示)，雖然用戶線程依然只有讀取數據的權限，可是後臺線程能夠更新數據，例如經過物理複製的方式從Primary節點更新增量數據。StandBy節點主要用來機房級別的容災以及建立跨可用區的只讀實例，公測階段暫時不開放。因爲只讀實例的擴展不須要拷貝數據，建立新的只讀實例不但速度快，並且很便宜，用戶只須要支付相應計算節點的成本便可。咱們稱StandBy和Replica節點爲Slave節點，Primary節點也可稱爲Master節點。

User Space File System: 即用戶態文件系統(Polar File Sytem, 簡稱PolarFS)。因爲多個主機的數據庫實例須要訪問塊存儲上的同一份數據，經常使用的Ext4等文件系統不支持多點掛載，PolarDB數據庫團隊自行研發了專用的用戶態文件系統，提供常見的文件讀寫查看接口，便於MySQL和相關的外圍運維工具使用文件系統支持相似O_DIRECT的非緩存方式讀寫數據，還支持數據頁原子寫，IO優先級等優秀的特性，爲上層數據庫的高性能提供告終實的保障。傳統的文件系統，因爲嵌入在操做系統內核中，每次系統文件讀寫操做都須要先陷入內核態，完成後再返回用戶態，形成效率低下。PolarFS以函數庫形式編譯在MySQL中，所以都運行在用戶態，從而減小了操做系統切換的開銷。

Data Router & Cache: 即塊存儲系統客戶端(Polar Store Client, 別名PolarSwitch)。PolarFS收到讀寫請求後，會經過共享內存的方式把數據發送給PolarSwitch，PolarSwith是一個計算節點主機維度的後臺守護進程，接收主機上全部實例以及工具發來的讀寫塊存儲的請求。PolarSwith作簡單的聚合，統計後分發給相應的存儲節點上的守護進程。因而可知PolarSwitch是一個重資源的進程，若是處理很差，對計算節點上的數據庫實例有很大的影響，所以咱們的管控程序對其使用了CPU綁定，內存預分配，資源隔離等一些手段，而且同時部署了高效可靠的監控系統，保證其穩定運行。

Data Chunk Server: 即塊存儲系統服務器端(Polar Store Server, 別名ChunkSever)。上述三個部件都運行在計算節點上，這個部件則運行在存儲節點上。主要負責相應數據塊的讀取。數據塊的大小目前爲10GB，每一個數據塊都有三個副本(位於三臺不一樣的存儲節點上)，兩個副本寫成功，纔給客戶端返回成功。支持數據塊維度的高可用，即若是一個數據塊發生不可用，能夠在上層無感知的狀況下秒級恢復。此外，PolarStore使用了相似Copy On Write技術，支持秒級快照，即對數據庫來講，無論底層數據有多大，都能快速完成全量數據備份，所以PolarDB支持高達100T的磁盤規格。

計算節點和存儲節點之間經過25G RDMA網絡鏈接，保證數據的傳輸瓶頸不會出如今網絡上。

此外，PolarDB還有一套完善的基於docker的管控系統，處理用戶下發的建立實例，刪除實例，建立帳號等任務，還包括完善詳細的監控，以及可靠的高可用切換。管控系統還維護了一套元數據庫，用以記錄各個數據塊的位置信息，提供給PolarSwitch，便於其轉發。

能夠說，PolarDB整個項目用了不少不少的新技術黑科技，給用戶直接的感覺是，又快(性能是官方MySQL6倍)又大(磁盤規格支持高達100T)又便宜(價格只有商業數據庫的1/10)。

實踐內容

POLARDB數據庫準備

進入雲數據庫阿里雲POLARDB控制檯進行配置：2核4GB（獨享配置）

建立後會發現有兩個實例，一個主實例，一個只寫實例。

測試過程

本次場景使用HyperPacer PRO 2016版進行數據庫壓測。

配置以下：

1.進行工程配置：

初始化JDBC配置和JDBC請求：

這裏各個編輯控件和下拉控件的使用及每一個選項的說明，只要在HyperPacer的工具欄上點擊幫助就能夠看到。在綁定變量賦值的編輯區域裏，咱們看到在前兩個變量賦值這裏作了參數化。

這裏須要注意的是：此處綁定變量賦值的順序和個數須要和存儲過程當中定義的參數保持徹底一致。

在綁定變量類型的編輯區域，這裏的類型只能夠是在java.sql.Types中定義的類型，而且要保證和咱們調用的存儲過程當中的參數類型保持一致。

咱們這裏說的類型保持一致要分爲兩方面來看：一方面要保證用於傳參的變量類型保持一致，即這裏寫的JDBC類型要和SQL類型保持一致，關於保持類型一致的轉換映射關係能夠查看JDK的官方文檔。

2.以下圖進行壓力數據測試配置:

參數詳解

基準用戶數：系統過載前容許的最大用戶數

最大用戶數：系統過載後容許的最大用戶數

基準用戶加壓策略：固定時間內加載固定數量的基準用戶進入系統

過載用戶加壓策略：固定時間內加載固定數量的過載用戶進入系統

持續總時長：系統過載後持續保持過載運行的時間

用戶退出策略：測試結束前多少時間內退出所有用戶

壓力閥配置：配置測算系統過載的依據，如平均CPU利用率達到99%等。

本文做者：凌洛

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。