TiDB开启列式存储

🛸 其他技术问题
1

TiDB开启列式存储后，磁盘层面具体是怎么存储的？和行存的物理存储差异在哪？

2 个赞
2
  • TiKV 节点 ： Key-Value, 负责行式存储（Row Store），处理 OLTP。
  • TiFlash 节点 ： DeltaTree, 负责列式存储（Column Store），处理 OLAP。
2 个赞
3

按列存储 ：数据按列 独立存储。例如，user 表的 name 列所有数据存储在一个文件中，age 列存储在另一个文件中

2 个赞
4

可以参考这两篇文章看看

2 个赞
5

列存是把一列数据保存在一起，而且是排序的，相同数据多压缩比也高减少了磁盘io数据量，扫描单个字段会很快

2 个赞
6
维度 行存储（TiKV） 列存储（TiFlash）
存储单元 按行打包，一行的所有列连续存储 按列拆分，同一列的所有行连续存储
数据读取 读取整行（即使只需要部分列），点查高效 仅读取所需列，聚合 / 分析查询高效
压缩效率 低（列类型混杂，重复度低） 高（同列数据类型统一，专属压缩算法）
物理文件组织 SST 文件按行 Key 有序排列 按列分块存储，列块 + 元数据文件分离
索引方式 基于行 Key 的全局有序索引 列块级轻量级索引（Min/Max、位图等）
适用场景 OLTP（增删改查、事务、低延迟点查） OLAP（聚合统计、批量分析、复杂查询）
2 个赞
7

个人理解行存是传统的存储模式，适合OLTP，方便用户点查的场景，比如：用客户号查询某个客户的个人信息，该客户的相关字段可以一次性获取到。列存则通常用于OLAP场景，如：报表系统跑批量计算任务。

2 个赞
8
  • 核心差异：行存（TiKV）按行打包存储，一列查询需加载整行；列存（TiFlash）按列拆分存储，仅加载目标列，且压缩比更高；
  • 磁盘结构：TiKV 是 LSM 树的 Key-Value 块，TiFlash 是列级数据块 + 轻量索引；
  • 落地特征：TiFlash 列存需创建副本，与 TiKV 强一致，自动适配 OLAP 查询，磁盘占用更低但写入效率略低。
2 个赞
9

列式存储数据放到tiflash里面，使用分析类的业务

10

TiKV（行存）：像书，一行行写，整行一起存。
TiFlash（列存）：像Excel 拆成单列，每一列单独存。

1 个赞
11

列存是以列为组织存储的，可能更好的进行编码压缩

12

tiflash列式存储，一般统计集合类sql

13

Kongdom分享的文章就很详细

14

数据以列存格式存储，每列独立成文件（或分块），物理上按Segment + Delta Tree组织

2 个赞
15

个人理解是
TiKV = 行存 = 交易业务的主场
TiFlash = 列存 = 分析业务的加速器

1 个赞
16

TiDB 列式存储（TiFlash）磁盘存储细节
TiFlash 作为独立列存副本，通过 Raft Learner 异步拉取 TiKV 的 Raft 日志，在本地将行数据重组织为纯列式结构持久化到磁盘TiDB

1.整体分层
逻辑层：沿用集群 Region 做 Raft 同步与调度（和 TiKV 一致）TiDB。
物理层：内部不再按行存储，而是使用自研 DeltaTree 列存引擎，以 Segment 为磁盘管理单元。
2.DeltaTree 磁盘结构（核心）
采用类 LSM 双层结构，区分增量与稳态数据，兼顾实时写入与分析读：
Delta Layer（增量层）：内存 + 磁盘小文件，存放近期写入 / 更新数据，支持随机修改，写入性能优先。
Stable Layer（稳态层）：磁盘大文件，按列独立连续存储，同列所有行数据挨在一起，高度压缩、只读，查询性能优先。
后台定期 Compaction：将 Delta 数据合并到 Stable，整理磁盘碎片、提升扫描效率。
3.文件形态
每张表的每一列对应独立磁盘文件，查询时只加载需要的列文件，大幅减少磁盘 I/O。
4.部署形态
默认本地盘部署；v7.0+ 支持存算分离，冷数据下沉到 S3 等对象存储，本地盘仅缓存热数据TiDB

2 个赞
18

开启列式存储后，TiDB 在 TiFlash 里用 DeltaTree 两层结构：新更新走行式小文件（Delta），后台合并成按列分文件的只读大文件（Stable，类 Parquet）；而 TiKV 行存是把整行编码成 KV 存在 RocksDB 的 LSM-Tree 里，磁盘上是行连续、列混杂。

19

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。