8.存储引擎TiFlash

TiFlash 简介

TiFlash 是 TiDB HTAP 形态的关键组件,它是 TiKV 的列存扩展,在提供了良好的隔离性的同时,也兼顾了强一致性。列存副本通过 Raft Learner 协议异步复制,但是在读取的时候通过 Raft 校对索引配合 MVCC 的方式获得 Snapshot Isolation 的一致性隔离级别。这个架构很好地解决了 HTAP 场景的隔离性以及列存同步的问题。

整体架构

上图为 TiDB HTAP 形态架构,其中包含 TiFlash 节点。

TiFlash 提供列式存储,且拥有借助 ClickHouse 高效实现的协处理器层。除此以外,它与 TiKV 非常类似,依赖同样的 Multi-Raft 体系,以 Region 为单位进行数据复制和分散(详情见《说存储》一文)。

TiFlash 以低消耗不阻塞 TiKV 写入的方式,实时复制 TiKV 集群中的数据,并同时提供与 TiKV 一样的一致性读取,且可以保证读取到最新的数据。TiFlash 中的 Region 副本与 TiKV 中完全对应,且会跟随 TiKV 中的 Leader 副本同时进行分裂与合并。

TiFlash 可以兼容 TiDB 与 TiSpark,用户可以选择使用不同的计算引擎。

TiFlash 推荐使用和 TiKV 不同的节点以做到 Workload 隔离,但在无业务隔离的前提下,也可以选择与 TiKV 同节点部署。

TiFlash 暂时无法直接接受数据写入,任何数据必须先写入 TiKV 再同步到 TiFlash。TiFlash 以 learner 角色接入 TiDB 集群,TiFlash 支持表粒度的数据同步,部署后默认情况下不会同步任何数据,需要按照按表构建 TiFlash 副本一节完成指定表的数据同步。

TiFlash 主要包含三个组件,除了主要的存储引擎组件,另外包含 tiflash proxy 和 pd buddy 组件,其中 tiflash proxy 主要用于处理 Multi-Raft 协议通信的相关工作,pd buddy 负责与 PD 协同工作,将 TiKV 数据按表同步到 TiFlash。

对于按表构建 TiFlash 副本的流程,TiDB 接收到相应的 DDL 命令后 pd buddy 组件会通过 TiDB 的 status 端口获取到需要同步的数据表信息,然后会将需要同步的数据信息发送到 PD,PD 根据该信息进行相关的数据调度。

核心特性

TiFlash 主要有异步复制、一致性、智能选择、计算加速等几个核心特性。

异步复制

TiFlash 中的副本以特殊角色 (Raft Learner) 进行异步的数据复制。这表示当 TiFlash 节点宕机或者网络高延迟等状况发生时,TiKV 的业务仍然能确保正常进行。

这套复制机制也继承了 TiKV 体系的自动负载均衡和高可用:并不用依赖附加的复制管道,而是直接以多对多方式接收 TiKV 的数据传输;且只要 TiKV 中数据不丢失,就可以随时恢复 TiFlash 的副本。

一致性

TiFlash 提供与 TiKV 一样的快照隔离支持,且保证读取数据最新(确保之前写入的数据能被读取)。这个一致性是通过对数据进行复制进度校验做到的。

每次收到读取请求,TiFlash 中的 Region 副本会向 Leader 副本发起进度校对(一个非常轻的 RPC 请求),只有当进度确保至少所包含读取请求时间戳所覆盖的数据之后才响应读取。

智能选择

TiDB 可以自动选择使用 TiFlash 列存或者 TiKV 行存,甚至在同一查询内混合使用提供最佳查询速度。这个选择机制与 TiDB 选取不同索引提供查询类似:根据统计信息判断读取代价并作出合理选择。

计算加速

TiFlash 对 TiDB 的计算加速分为两部分:列存本身的读取效率提升以及为 TiDB 分担计算。其中分担计算的原理和 TiKV 的协处理器一致:TiDB 会将可以由存储层分担的计算下推。能否下推取决于 TiFlash 是否可以支持相关下推。

使用 TiFlash

TiFlash 部署完成后并不会自动同步数据,而需要手动指定需要同步的表。

用户可以使用 TiDB 或者 TiSpark 读取 TiFlash,TiDB 适合用于中等规模的 OLAP 计算,而 TiSpark 适合大规模的 OLAP 计算,用户可以根据自己的场景和使用习惯自行选择。

按表构建 TiFlash 副本

