這陣子對OLAP資料庫産生了興趣，先是簡單測試了ClickHouse，性能的确不錯，不過它在穩定&可靠性，整體生态&周邊配套方面還有待加強，我會持續保持關注。
3月27日，騰訊雲推送的文章 TXSQL(TencentDB for MySQL) 8.0特性介紹中提到即将推出 基于MySQL架構的列存引擎CSTORE，看了下架構圖，和以前紅極一時的 infobright 有點神似。
不過現在還沒上線，還不能開始内測，隻能看看了。
轉過身看看阿裡雲，發現有 分析型資料庫MySQL版（AnalyticDB，簡稱ADB） 以及 雲資料庫ClickHouse可選。
ADB的産品介紹可以看官方文檔 什麼是分析型資料庫MySQL版，我抓取了其中幾個關鍵技術資訊：
- 雲端PB級高并發實時資料倉庫。
- 采用關系模型的行列混存技術。
- 自動索引，智能優化器。
- 高度相容MySQL和SQL 2003文法。
- 可對RDS直接建立一個分析執行個體，建構ADB，并利用DTS實作資料同步。
看着很牛逼，有木有，那就測測呗。
1. 建立RDS執行個體和ADB執行個體
我選擇的RDS執行個體對标之前用于測試ClickHouse的規則
- 4CPU
- 16G記憶體
- 500G存儲
選擇ADB執行個體時，系統會根據RDS中的資料量，隻顯示符合條件的規格，我這裡選擇的是 3.0版本、T16型号、存儲空間 600G。
2. 導入測試資料
老樣子，用ClickHouse官網提到的dbgen工具生成測試資料，生成資料時選擇
-s 100
參數。
然後在RDS執行個體中分别導入到幾個測試表。
MySQL [testabc]> load data local infile '/data/ssb-dbgen/customer.tbl'
into table customer fields terminated by '\t'; 提醒：ClickHouse官網提供的建表DDL需要自己微調下，改成适用于MySQL的文法和資料類型。
3. 建立資料同步DTS任務
DTS的工作機制類似 pt-table-sync，需要每個表都要指定一個主鍵，這就讓我很不開心了。
生成的測試表中，是在其他表都導完資料後，再用 CREATE...SELECT建立的。
幾個測試表的總資料量是604,637,902(6億)，建立完DTS同步任務後，經過22.5小時候，同步的資料量約為325,174,022條，完成率53.78%，折算下來每秒約3990條記錄，這個速度如果是OLTP資料庫也還算可以，但放在海量資料的OLAP場景下，可就有點慢了。
對了，我選擇的是 medium規則，号稱最高同步性能 5000 records/s。
DTS啟動、停止
同步進度
由于測試經費預算有限，我隻能放棄全量資料同步，有多少算多少吧。
接下來的事情可就有點頭疼了。
上面說了，lineorder_flat表是 CREATE...SELECT 建立的，而這個文法在ADB中是不支援的（産品頁面上宣稱全面支援MySQL文法，産品經理果然很會畫大餅啊，哈哈）。
好嘛，我退而求其次，改成 在RDS中先建立一個空表，讓DTS把表結構同步過去，再在ADB中用INSERT...SELECT寫資料。
由于lineorder_flat原表是沒有主鍵的，我需要建立一個自增INT做主鍵，否則DTS配置階段是過不去的，無論我選擇分區表還是次元表，都必須指定主鍵列。
分區表模式下：
次元表模式下：
好了，變通之後表結構是同步過去了，可是在ADB上執行 INSERT...SELECT時，彈出下面的錯誤提醒：
INSERT INTO lineorder_flat SELECT ... FROM lineorder AS l INNER JOIN customer AS c ON c.C_CUSTKEY = l.LO_CUSTKEY INNER JOIN supplier AS s ON s.S_SUPPKEY = l.LO_SUPPKEY INNER JOIN part AS p ON p.P_PARTKEY = l.LO_PARTKEY limit 1;
失敗原因：[40040, 2020040414153117201906308103453294111] Query execution error: : Insert query has mismatched column types. The 1 column has mismatched types. Table: bigint. Query: decimal(20,0). 而上面這條SQL，如果把所有列讀取出來，再手動構造成INSERT寫入，則不會報錯，這就尴尬了，搞不懂具體是錯在哪裡。
不得已，隻能回到RDS執行個體上，硬着頭皮對其他幾個表都先加上主鍵和必要，再生成測試資料了。
在RDS主庫上往lineorder_flat表中寫入1000萬條資料，等到DTS同步完成後，再在ADB上跑測試SQL。
4. 執行測試SQL
下面是幾個測試SQL執行耗時、傳回資料，和ClickHouse運作結果的對比（提醒：CH的資料量是6億，ADB的資料量是1000萬，相差60倍）。
| SQL | ADB(毫秒)/傳回數量 | CH(秒)/傳回數量 | CH掃描數量(10萬) |
| Q1.1 | 33/0 | 2.141/1 | 91.01 |
| Q1.2 | 0.320/1 | 7.75 | |
| Q1.3 | 31/0 | 0.053/1 | 1.81 |
| Q2.1 | 271/100 | 17.979/280 | 600.04 |
| Q2.2 | 385/56 | 3.625/56 | |
| Q2.3 | 99/7 | 3.263/7 | |
| Q3.1 | 383/100 | 6.906/150 | 546.67 |
| Q3.2 | 130/100 | 5.330/600 | |
| Q3.3 | 96/24 | 3.666/24 | |
| Q3.4 | 65/2 | 0.058/4 | 7.76 |
| Q4.1 | 304/35 | 10.110/35 | |
| Q4.2 | 519/100 | 1.928/100 | 144.42 |
| Q4.3 | 67/772 | 1.373/800 |
在ADB中沒辦法看到每次掃描了多少條資料，是以少了這項資料。
看起來性能還算可以，就是不知道如果資料量一樣的話，結果又會如何。
這次的測試就先到這裡吧，以後有機會再繼續。
本次測試得到了DTS産品經理的幫助，感謝。