初探 TiDB-TiFlash

作者： tplinux 原文来源：https://tidb.net/blog/9da1cede

简介 TiFlash

TiFlash 是 TiDB 生态组件之一，专门解决 OLAP 场景。借助 ClickHouse 实现高效的列式计算。

介绍 TiFlash 架构

一开始，我个人以为他会是用 binlog 或其他方式把数据同步到 TiFlash 中，读取数据有专门的接口，结果我的理解是错误的。

如图，TiFlash 是通过 TiKV 把数据同步到 TiFlash。大家都知道 TiKV 中的 Region 是分 leader 和 Follower。

TiFlash 通过 Region 的 leader 节点进行数据全量和增量同步。

增量同步是通过 Raft Log 异步复制，相当于 MySQL 的 redo log 同步。

我这里就好奇，为啥不通过 TiKV Follower 节点进行全量和增量的同步呢？

因为本身 TiKV 的数据就是强一致的，并且 TiKV 的 Leader 节点还要承担日常的读写压力。

答： 这个是因为 Raft 协议实现的问题，目前都是以 leader 为准的。（来自神秘好友的解答）

目前 TiKV 应该不支持读写分离，如果把同步的节点改完 TiKV 的 Follower 节点，也不会影响数据的一致性，并且能分担 Leader 节点的压力。

答： 这个的话，现在有 Follower Read 的功能，可以理解为读写分离，但是目前读是强一致性的，后续会允许异步读取数据，也就是从 follower 上读到一段时间之前的数据（来自神秘好友的解答）

核心特性

异步复制

TiFlash 节点和 TiKV 节点进行复制同步期间，发生网络延迟或者网络抖动，不会影响到 TiKV 的运行。如果 TiFlash 节点宕机了，也不会影响 TiKV 的运行。只要 TiKV 的数据不丢失，TiFlash 的数据就可以通过 TiKV 进行恢复。

简单来说 你可以把 TiFlash 和 TiKV 的关系理解为 MySQL 的主从架构。MySQL 主库和从库之间发生网络抖动，或者 MySQL 从库挂了。

并不会影响 MySQL 主库的写入和读取（这里说的是 MySQL 异步复制）。

智能选择

TiDB 可以自动选择使用 TiFlash 列存或者 TiKV 行存。不需要通过其他接口访问 TiFlash 。其实在这里就实现了一个入口根据实际 SQL 选择列存或者行存。

实验环境：2 张表一个是 sbtest1、sbtest2 有相同的数据。但 sbtest1 做了 TiFlash 同步，sbtest2 还是保留 TiKV 存储。

当 sbtest1 和 sbtest2 同时执行 count 的操作，二个表的执行计划就不同了。

发现 sbtest1 表走了 TiFlash 列存储，而 sbtest2 表则走了 TiKV 行存储。

实验 2：sbtest1 表执行不同的 SQL，选择行存或者列存就会发生转变。

计算加速

通过列式引擎来提升 TiDB 读取的效率的提升。

TiDB 架构中本身就实现了计算下推，把计算任务推给了存储引擎层也就是 TiKV。

在新增列式存储 TiFlash 环境中，TiFlash 也承担计算任务。

一致性

TiFlash 和 TiKV 一样提供快照隔离的支持，并且保证读取数据最新。这个一致性是通过复制进度校验来实现的。

每次接收到读取请求，TiFlash 会向 Leader 发起进度校对。

只有当进度确保至少所包含读取请求时间戳所覆盖的数据之后才响应读取。

部署 TiFlash

TiDB 版本大于 TiDB3.1 和 TiDB4.0 。在 tidb-ansible 找到

[tiflash_servers] 填写主机名和 data 目录。

其他操作和部署 TiDB 无异，目前官方推荐使用 TiUP 进行部署，可以参考官方。

需要注意的是 不建议 TiFlash 和 TiKV 混合部署，不建议部署多实例。

个人建议 TiFlash 的配置比 TiKV 的配置要高一点。

因为毕竟 TiFlash 要跑 OLAP 业务，消耗资源可能会多一点。

使用 TiFlash

TiFlash 接入后，默认不会进行数据同步。可以针对表来进行 TiFlash 副本。

按照表构建 TiFlash。

ALTER TABLE table_name SET TIFLASH REPLICA count

#count 表示副本数 ALTER TABLE table_name SET TIFLASH REPLICA 1

查看表的同步进度

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

TiSpark 可以直接读取 TiFlash 中的数据。

优点

业务可以通过 TiDB 直接跑 OLAP 场景的 SQL。

减少维护成本 数据库（MySQL）到分析类型的数据库（例如 hadoop）之间的链路同步工具。减少分析数据库（例如 hadoop）的维护成本。

美中不足

资源隔离和资源调度

虽然 TiFlash 和 TiKV 中有资源隔离。TiFlash 不会影响到 TiKV 的性能。

但我想说的是 TiFlash 里的资源调度。

如果大量的消耗资源的 SQL 在 TiFlash 中运行，TiFlash 会不会把整个系统的资源跑满？导致重要的其他 SQL 无法运行。

可以把一些慢的 不重要的 SQL 分配较少的系统资源。重要的 SQL 分配更多的系统资源。

总结 TiFlash 还是一款非常不错的组件，能够解决一些痛点，满足一些场景的需求，在官方持续维护下 TiFlash 的未来还是非常可期的。