TiFlash 接入 TiKV 集群后,默认不会开始同步数据。可通过 MySQL 客户端向 TiDB 发送 DDL 命令来为特定的表建立 TiFlash 副本:

ALTER TABLE table_name SET TIFLASH REPLICA count

该命令的参数说明如下:

  • count 表示副本数,0 表示删除。

对于相同表的多次 DDL 命令,仅保证最后一次能生效。例如下面给出的操作 tpch50 表的两条 DDL 命令中,只有第二条删除副本的命令能生效:

为表建立 2 个副本:

ALTER TABLE `tpch50`.`lineitem` SET TIFLASH REPLICA 2

删除副本:

ALTER TABLE `tpch50`.`lineitem` SET TIFLASH REPLICA 0

查看表同步进度

可通过如下 SQL 语句查看特定表(通过 WHERE 语句指定,去掉 WHERE 语句则查看所有表)的 TiFlash 副本的状态:

SELECT * FROM information_schema.tiflash_replica WHERE TABLE_SCHEMA = '<db_name>' and TABLE_NAME = '<table_name>'

查询结果中:

  • AVAILABLE 字段表示该表的 TiFlash 副本是否可用。1 代表可用,0 代表不可用。副本状态为可用之后就不再改变,如果通过 DDL 命令修改副本数则会重新计算同步进度。

  • PROGRESS 字段代表同步进度,在 0.0~1.0 之间,1 代表至少 1 个副本已经完成同步。

使用 TiDB 读取 TiFlash

TiDB 提供三种读取 TiFlash 副本的方式。如果添加了 TiFlash 副本,而没有做任何 engine 的配置,则默认使用 CBO 方式。

智能选择

对于创建了 TiFlash 副本的表,TiDB 优化器会自动根据代价估算选择是否使用 TiFlash 副本。具体有没有选择 TiFlash 副本,可以通过 desc 或 explain analyze 语句查看,例如:

desc select count(*) from test.t;

+--------------------------+---------+--------------+---------------+--------------------------------+

| id | estRows | task | access object | operator info |

+--------------------------+---------+--------------+---------------+--------------------------------+

| StreamAgg_9 | 1.00 | root | | funcs:count(1)->Column#4 |

| └─TableReader_17 | 1.00 | root | | data:TableFullScan_16 |

| └─TableFullScan_16 | 1.00 | cop[tiflash] | table:t | keep order:false, stats:pseudo |

+--------------------------+---------+--------------+---------------+--------------------------------+

3 rows in set (0.00 sec)

explain analyze select count(*) from test.t;

+--------------------------+---------+---------+--------------+---------------+----------------------------------------------------------------------+--------------------------------+-----------+------+

| id | estRows | actRows | task | access object | execution info | operator info | memory | disk |

+--------------------------+---------+---------+--------------+---------------+----------------------------------------------------------------------+--------------------------------+-----------+------+

| StreamAgg_9 | 1.00 | 1 | root | | time:83.8372ms, loops:2 | funcs:count(1)->Column#4 | 372 Bytes | N/A |

| └─TableReader_17 | 1.00 | 1 | root | | time:83.7776ms, loops:2, rpc num: 1, rpc time:83.5701ms, proc keys:0 | data:TableFullScan_16 | 152 Bytes | N/A |

| └─TableFullScan_16 | 1.00 | 1 | cop[tiflash] | table:t | time:43ms, loops:1 | keep order:false, stats:pseudo | N/A | N/A |

+--------------------------+---------+---------+--------------+---------------+----------------------------------------------------------------------+--------------------------------+-----------+------+

cop[tiflash] 表示该任务会发送至 TiFlash 进行处理。如果没有选择 TiFlash 副本,可尝试通过 analyze table 语句更新统计信息后,再查看 explain analyze 结果。

需要注意的是,如果表仅有单个 TiFlash 副本且相关节点无法服务,智能选择模式下的查询会不断重试,需要指定 Engine 或者手工 Hint 来读取 TiKV 副本。

Engine 隔离

Engine 隔离是通过配置变量来指定所有的查询均使用指定 engine 的副本,可选 engine 为 "tikv"、"tidb" 和 "tiflash"(其中 "tidb" 表示 TiDB 内部的内存表区,主要用于存储一些 TiDB 系统表,用户不能主动使用),分别有 2 个配置级别:

  1. TiDB 实例级别,即 INSTANCE 级别。在 TiDB 的配置文件添加如下配置项:

    [isolation-read]

    engines = ["tikv", "tidb", "tiflash"]

    实例级别的默认配置为 ["tikv", "tidb", "tiflash"]。

  2. 会话级别,即 SESSION 级别。设置语句:

    set @@session.tidb_isolation_read_engines = "逗号分隔的 engine list";

    或者

    set SESSION tidb_isolation_read_engines = "逗号分隔的 engine list";

    会话级别的默认配置继承自 TiDB 实例级别的配置。

