【TiKV / HTAP 内核】Key 编码与 MVCC：三 CF 与时间戳
内容提要
TiKV 将 Percolator 的锁、数据和写入三列映射为 RocksDB 的 CF_LOCK、CF_DEFAULT 和 CF_WRITE。通过时间戳的位反转实现 Key 编码规则，确保查询时优先返回最新版本。TiKV 的 MVCC 时间戳由 PD 的 TSO 提供，确保跨 Region 的全局一致性，区别于 RocksDB 的单机快照机制。这三种 CF 共同维护同一逻辑数据，需联合管理。
关键要点
-
TiKV 将 Percolator 的 lock、data、write 三列映射为 RocksDB 的 CF_LOCK、CF_DEFAULT 和 CF_WRITE。
-
TiKV 的 Key 编码规则通过时间戳的位反转实现，确保查询时优先返回最新版本。
-
TiKV 的 MVCC 时间戳由 PD 的 TSO 提供，确保跨 Region 的全局一致性。
-
CF_LOCK 里的 Key 不带时间戳，因为同一 user key 在任意时刻最多只能有一把未提交的锁。
-
CF_DEFAULT 和 CF_WRITE 需要保留同一个 user key 的多个历史版本，因此在 Key 后面追加时间戳。
-
TiKV 的 MVCC 版本链允许不同事务在同一 Key 空间里共存，读请求通过时间戳过滤实现快照隔离。
-
TiKV 的 MVCC 时间戳与 RocksDB 的 Snapshot 机制是两种独立的机制，前者跨 Region 全局一致，后者仅在单个实例内有效。
-
三种 CF 共同维护同一逻辑数据，需联合管理，不能独立处理。
延伸解读
TiKV 的三种 CF 角色
TiKV 将 Percolator 的 lock、data、write 三列映射为 RocksDB 的 CF_LOCK、CF_DEFAULT 和 CF_WRITE。这三种 Column Family 各自承担不同的角色，CF_LOCK 负责未提交事务的锁信息，CF_DEFAULT 存储用户实际写入的值，而 CF_WRITE 则记录已提交事务的提交信息。理解这些角色有助于更好地管理和优化数据存储。
时间戳编码的重要性
TiKV 通过时间戳的位反转来实现 Key 编码规则，使得最新版本的记录在查询时优先返回。这种设计不仅提高了查询效率，还确保了数据的一致性。开发者在设计数据模型时，应考虑时间戳的处理方式，以优化数据访问性能。
MVCC 与 RocksDB Snapshot 的区别
TiKV 的 MVCC 时间戳由 PD 的 TSO 提供，确保跨 Region 的全局一致性，而 RocksDB 的 Snapshot 机制仅在单个实例内有效。这两者解决了不同的问题，开发者在使用时需明确其适用场景，避免混淆。
延伸问答
TiKV 如何映射 Percolator 的三列模型？
TiKV 将 Percolator 的 lock、data、write 三列映射为 RocksDB 的 CF_LOCK、CF_DEFAULT 和 CF_WRITE。
TiKV 的 Key 编码规则是什么？
TiKV 的 Key 编码规则通过时间戳的位反转实现，确保查询时优先返回最新版本。
TiKV 的 MVCC 时间戳是如何提供的？
TiKV 的 MVCC 时间戳由 PD 的 TSO 提供，确保跨 Region 的全局一致性。
CF_LOCK 中的 Key 为什么不带时间戳？
CF_LOCK 中的 Key 不带时间戳，因为同一 user key 在任意时刻最多只能有一把未提交的锁。
TiKV 的 MVCC 版本链有什么特点？
TiKV 的 MVCC 版本链允许不同事务在同一 Key 空间里共存，读请求通过时间戳过滤实现快照隔离。
TiKV 的 MVCC 与 RocksDB 的 Snapshot 有什么区别？
TiKV 的 MVCC 时间戳是跨 Region 的全局一致性机制，而 RocksDB 的 Snapshot 仅在单个实例内有效。
