tidb 删除语句在tikv里面怎么存储的

【 TiDB 使用环境】生产环境
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题:问题现象及影响】
tidb 删除一条数据,tikv里面是怎么存储的呀
Key_delete → Value ?


,有没有人知道原理呀,分享一下
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件:截图/日志/监控】

TiDB底层使用的是TiKV来存储数据,而TiKV使用的是LSM tree这种数据结构,它是一种append only模型,也就是说所有对数据的变更都体现在追加上。当删除一条数据时,实际上是将该数据的key标记为删除状态,而不是直接将其从磁盘中删除。这个被标记为删除状态的key会在后续的GC过程中被清理掉。因此,删除一条数据的实际操作是将该数据的key插入到TiKV中,并将其value设置为空。这个操作会生成一个Key_delete,对应的value为空。

key是row_id吗

在 TiDB 中,数据的 key 不是 row_id,而是由表的主键和索引组成的。TiDB 中的数据是以行的形式存储的,每一行数据都有一个唯一的主键,主键的值可以是任意类型,包括整数、字符串等。在 TiDB 中,主键和索引都是以 B+ 树的形式存储的,每个节点都包含多个 key-value 对,其中 key 是主键或索引的值,value 是指向数据行的指针。当 TiDB 执行查询操作时,会根据查询条件在 B+ 树上进行查找,找到对应的 key-value 对,然后根据指针找到对应的数据行。因此,TiDB 中的数据 key 不是 row_id,而是由主键和索引组成的。

如果你对源码比较感兴趣,你可以看看:

这是个持续学习的过程,如果你感兴趣一定要坚持一直学,一直看。

我理解删除的时候
key是
tablePrefix{TableID}_recordPrefixSep{RowID}delete{时间}

这个怎么理解都对, :upside_down_face:
但是要符合 rocksDB compaction filter 或者 compaction 处理过程的语义…

TiDB使用基于Percolator的事务模型,将一行数据抽象为default、write 和 lock 3 个 CF(column family)存储,其中:

  • default CF存储的真正数据
    ​​​${key}_${start_ts} --> ${value}​
  • write CF存储数据的版本信息,commit_ts代表一行记录的真正版本
    ​​​${key}_${commit_ts}-->${start_ts}​
  • lock CF存放锁信息,提交中的事务会加lock,包含primary lock的位置
    ​​​${key}-->${start_ts,primary_key,..etc}​
1 个赞

看这个三篇文章了解 TiDB 技术内幕 - 说存储 | PingCAP

image

1 个赞

region层面,tikv会追加一天已删除的记录。
lsm层面,在分裂或合并时,会把已删除的数据从物理上都删除。

将该数据的key标记为删除状态

追加,变成多版本,然后gc吧