TiFlash：并不是另外一个 T + 1 列存数据库

在 上篇关于 TiFlash 的文章 发布后，咱们收到了不少伙伴们的反馈，你们有各类各样的疑问，包括 TiFlash 是否是 T + 1 列存数据库？为啥实时写入也很快？读压力大怎么办？节点挂了怎么办？业务怎么接入？……今天咱们就来详细回复一下你们的问题，但愿能对你们理解和实践 TiFlash 有所帮助。

并不是「另外一个 T + 1 列存数据库」

首先，它并非独立的列存数据库：TiFlash 是配合 TiDB 体系的列存引擎，它和 TiDB 无缝结合，在线 DDL、无缝扩容、自动容错等等方便运维的特色也在 TiFlash 中获得继承。

其次，TiFlash 能够实时与行存保持同步。

T + 1 问题

「为什么要列和 MySQL 的对比呢？这样是否太无聊？」

因为 TiFlash 具有实时高频实时更新能力，所以咱们在 上一篇 介绍中单机对单机比较了交易型数据库例如 MySQL，由于这些特色通常是行存引擎具有的优点。TiFlash 与大多数列存不一样的是，它支持实时更新，而且与行存数据保持同步。

「为什么说其余列存数据库没法更新？我看到 XX 支持 Update 呀？」

多数列存引擎并非绝对不支持更新，而是不支持主键或惟一性约束，所以没法像交易型数据库那样快速定位单条记录并进行一致性更新，这也是你没法向它们实时同步交易库数据的缘由。针对这样的设计，经常使用的更新方式是使用 ETL 去重和融合新老数据，而后批量导入列存，这就使得数据没法实时分析而需等待数小时甚至一天。

TiFlash 是为实时场景设计，所以咱们必须支持实时更新。在这个前提下，经过良好的设计和工程实现，也借助 ClickHouse 极速的向量化引擎，TiFlash 仍然拥有不亚于甚至超出其余列存引擎的优异性能。你们能够参考 上一篇文章中的 Benchmark 。

为何实时写入也很快

「TiFlash 是列存，你们都说列存的实时写入很慢，TiFlash 呢？」

通过业界验证的实时更新列存方案是 Delta Main 设计。简单说，就是将须要更新数据与整理好的不可变列存块分开存放，读时归并，按期 Compact，而 TiFlash 也采起了相似设计思路。TiFlash 并不是是拍脑壳发明了一种可更新列存结构，而是参考了其余成熟系统设计，如 Apache Kudu，CWI 的 Positional Delta Tree 等的设计思路，TiFlash 的设计也兼具了 B+ 树和 LSM 的优点，在读写两端都有优异的性能（但牺牲了对 TiFlash 场景无用的点查性能）。因为无需考虑点查，所以 TiFlash 能够以进行惰性数据整理加速写入；因为引入了读时排序索引回写，所以哪怕 Compact 不那么频繁仍能够保持扫描高效，进一步减少写放大加速写入。

「TiFlash 进行 OLAP 读取的时候会影响 OLTP 性能吗？」

上篇文章 中已经展现过 TiFlash 的读取性能：

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

下面带你们看看更新写入速度，这里作了个简单的写入测试：

• 测试配置 3 节点 6 TiKV（3 副本）+ 2 节点 TiFlash（2 副本）。
• sysbench write-only 测试。
• 以 60954.39 的 QPS 进行混合写入更新和删除。
• 同时 TiFlash 不断进行全表聚合计算。

测试结果是：

1. sysbench 运行 QPS 很是平稳，不会由于 AP 查询而抖动。从上图能够看到，黄色线段表明 AP 查询（开启和关闭），开启和关闭并不会对查询产生抖动，哪怕 999 分位。
2. TiFlash 能够很好匹配 TiKV 的实时写入（包含增删改而非仅仅插入）同时提供查询。
3. 另外，咱们也观测到，以大压力写入同时进行查询，经过对 5000 个 TiFlash Region 副本采样：读取时，进行一致性校对 + 追赶 + 写入的时间平均 27.31 毫秒，95分位在 73 毫秒，99分位是 609 毫秒，对于分析类查询，这个延迟稳定性是能够接受的。

