TiFlash的速度快吗

魁首哥

作者

TiFlash的速度快吗

本篇内容介绍了“TiFlash的速度快吗”的有关知识，在实际案例的操作过程中，不少人都会遇到这样的困境，接下来就让小编带领大家学习一下如何处理这些情况吧！希望大家仔细阅读，能够学有所成！

那么 TiFlash 到底有多快？

为了更直观回答这个问题，我们用最新版本的 TiFlash 进行了一次全新的对比测试。测试选取了传统交易型数据库（及其列存扩展），分析型数据库和大数据计算引擎进行对比，分别是Oracle、MySQL、MariaDB ColumnStore、Greenplum 和 Apache Spark。

其中 MySQL 可以承担在线交易业务，但是分析速度对比针对分析场景特化的产品就相当堪忧；而列存数据库则无法承担在线交易，无论是无更实时新存储结构还是高频少量数据访问性能都很难符合在线交易业务要求。

而 TiDB 作为 HTAP 数据库，在交易场景已经大量验证的前提下，加上 TiFlash 后在分析侧又能达到怎样的性能呢？借助 TiFlash 的一致性数据同步特型，用户可否以一个优异的速度直接对实时数据进行分析呢？

这次我们一起来看一组来自美国交通部的有趣数据，它包含了从 1987 至今的飞机起降和准点情况。大家可以使用 Percona Lab 的下载脚本获取数据集。数据集总共为一亿八千多万行飞机起降记录。数据集的表结构在这里。

测试所用查询见后文，我们先来看看对比结果：

查询语句	TiDB + TiFlash	MySQL 5.7.29	Greenplum 6.1	Mariadb Columnstore 1.2.5	Spark 2.4.5 + Parquet	Oracle 12.2.0.1
Q1	0.508	290.340	4.206	1.209	2.044	88.53
Q2	0.295	262.650	3.795	0.740	0.564	76.05
Q3	0.395	247.260	2.339	0.583	0.684	74.76
Q4	0.512	254.960	2.923	0.625	1.306	74.75
Q5	0.184	242.530	2.077	0.258	0.627	67.44
Q6	0.273	288.290	4.471	0.462	1.084	134.08
Q7	0.659	514.700	9.698	1.213	1.536	147.06
Q8	0.453	487.890	3.927	1.629	1.099	165.35
Q9	0.277	261.820	3.160	0.951	0.681	76.5
Q10	2.615	407.360	8.344	2.020	18.219	127.29

注：为了不影响比例，上图忽略了 MySQL 和 Oracle 数据。

从上面的对比可以看出，

相对 MySQL 而言，单机环境下可达到数百倍提升（更不用提 TiFlash 可扩展）；
而对比 MPP 数据库或者新 MariaDB ColumnStore 等无法实时更新的分析型数据库 / 引擎，仍然可达数倍乃至十倍的性能提升。

如下十条为测试分析查询所用的 SQL。

查询 1：平均每月航班起降记录数

selectavg(c1)from(selectyear,month,count(*)asc1fromontimegroupbyyear,month)A;

查询 2：2000 年到 2008 年的每日航班数

selectdayofweek,count(*)ascfromontimewhereyear>=2000andyear<=2008groupbydayofweekorderbycdesc;

查询 3：按星期统计 2000 年到 2008 年延误（10 分钟以上，下同）的航班数

selectdayofweek,count(*)ascfromontimewheredepdelay>10andyear>=2000andyear<=2008groupbydayofweekorderbycdesc;

查询 4：按出发机场统计 2000 年到 2008 年延误数

selectorigin,count(*)ascfromontimewheredepdelay>10andyear>=2000andyear<=2008groupbyoriginorderbycdesclimit10;

查询 5：按照航空公司统计 2007 年延误数

selectcarrier,count(*)fromontimewheredepdelay>10andyear=2007groupbycarrierorderbycount(*)desc;

查询 6：按照航空公司统计 2007 年延误比例

selectcarrier,c,c2,c*100/c2asc3from(selectcarrier,count(*)ascfromontimewheredepdelay>10andyear=2007groupbycarrier)Ainnerjoin(selectcarrier,count(*)asc2fromontimewhereyear=2007groupbycarrier)Busing(carrier)orderbyc3desc;

查询 7：按照航空公司统计 2000 到 2008 年延误比例

selectcarrier,c,c2,c*100/c2asc3from(selectcarrier,count(*)ascfromontimewheredepdelay>10andyear>=2000andyear<=2008groupbycarrier)Ainnerjoin(selectcarrier,count(*)asc2fromontimewhereyear>=2000andyear<=2008groupbycarrier)Busing(carrier)orderbyc3desc;

查询 8：按年统计航班延误率

selectyear,c1/c2from(selectyear,count(*)*100asc1fromontimewheredepdelay>10groupbyyear)Ainnerjoin(selectyear,count(*)asc2fromontimegroupbyyear)Busing(year)orderbyyear;

查询 9：每年航班数

selectyear,count(*)asc1fromontimegroupbyyear;

查询 10：多维度复杂过滤和聚合

selectmin(year),max(year),carrier,count(*)ascnt,sum(arrdelayminutes>30)asflights_delayed,round(sum(arrdelayminutes>30)/count(*),2)asratefromontimewheredayofweeknotin(6,7)andoriginstatenotin('ak','hi','pr','vi')anddeststatenotin('ak','hi','pr','vi')andflightdate<'2010-01-01'groupbycarrierhavingcnt>100000andmax(year)>1990orderbyratedesclimit1000;

真 · 行列混合

别忘了还有行存。TiDB 不但拥有 TiFlash 列存引擎，也同时拥有相应的行存和配套的细粒度索引支持。

对于唯一值个数非常高的列（例如一个具体的时间，产品唯一序列号等等），一般来说列存很难有良好的手段进行精确过滤。例如在上述 OnTime 数据集中，对 CRSDepTime 计划起飞时间列进行索引，同样的查询还能变得更快。

统计所有在 18:45 分计划起飞的飞机总数。

mysql>selectcount(*)fromontimewhere1845=CRSDepTime;+----------+|count(*)|+----------+|766539|+----------+1rowinset(0.09sec)

而纯粹使用列存，在 MariaDB，Spark 以及 Greenplum 中，这样的查询分别是 0.447 vs 0.449 以及 1.576 秒——与 TiDB + TiFlash 存在 4 至 17 倍速度差！因为他们必须暴力扫表。

除此以外，TiDB 的行列混合并不是传统设计上的行存列存二选一，而是 TiDB 可以在同一张表同时拥有行存和列存，且两者永远保持数据强一致（而非最终一致）。

看到这里也许你要问，TiDB 同时拥有行存和列存是否反而会给用户带来心智负担？答案是并不会。何时使用行存或者列存，除了用户可以为了 HTAP 业务隔离而强制选择以外，你完全可以委托给 TiDB 自行选择。当行存更优（例如上面的案例），TiDB 则会凭借统计信息自动切换到行存进行读取：上面的查询在 TiFlash 上的性能只有 TiKV 行存 + 索引的一半。