雲數據庫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並行計算

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