本期由 PingCAP 资深研发工程师 施闻轩 和大家介绍 TiFlash DeltaTree 引擎设计及实现解析 ，可深入理解 TiFlash 存储层 DeltaTree 引擎的读写工作流程及代码实现。本期重点讲了 DeltaTree 引擎的写路径相关原理实现。
全文回顾：TiFlash 源码阅读（三） DeltaTree 存储引擎设计及实现分析 - Part 1
资料下载：TiFlash DeltaTree Storage Engine (Part 1).pdf (2.2 MB)
视频回放： TiFlash DeltaTree 引擎设计及实现解析_哔哩哔哩_bilibili
现场 Q&A 解答：
Q：底层是个clickhouse吗？不需要单独安装的哈，是封装好的吧?
A:TiFlash 是基于 Clickhouse 2018 年的代码做了大幅度修改而来，自研了 TiFlash 高性能可更新列存引擎替换了 Clickhouse 原生的 MergeTree 列存引擎，并支持从 TiKV 的 Raft 协议同步数据。TiFlash 与 TiDB 生态无缝融合，不需要单独安装 Clickhouse。
Q： delta layer 是内存吗？
A：Delta Layer 中 MemTable 部分在内存中，其余部分存储在磁盘上（通过 PageStorage 存储）。刚写入的数据在 MemTable 中，定期 Flush 到磁盘上。
Q： 读可以读单列，写是不是也容易做到写单列？
A：引擎层面实现这个功能比较容易，但目前 TiFlash 数据的写入来源是 TiKV，在发生修改时 TiKV 总是以整行形式同步到 TiFlash，因此实际上还没有机会这么做。在传入相同更新数据（来自 TiDB）的情况下，DeltaTree (TiFlash) 比 LSM Tree (TiKV) 写放大略微少一些，因为 DeltaTree 的层数更少。
TiFlash 理论上很容易支持只保存某些列，但是选择不支持的主要原因主要是，如要查询需要其他列，重新同步的代价比较大。
Q：不太理解为什么要有stablelayer，delta和stable分开有什么好处？
A： 形式上类似于是个 2 层 LSM Tree，Delta 存放新数据，Stable 存放固化后的数据，两层合起来（Delta 优先）得到实际内容。
delta 数据量占比较小，通常占比 5% 左右。由于 delta 需要频繁的进行 minor compact，并且数据块更小（为了减少 io 放大），所以 delta 存储在 PageStorage 中（类似对象存储）。stable 则比较稳定。所以他们具有有不同的负载特征。典型场景 delta 的读 IOPS 比 stable 高一个数量级。将他们分开管理，可以进行针对性的优化。
Q：这个 Pack 内会有一些自定义的压缩吗？
A：TiFlash 目前支持 lz4，lz4hc，zstd 压缩算法，默认是 lz4。针对不同表的不同类型数据列设计针对性的压缩确实是一个有潜力的优化方向。
Q：pack=granularity?
A：Stable Layer 中的 pack 仅仅是个 IO 单位，作用类似于 RocksDB 中的 SST file block。
Q：mrk和idx为什么不合成一个？
A：这两个是服务于不同目的的，总的来说拆开做起来更简单一些，例如以后若想引入其他多种不同 Index，那么拆分后会更容易处理。当然，拆分并不总是最好，例如数据文件拆得过细可能会更容易让 inode 成为空间瓶颈，以及文件拆分也会难以实现 FileSystem 级别原子性操作。TiFlash 目前的拆分粒度在各个典型负载及环境下都能维持比较好的表现，也能兼顾工程维护性，是一个比较好的平衡点。
第一期源码解读资料和回顾：【资料+Q&A回顾】TiFlash 存储引擎的设计思路
第二期源码解读资料和回顾：【活动回顾 & 资料下载】TiFlash 源码解读（二）计算层 Overview