实际上，在都只写 1 副本的状况下，TiFlash 的写入性能大体能够追上 2-3 个同规格 TiKV 节点，这确保了 TiFlash 在更少的资源配比下，也能够匹配 TiKV 的写入压力。

为什么如此？

因为 TiFlash 引擎针对 AP 场景无需点查的不一样设计，它相对 LSM 引擎减少了写放大比率：TiFlash 的写放大大约在 3-7 倍之间。且在写入约繁忙状况下，因为攒批效果反而越接近更小的三倍放大比率。而 LSM 结构下，RocksDB 的写放大在 10 倍左右。这个对比优点大大提升了 TiFlash 磁盘实际能承载的业务吞吐量。

方便敏捷的运维

灵活扩容

「若是读压力也很大，你光写得够快有啥用啊？」

虽然咱们展现了 TiFlash 的写入性能，其实哪怕它的写入速度不如 TiKV，咱们仍然能够单独对 TiFlash 进行扩容。无论 TiFlash 的写入性能多优秀，仍然有可能由于用户的查询读取压力过大而形成写入速度降低，这时候是否就会产生严重的复制延迟呢？

会。可是 TiFlash 却能够依靠 TiDB 的体系单独扩容，若是业务压力过大，多上线几台 TiFlash 节点就能够天然分担数据和压力，用户彻底无需操心扩容过程，这些都是透明且自动的。相对于同节点的行列混合设计，这样的架构无疑更灵活，且仍然保持了一致性。

自动恢复

「节点挂了怎么办？」

当 TiFlash 节点损坏下线，TiDB 体系能够保证 TiFlash 的数据自动从行存恢复副本，而补副本的过程也会考虑不对 TiKV 产生冲击。在 TiFlash 多副本的状况下，这个过程对用户也是彻底透明无感知的：你只须要将补充的服务器启动上线就行。

无阻塞 DDL

「TiFlash 支持 DDL 吗？」

TiFlash 继承了 TiDB 体系的在线 DDL，尤为是它支持了更改列类型。与传统列存系统须要彻底重写列格式不一样，TiFlash 支持混合表结构，每一个列数据块能够有独立的表结构，这使得 TiFlash 更改列类型是彻底实时且无负担的：没有数据须要被马上重写。这种设计，使得 TiFlash 能够很容易被用于数据集成场合，任何上游数据源的表结构变动能够无阻塞地被同步。

快速的业务接入

上述全部这些特性，使得 TiFlash 体系能够很是便捷地承载实时分析业务。考虑一下若是你有一个新业务上线，你须要将在线业务接入分析平台例如 Hadoop，你也许须要作以下事情：

1. 修改业务逻辑，在表结构中添加变动时间标记以便增量抽取。
2. 编写定时任务，从源数据库中抽取增量数据。
3. 将数据写入 Staging 表，经过和 Hive 目标表进行 JOIN 并回写以处理增量更新。
4. 极可能你还须要编写数据校验代码按期检查一致性。
5. 那么也意味着你须要编写不一致时的修复代码。

这个过程可能须要耗费数天，甚至更久，而你还须要维护整个传输链路。

在 TiDB + TiFlash 体系下，你只须要一条命令：

ALTER TABLE your_table SET TIFLASH REPLICA 1;

你就能够自动得到一份实时保持一致的列存数据镜像，进行实时分析。

5秒（取决于你的手速） vs 数天

即使你已经有完整的 Hadoop 数仓建设，TiFlash 配合 TiSpark，也能够轻松衔接两个平台的同时，为离线数仓提供实时分析能力。

欢迎尝鲜

TiFlash 已经在进行第一轮用户测试，并在近期开启第二批用户测试，请关注后续信息，也欢迎联系询问提早体验 maxiaoyu@pingcap.com。来信请注明以下信息：姓名，公司，业务场景，是否已是 TiDB 用户。