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

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的基于POLARDB数据库的压测实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。