TiFlash的速度快吗

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

那么 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：平均每月航班起降记录数

select avg(c1) from ( select year, month, count(*) as c1 from ontime group by year, month ) A;

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

select dayofweek, count(*) as c from ontime where year>=2000 and year<=2008 group by dayofweek order by c desc;

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

select dayofweek, count(*) as c from ontime where depdelay>10 and year>=2000 and year<=2008 group by dayofweek order by c desc;

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

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;

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

select carrier, count(*) from ontime where depdelay>10 and year=2007 group by carrier order by count(*) desc;

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

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;

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

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;

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

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;

查询 9：每年航班数

select year, count(*) as c1 from ontime group by year;

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

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;

真 · 行列混合

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

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

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

mysql> select count(*) from ontime where 1845 = CRSDepTime;+----------+| count(*) |+----------+|   766539 |+----------+1 row in set (0.09 sec)

而纯粹使用列存，在 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的速度快吗"的内容就介绍到这里了，感谢大家的阅读。如果想了解更多行业相关的知识可以关注网站，小编将为大家输出更多高质量的实用文章！