體驗另類「MySQL」的極致性能

• 2020 年 2 月 25 日
• 筆記

AnalyticDB，是阿里雲推出的一款資料庫產品，主打海量實時數據分析領域。說其是另類「MySQL」，是因為其兼容MySQL生態，可以像MySQL一樣去使用，非常簡潔方便。不久前，其還推出單機版規格，頗為驚艷，可以說把大數據的門檻大大降低了。正如上圖所表現的，"大數據"這頭大象也可以敏捷奔跑起來。假期無事，特針對AnalyticDB新推出的單機版與MySQL，在規模數據下的查詢表現做了個對比分析。

《敏捷大數據》的時代到來

曾幾何時，大數據的概念非常火熱。但我們這裡要看到，這裡的大數據通常代表兩層含義，一是所謂符合4V標準的數據；二是隨之誕生的一些適合處理前者問題的技術。隨著近些年來，數據在企業中扮演者越來越重要的地位，之前常見的一些「中小」數據，也逐步變成了大數據。此外，隨著數字化浪潮的發展，數據在企業經營決策中扮演著愈發重要的地位，隨之而來對數據計算的需求也越來越強烈。而之前談到的大數據技術，並沒有很好地跟上現實需求，其較高的技術門檻、離散的技術生態、非傳統的使用方式都阻礙了快速普及。AnalyticDB的推出，正是看中了這一問題，以近似傳統的使用方式，來處理現在面臨的海量、實時類數據問題。進而，也提出了「敏捷大數據」的理念，摒棄傳統大數據技術的繁複冗贅，而倡導以一種更加簡潔的方式來使用數據。

1. 背景介紹：資料庫新兵「ADB」

分析型資料庫MySQL版（AnalyticDB for MySQL）是雲端託管的PB級高並發實時數據倉庫，是專註於服務OLAP領域的數據倉庫。在數據存儲模型上，採用關係模型進行數據存儲，可以使用SQL進行自由靈活的計算分析，無需預先建模。利用雲端的無縫伸縮能力，分析型資料庫MySQL版在處理百億條甚至更多量級的數據時真正實現毫秒級計算。其特點包括：

• 極致性能 分析型資料庫MySQL版運用新一代超大規模的MPP+DAG融合引擎，採用行列混存技術、自動索引、智慧優化器等技術。針對複雜SQL查詢速度相比傳統的關係型資料庫快10倍以上。此外，其採用的分散式架構可快速擴容至數千節點的超大規模，進一步提升速度。
• 靈活部署 分析型資料庫MySQL版，採用存儲和計算分離架構，可根據需要調整節點數量和動態升降配實例規格。既可實現Scale Up，也可以實現Scale Out。方便用戶根據自身情況進行選擇。
• 簡單易用 分析型資料庫MySQL版，全面兼容MySQL協議和SQL：2003，可很方便的融入MySQL生態體系。通過標準SQL和常用BI、ETL工具平台，可輕鬆使用分析型資料庫MySQL版。
• 海量規模 分析型資料庫MySQL版是全分散式結構，無任何單點設計。整體系統可通過橫向擴容來大幅度擴大存儲規模及提升查詢SQL性能和並發處理能力。其可實現數千節點，PB級規模的體量。

單機版介紹

AnalyticDB for MySQL單機版，於2019年12月底推出。其目的是大幅降低企業用戶使用大數據的成本，可方便用戶快速享受到數據實時分析所帶來的技術紅利。其推出的多種規格，可滿足中小規模用戶的數據分析需求。其核心特點如下：

• 門檻降低 用戶僅需之前約50%的成本，即可使用AnalyticDB。這將大大降低用戶的成本投入。無論是小白用戶入門大數據，還是既有用戶新增測試、開發環境都是不錯的選擇。
• 極速性能 在應對複雜SQL場景下，單機版雖較集群版性能有所降低，但其綜合性能仍可達開源MySQL 10倍以上。特別適合於針對MySQL只讀查詢壓力大的情況，可快速根治釋放壓力。
• 使用靈活 用戶可根據需要，隨時選擇使用更為強大的集群版，減少用戶的前期投入。阿里雲也將隨後推出平滑遷移方案。
• 免運維優化 AnalyticDB，採用開箱即用策略，免運維、免優化。可快速享受到極速性能所帶來的紅利。

2. 測試概述：ADB vs MySQL

1). 環境說明

• SSD雲盤IOPS在25000，高效雲盤為5000。
• RDS和ADB均為阿里雲同地域的提供的默認配置。

