雲資料庫POLARDB產品解讀之二：如何做到高性價比
現在做任何事情都要看投入產出比，對應到資料庫上其實就是價效比。POLARDB作為一款阿里自研資料庫，經常被問的問題是：效能怎麼樣？能不能支撐我的業務？價格貴不貴？很顯然，在早期調研階段，對穩定性、可靠性很難有量化的指標時，效能的好快就成了一個非常關鍵的決策因子。
POLARDB在一開始設計時就把效能作為一項關鍵的需求指標列入產品需求說明書，從架構設計到新硬體選型，再到程式碼實現，從驅動到分散式塊儲存，再到分散式檔案系統和資料庫引擎，打通整個技術棧做協同優化，最終才能保證效能上有數量級的提升。
高效能背後的技術
在2018杭州雲棲大會上分享的這張架構圖展示了POLARDB的內部細節。自下而上來看，POLARDB由__共享分散式儲存PolarStore__，__分散式檔案系統PolarFS__，__多節點的資料庫叢集PolarDB__和__提供統一入口的代理PolarProxy__這四部分組成。
PolarFS
PolarFS設計中採用瞭如下技術以充分發揮I/O效能：
- PolarFS採用了繫結CPU的單執行緒有限狀態機的方式處理I/O，避免了多執行緒I/O pipeline方式的上下文切換開銷。
- PolarFS優化了記憶體的分配，採用MemoryPool減少記憶體物件構造和析構的開銷，採用巨頁來降低分頁和TLB更新的開銷。
- PolarFS通過中心加區域性自治的結構，所有元資料均快取在系統各部件的記憶體中，基本完全避免了額外的元資料I/O。
- PolarFS採用了全使用者空間I/O棧，包括RDMA和SPDK，避免了核心網路棧和儲存棧的開銷。
在相同硬體環境下的對比測試，PolarFS中資料塊3副本寫入效能接近於單副本本地SSD的延遲效能。從而在保障資料可靠性的同時，極大地提升POLARDB的單例項TPS效能。
PolarDB
在資料庫PolarDB中開創性地引入了物理日誌（Redo Log）代替了傳統的邏輯日誌，不僅極大地提升了複製的效率和準確性，還節省了50%的 I/O 操作，對於有頻繁寫入或更新的資料庫，效能可提升50%以上。
PolarProxy
PolarProxy存在的意義是可以把底層的多個計算節點的資源整合到一起，提供一個統一的入口，讓應用程式訪問，極大地降低了應用程式使用資料庫的成本，也方便了從老系統到POLARDB的遷移和切換。本質上，PolarProxy是一個容量自適應的分散式無狀態資料庫代理叢集，動態的橫向擴充套件能力，可以將POLARDB快速增減讀節點的優勢發揮到極致，提升整個資料庫叢集的吞吐，訪問它的ECS越多，併發越高，優勢越明顯。
關於成本
拋開成本談效能，都是耍流氓。
首先，POLARDB儲存與計算分離的架構，可以讓CPU、記憶體和磁碟擺脫互相制約的困擾，讓計算和儲存作為單獨的資源池進行管理和分配，大幅降低資源碎片，提升整體的資源利用率。計算和儲存的機型不同，我們還可以更有針對性地做定製和優化，降低單位資源的成本。
通用意義上，規模效應帶來的邊際成本遞減這件事，會一直髮生。在阿里巴巴超大規模的基礎設施的基礎上，我們可以持續不斷地從全球供應鏈、低能耗資料中心、伺服器研發等多個維度來降低我們的成本。
價效比
不管技術上有多先進，成本上有多低，最終還是需要使用者認可。
所以，我們從使用者角度來看，最關心的其實還是價效比，即同樣的費用，是否可以獲取更好的效能。
我們簡單算筆賬，來看一下POLARDB和RDS MySQL的價效比。
公平起見，我們使用同樣的資料庫配置，測試資料集和測試方法，然後分別計算出二者的價格和效能。
其中，
- 資料庫配置採用生產環境常見的『8核 32G ，500G儲存』的配置
- 資料集和測試方法採用通用的sysbench OLTP測試用例(--oltp-tables-count=10 --oltp-table-size=500000)
- 效能指標我們取QPS（Query per Second 每秒鐘處理請求數）和TPS（ Transaction per Second 每秒鐘處理事務數）
此外，不管是RDS MySQL還是POLARDB，都具備了通過增加只讀節點來達到橫向擴充套件讀（Scale out）的能力，不同的是，POLARDB隨著節點數的增加，並不需要額外的儲存費用，因此，我們需要多對比幾種架構，從1個讀節點到3個讀節點，具體如下：
| 叢集架構 | POLARDB 月價（計算規格+儲存） | RDS MYSQL 月價 | POLARDB比RDS貴 | POLARDB 效能(QPS) | RDS MySQL效能(QPS) | POLARDB效能提升 | 千元效能指標（RDS vs. POLARDB) |
|---|---|---|---|---|---|---|---|
| 1主1備 | 2000*2 +1575=5575 | 4100+400=4500 | +24% | 53879.46 | 18625.49 | +190% | 4139 vs. 9664 |
| 1主2備 | 2000*3+1575=7575 | (4100+400)+(5.13+0.001*400)*24*30=8481 | -10% | 66626.63 | 26357.94 | +150% | 3107 vs. 8795 |
| 1主3備 | 2000*4+1575=9575 | (4100+400)+(5.13+0.001400)24302=12463 | -23% | 80268.27 | 43087.33 | +86% | 3457 vs. 8383 |
表中的一些基礎價格（以2018.11.8 當天價格為例）：
- POLARDB儲存月價：1575元/月 = 500GB * 3.5元/GB/月
- POLARDB 1個節點的月價是2000元
- MySQL高可用版例項（雙節點）的月價是4100元
- MySQL高可用版例項儲存月價：400元/月 = 500GB * 0.8元/GB/月
- MySQL只讀例項小時價：5.13元/小時
- MySQL只讀例項儲存小時價：0.001元/GB/小時
用下圖展示會更清晰一些，其中灰色的『備庫』不對外提供服務。由此可見，POLARDB的價效比非常高，所有節點都提供服務，因此資源利用率也較RDS高。
彩蛋——免費使用的複雜SQL查詢加速
在實際應用中，客戶的業務是複雜的，很多時候業務訪問會摻雜著大量的統計分析類的複雜SQL（Ad-hoc query），這時候MySQL的單執行緒模型處理起來就會捉襟見肘。
POLARDB為了應對這種場景，內建了並行查詢引擎，針對大表複雜查詢（比如TCP-H基準測試）效能可提升8倍，特別適用於執行時長超過1分鐘的慢SQL（比如報表查詢）。同時還支援了集合運算、WITH、視窗函式OVER等高階語法。該功能目前已經公測，免費使用，詳細參考『SQL加速』。
以下圖表是我們做了一個對比測試，在使用SQL加速的情況下，查詢效率是不使用SQL加速直接查詢的8倍以上，具體的測試用例包括，
- Point query on non-indexed column（無索引列的單行查詢）
- Aggregate query（聚合查詢）
- TPC-H
目前SQL加速功能，提供了額外的連線地址，提供非事務的複雜查詢服務。底層的計算節點和儲存複用POLARDB現有的資源，一份資料多種訪問方式，省去了資料遷移的煩惱，也不需要額外的成本投入。
技術實現上，包括以下幾點，
- 外掛式計算引擎，負責分散式運算元計算
- 單表計算下推到資料庫引擎
- 大SQL平行計算
