上篇文章 中，我們簡單介紹了 TiFlash 的設計和架構，TiFlash 是即將隨著 TiDB 3.1 版本發佈（3月）的列存引擎，大幅提升了 TiDB 在實時分析場景下的性能。同時和 TiDB 體系無縫結合，可實時更新，彈性擴展，保持 TiDB 的 ACID 事務特性和快照隔離級別，可用於嚴肅場景的實時分析。
那麼 TiFlash 到底有多快？
為了更直觀回答這個問題，我們用最新版本的 TiFlash 進行了一次全新的對比測試。測試選取了傳統交易型數據庫（及其列存擴展），分析型數據庫和大數據計算引擎進行對比，分別是 Oracle、MySQL、MariaDB ColumnStore、Greenplum 和 Apache Spark。
其中 MySQL 可以承擔在線交易業務，但是分析速度對比針對分析場景特化的產品就相當堪憂；而列存數據庫則無法承擔在線交易，無論是無更實時新存儲結構還是高頻少量數據訪問性能都很難符合在線交易業務要求。
而 TiDB 作為 HTAP 數據庫，在交易場景已經大量驗證的前提下，加上 TiFlash 後在分析側又能達到怎樣的性能呢？藉助 TiFlash 的一致性數據同步特型，用戶可否以一個優異的速度直接對實時數據進行分析呢？
這次我們一起來看一組來自美國交通部的有趣數據，它包含了從 1987 至今的飛機起降和準點情況。 大家可以使用 Percona Lab 的 下載腳本 獲取數據集。數據集總共為一億八千多萬行飛機起降記錄。數據集的表結構在 這裡。
測試所用查詢見後文，我們先來看看對比結果：
注：為了不影響比例，上圖忽略了 MySQL 和 Oracle 數據。
從上面的對比可以看出，
- 相對 MySQL 而言，單機環境下可達到數百倍提升（更不用提 TiFlash 可擴展）；
- 而對比 MPP 數據庫或者新 MariaDB ColumnStore 等無法實時更新的分析型數據庫 / 引擎，仍然可達數倍乃至十倍的性能提升。
如下十條為測試分析查詢所用的 SQL。
查詢 1：平均每月航班起降記錄數
<code>select avg(c1) from
( select year, month, count(*) as c1 from ontime group by year, month ) A;/<code>
查詢 2：2000 年到 2008 年的每日航班數
<code>select dayofweek, count(*) as c from ontime
where year>=2000 and year<=2008 group by dayofweek
order by c desc;/<code>
查詢 3：按星期統計 2000 年到 2008 年延誤（10 分鐘以上，下同）的航班數
<code>select dayofweek, count(*) as c from ontime
where depdelay>10 and year>=2000 and year<=2008 group by dayofweek order by c desc;/<code>
查詢 4：按出發機場統計 2000 年到 2008 年延誤數
<code>select origin, count(*) as c from ontime
where depdelay>10 and year>=2000 and year<=2008 group by origin order by c desc limit 10;/<code>
查詢 5：按照航空公司統計 2007 年延誤數
<code>select carrier, count(*) from ontime
where depdelay>10 and year=2007 group by carrier
order by count(*) desc;/<code>
查詢 6：按照航空公司統計 2007 年延誤比例
<code>select carrier, c, c2, c*100/c2 as c3 from
(select carrier, count(*) as c from ontime where depdelay>10 and year=2007 group by carrier ) A
inner join
( select carrier, count(*) as c2 from ontime where year=2007 group by carrier ) B using (carrier)
order by c3 desc;/<code>
查詢 7：按照航空公司統計 2000 到 2008 年延誤比例
<code>select carrier, c, c2, c*100/c2 as c3 from
( select carrier, count(*) as c from ontime where depdelay>10 and year>=2000 and year<=2008 group by carrier ) A
inner join
( select carrier, count(*) as c2 from ontime where year>=2000 and year<=2008 group by carrier ) B using (carrier)
order by c3 desc;/<code>
查詢 8：按年統計航班延誤率
<code>select year, c1/c2 from ( select year, count(*)*100 as c1 from ontime where depdelay>10 group by year ) A
inner join
( select year, count(*) as c2 from ontime group by year ) B using (year)
order by year;/<code>
查詢 9：每年航班數
<code>select year, count(*) as c1 from ontime
group by year;/<code>
查詢 10：多維度複雜過濾和聚合
<code>select min(year), max(year), carrier, count(*) as cnt, sum(arrdelayminutes>30) as flights_delayed, round(sum(arrdelayminutes>30)/count(*),2) as rate from ontime
where dayofweek not in (6,7) and originstate not in ('ak', 'hi', 'pr', 'vi') and deststate not in ('ak', 'hi', 'pr', 'vi') and flightdate < '2010-01-01'
group by carrier having cnt>100000 and max(year)>1990
order by rate desc limit 1000;/<code>
真 · 行列混合
別忘了還有行存。TiDB 不但擁有 TiFlash 列存引擎，也同時擁有相應的行存和配套的細粒度索引支持。
對於唯一值個數非常高的列（例如一個具體的時間，產品唯一序列號等等），一般來說列存很難有良好的手段進行精確過濾。例如在上述 OnTime 數據集中，對 CRSDepTime 計劃起飛時間列進行索引，同樣的查詢還能變得更快。
統計所有在 18:45 分計劃起飛的飛機總數。
<code>mysql> select count(*) from ontime where 1845 = CRSDepTime;
+----------+
| count(*) |
+----------+
| 766539 |
+----------+
1 row in set (0.09 sec)/<code>
而純粹使用列存，在 MariaDB，Spark 以及 Greenplum 中，這樣的查詢分別是 0.447 vs 0.449 以及 1.576 秒——與 TiDB + TiFlash 存在 4 至 17 倍速度差！因為他們必須暴力掃表。
除此以外，TiDB 的行列混合並不是傳統設計上的行存列存二選一，而是 TiDB 可以在同一張表同時擁有行存和列存，且兩者永遠保持數據強一致（而非最終一致）。
看到這裡也許你要問，TiDB 同時擁有行存和列存是否反而會給用戶帶來心智負擔？答案是並不會。何時使用行存或者列存，除了用戶可以為了 HTAP 業務隔離而強制選擇以外，你完全可以委託給 TiDB 自行選擇。當行存更優（例如上面的案例），TiDB 則會憑藉統計信息自動切換到行存進行讀取：上面的查詢在 TiFlash 上的性能只有 TiKV 行存 + 索引的一半。
更快的數據到達
由於為配合 TiDB 數據鏡像同步而設計的可高頻更新列存引擎，使得 TiFlash 得以高速更新數據。這使得它的「快」不僅僅是「高速返回查詢」，也意味著「數據能更快被查詢到」。
相較於傳統的分析型數據庫或者 Hadoop 數據湖需要從源數據庫 T + 1 批量加載（往往是一天），TiFlash 的可以讀取到最新的（而非僅僅是新鮮的）數據，且你無需關心數據到達亂序或者一致性問題。相比維護額外的數據複製作業，你不但精簡了架構，也可以更實時地訪問數據。
何不試試看？
另外，TiFlash 上線測試非常簡單，你可以使用一兩臺現成的機器進行測試，簡單一兩條命令，上線 TiFlash 節點，添加列存副本，等副本同步完成之後就可以看到效果，綠色無害。TiFlash 已經在進行第一輪用戶測試，並在 3 月會開啟開放公測，請關注後續信息，也歡迎聯繫詢問提前體驗 [email protected]。
附本文測試環境
由於部分測試對象不支持集群模式，測試環境為單機（但是藉助 TiDB 的可擴展體系，TiFlash 也可以進行無縫線性擴展）。測試機規格和配置如下：
CPU: 40 vCores, Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz @ 1268.383 MHz Mem: 188G @ 2133 MHz
1 x NVMe SSD 3.6T
OS: centos-release-7-6.1810.2.el7.centos.x86_64
Filesystem: ext4
TiKV Region Size: 512M
Greenplum 16 Segments (DISTRIBUTED RANDOMLY)
Oracle noparallel
如果外鏈失效請到 PingCAP 官網博客查看原文。
閱讀更多 PingCAP 的文章