2). 樣本說明

測試樣本採用常見的人力資源模型，數據採用了人工構造方式。

• 數據結構 原生結構如下，ADB由於是分散式結構，需要定義分布鍵（使用了主鍵）。此外，MySQL後續做了結構優化，添加了部分索引。後續測試分兩組對比。

• 規模

3). 測試集說明

根據SQL特點，將其歸納為十個大類。每類抽象出有代表性的若干語句，作為測試語句。

4). 測試方法

• 數據載入 使用原生MySQL的默認處理，insert into … values(),()方式插入。
• 前置操作 插入後，進行了analyze table操作。
• 測試操作 使用自定義腳本，進行多輪查詢測試，並記錄SQL執行時長。
• 測試數據
  1. 為避免大數據傳輸影響，執行結果使用聚合操作後返回，部分結果會存在下推影響結果的情況。對MySQL和ADB影響一樣。
  2. 所有測試，均進行三組，取執行時長的平均值。
  3. 所有數據的默認單位為毫秒(ms)。
• 測試說明
  1. 單機版規格，性能較集群版有一定差距，且無法進行性能擴展。只能在有限程度做ScaleUp，因此對性能要求較高的用戶，建議使用集群版。
  2. 由於ADB採用的分散式架構，集群內組件較多。在單機環境內部署完整環境，自身資源消耗比例較大。本組測試，只是為了對比同等資源下的MySQL與ADB的性能表現，對ADB而言遠非最佳實踐。
  3. 單機版規格後端使用高效雲盤，其IO性能較SSD雲盤差異巨大，這點也對測試結果造成較大影響。如考慮高性能，還是建議使用集群版（其後端為SSD雲盤）。
  4. 針對MySQL的測試，使用了原始狀態和優化後，分別進行了測試。5000萬規模，因執行時間過長未進行MySQL原始狀態的測試。ADB全程未經任何調優，為默認安裝後的狀態。

3. 測試結果：ADB vs MySQL

1). 結果概覽

對比數據為MySQL/ADB，數字小於1，表示前者優於後者；數字大於1，表示後者優於前者。數據越大，差距越明顯。圖中灰色部分表示MySQL優於ADB的部分。

2). 分項說明

• 簡單查詢

對於此類查詢，基本不需要優化器更多優化，就是比拼數據提取的能力。ADB採用分片機制，類似於MySQL的「分庫分表」，並行提取數據。

• 排序

此部分，優化前後差異較大。上圖為MySQL未優化的情況，理所當然使用了」Using filesort」，性能很差。在優化後，通過加入索引這一有序結構，可以大幅降低排序成本，性能良好。ADB是分散式架構，需要匯總後排序；而單機版受限架構，無法利用多物理節點的能力，表現一般。

• 過濾

這一情況類似「簡單查詢」。在提取數據後，多一步CPU計算過濾過程，這一點單機版的ADB也沒有太多優勢。這裡面比較特殊的是binary比較，引入後使用全表掃描，即使增加索引也效果有限。但ADB則表現優異，猜想是與其列式存儲等因素有關。

• 模糊查詢

這一類查詢，ADB有壓倒性的優勢。因與其列式存儲等因素有關。

• 邏輯條件 同"簡單查詢"。
• 統計

這一組，也是ADB大優。原理就在於分散式架構與單體架構，及行式與列式存儲的差異。

• 分組

ADB勝出，原理同上組。

• 關聯

關聯部分，ADB使用分散式架構，需要有分片間的數據交換等步驟，並最終使用Hash Join完成。而MySQL依託於索引有序結構，可使用Block Nested Loop快速獲得數據。8.0的Hash Join也許對大表間的關聯更有優勢。

• 集合

這一組也是ADB勝出，原因還是出於其分散式架構所致。

• 其他

對於分頁類的操作，在有索引的有序結構下，MySQL表現不錯。ADB中規中矩。

4. 測試總結：ADB vs MySQL

一輪測試下來，對ADB有了更多的了解認識。作為新興的資料庫，對於實時分析類場景，這一產品頗有其特點。此外，其兼容MySQL生態，也很有吸引力，客戶的大量軟體資產，可以平滑遷移。在架構上，甚至可作為MySQL的從庫存在，將複雜類的查詢需求遷移上去，減輕主備庫壓力。可做到一套程式碼，適用多種場景。這遠比之前那種消費到大數據平台，然後非同步查詢來的優雅。最後，總結下AnalyticDB的適用場景，及與MySQL、大數據平台的對比。（星號部分為計劃發展中）