最终的 engine 配置为会话级别配置,即会话级别配置会覆盖实例级别配置。比如实例级别配置了 "tikv",而会话级别配置了 "tiflash",则会读取 TiFlash 副本。当 engine 配置为 "tikv, tiflash",即可以同时读取 TiKV 和 TiFlash 副本,优化器会自动选择。

注意:

由于 TiDB Dashboard 等组件需要读取一些存储于 TiDB 内存表区的系统表,因此建议实例级别 engine 配置中始终加入 "tidb" engine。

如果查询中的表没有对应 engine 的副本,比如配置了 engine 为 "tiflash" 而该表没有 TiFlash 副本,则查询会报该表不存在该 engine 副本的错。

手工 Hint

手工 Hint 可以在满足 engine 隔离的前提下,强制 TiDB 对于某张或某几张表使用指定的副本,使用方法为:

select /*+ read_from_storage(tiflash[table_name]) */ ... from table_name;

如果在查询语句中对表设置了别名,在 Hint 语句中必须使用别名才能使 Hint 生效。比如:

select /*+ read_from_storage(tiflash[alias_a,alias_b]) */ ... from table_name_1 as alias_a, table_name_2 as alias_b where alias_a.column_1 = alias_b.column_2;

其中 tiflash[] 是提示优化器读取 TiFlash 副本,亦可以根据需要使用 tikv[] 来提示优化器读取 TiKV 副本。更多关于该 Hint 语句的语法可以参考 READ_FROM_STORAGE

如果 Hint 指定的表在指定的引擎上不存在副本,则 Hint 会被忽略,并产生 warning。另外 Hint 必须在满足 engine 隔离的前提下才会生效,如果 Hint 中指定的引擎不在 engine 隔离列表中,Hint 同样会被忽略,并产生 warning。

注意:

MySQL 命令行客户端在 5.7.7 版本之前默认清除了 Optimizer Hints。如果需要在这些早期版本的客户端中使用 Hint 语法,需要在启动客户端时加上 --comments 选项,例如 mysql -h 127.0.0.1 -P 4000 -uroot --comments。

三种方式之间关系的总结

上述三种读取 TiFlash 副本的方式中,Engine 隔离规定了总的可使用副本 engine 的范围,手工 Hint 可以在该范围内进一步实现语句级别及表级别的细粒度的 engine 指定,最终由 CBO 在指定的 engine 范围内根据代价估算最终选取某个 engine 上的副本。

TiFlash 支持的计算下推

注意:

TiDB 4.0.2 版本之前,TiFlash 不支持 TiDB 新排序规则框架,所以在 TiDB 开启新框架下的排序规则支持后不支持任何表达式的下推,TiDB 4.0.2 以及后续的版本取消了这个限制。

TiFlash 支持谓词、聚合下推计算以及表连接,下推的计算可以帮助 TiDB 进行分布式加速。暂不支持的计算类型是 Full Outer Join 和 DISTINCT COUNT,会在后续版本逐步优化。

目前下推连接 (Join) 的功能需要通过以下会话变量开启(暂不支持 Full Outer Join):

set @@session.tidb_opt_broadcast_join=1

目前 TiFlash 支持了有限的常用表达式下推,支持下推的表达式包括:

+, -, /, *, >=, <=, =, !=, <, >, ifnull, isnull, bitor, in, mod, bitand, or, and, like, not,

case when, month, substr, timestampdiff, date_format, from_unixtime, json_length, if, bitneg, bitxor, round without fraction, cast(int as decimal), date_add(datetime, int), date_add(datetime, string)

其中,cast 和 date_add 的下推默认不开启,若需要手动开启,请参考优化规则及表达式下推的黑名单

目前 TiFlash 不支持下推的情况包括:

  • 所有包含 Duration 的表达式均不能下推

  • 在聚合函数或者 WHERE 条件中包含了不在上述列表中的表达式,聚合或者相关的谓词过滤均不能下推

如查询遇到不支持的下推计算,则需要依赖 TiDB 完成剩余计算,可能会很大程度影响 TiFlash 加速效果。对于暂不支持的表达式,将会在后续陆续加入支持,也可以联系官方沟通。

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值