TiKV 在删除大量 key 后做 scan 操作性能的问题

Hi,小伙伴们~ 如果我们在 TiKV 中删除了同一前缀下的大量 key,再去做前缀搜索的话,是不是性能有较大的降低?
因为我理解的是,TiKV 下面的存储层用的是 RocksDB,而 RocksDB 的删除只是插入一条 Delete 的记录,并不是真正的去删除 key,导致即使一个前缀下的所有 key 都删除光了,那么拿这个前缀去搜索的时候,也会遍历这个前缀下的所有已经删除的 key,详见 RocksDB issue #5265.
如果 TiKV 没有这个问题,那么是做了哪些优化呢?由于本人对 TiKV 实现并不是很熟悉,希望大家能提供一些思路或建议,非常感谢~

有优化,但是优化得有限,参考下血案,基本上能解答你的疑问了

但是有一点,裸tikv 和 tidb的架构在处理数据上还是有很大区别的

非常感谢你的回答~ 我还有点疑问,仅仅针对 RocksDB 这层,除了手动触发 CompactRange,是否还有其他优化?(我在相关资料文档并没有找到)
特别是针对被删了的 key 还在 memtables 中并没有被 flush 到 SST 时,这时候也是会增加 scan 的时长,针对这方面,上层有做什么优化吗?

我记得之前 full table scan 的时候,不会跳过这些 被删除的 keys,后来在 seek keys 的策略上做了个调整,好像有个 issue 吧,最后做了版本的修复,具体从哪个版本做的修复,我忘记了 :joy:

然后还是建议考虑最佳实践中提供的方式,来操作数据的删除,避坑~

你把gc时间调整到10分钟