CompactOnExpiredCollector的工作不符合预期

[qiwei9743]

hi master,

代码里为meta cf和subkey cf配置了：新生成的sst文件中，删除/过期key比率达到30%时候，继续compact 当前sst文件的行为。但是存在以下2个问题

1. meta cf计算CompactOnExpiredCollector::NeedCompact不正确；计算delete key时候，算上了subkey的数量，然后subkey并不存在meta cf中，继续compact看起来不能带来收益，例如，h1, 200fields, h2,100fields, h3,100fields。 h1 expires, deletekeys=201, totalkeys=303, deletekeys/totalkeys > 0.3，经过compact后，只是回收了 h1, 这一个key，并不会回收subkey cf中对应的key，没看出来收益是什么？ 功能上，和trigger_threshold不是很相符。

2. MetadataFilter::Filter 过滤掉了过期的meta cf 导致 #1的逻辑不会生效；调用MetadataFilter::Filter，发现meta key过期了，那么过期的meta key不会调用 CompactOnExpiredCollector::AddUserKey。 当前，有时间差的情况，当调用MetadataFilter::Filter时候，metakey没过期，调用CompactOnExpiredCollector::AddUserKey的时候过期了的情况。当时我相信CompactOnExpiredCollector 不是为了这种情况设计的吧。因为这两个函数调用时间间隔非常短（毫秒的级别？）

烦请帮忙看一下，上面分析是否正确。

[git-hulk]

经过compact后，只是回收了 h1, 这一个key，并不会回收subkey cf中对应的key，没看出来收益是什么？ 功能上，和trigger_threshold不是很相符。

对于 SubKey Column Family 的回收是在 Compaction Checker 里面实现，里面的逻辑会依赖 Collector 生成的数据。NeedCompact 仅针对 Metadata Column Family 这个逻辑没有问题

MetadataFilter::Filter 过滤掉了过期的meta cf 导致 #1的逻辑不会生效；调用MetadataFilter::Filter，发现meta key过期了，那么过期的meta key不会调用 CompactOnExpiredCollector::AddUserKey。

Collector 只会在 Table Builder 阶段调用，Metadata Key 过期不需要去更新 Collector 的数据。也就是这些过期数据一定程度上必然不是实时的，所以依赖于 Compaction Checker 在时间上强制去做 Compaction 来更新这些数据。

我可能没有完全理解上面想表达的优化点是什么？如果有更好的策略也欢迎提出来。

[qiwei9743]

感谢大佬回复。
我上面提到的不是 优化，是疑问，我怕对代码理解错误，需要帮忙澄清一下。

对于 SubKey Column Family 的回收是在 Compaction Checker 里面实现，里面的逻辑会依赖 Collector 生成的数据。NeedCompact 仅针对 Metadata Column Family 这个逻辑没有问题

这个逻辑是理解的。只是看到代码NewCompactOnExpiredTableCollectorFactory(kMetadataColumnFamilyName, 0.3)，看着和实现不太符合，因为实现中，meta cf统计了 subkey的数量。对应我提的问题1.

Collector 只会在 Table Builder 阶段调用，Metadata Key 过期不需要去更新 Collector 的数据。也就是这些过期数据一定程度上必然不是实时的，所以依赖于 Compaction Checker 在时间上强制去做 Compaction 来更新这些数据。

这个逻辑也是理解的。我的疑问是，对于meta cf，CompactOnExpiredCollector::AddUserKey函数中，deleted_keys_ += metadata.size + 1;不会被执行吧。

抱歉，我没有描述清楚，重新描述一下我的问题。

问题1，compact meta cf的时候，为什么deleted_keys需要计算 subkey的数量，也就是deleted_keys_ += metadata.size + 1 ？ NeedCompact函数需要依赖metadata.size的原理是什么?

问题2， CompactOnExpiredCollector::AddUserKey函数中的deleted_keys_ += metadata.size + 1大概率是执行不到的代码；meta cf compact过程中，对于metakey1(已经过期了)，先调用MetadataFilter::Filter，把metakey1转换成entry_type rocksdb::kEntryDelete，导致调用CompactOnExpiredCollector::AddUserKey的时候，不会调用到deleted_keys_ += metadata.size + 1;

小优化，
1.我理解NewCompactOnExpiredTableCollectorFactory(kMetadataColumnFamilyName, 0.3)大概意图是解决大量tombs的问题，看起来使用rocksdb::CompactOnDeletionCollectorFactory可能是一个更好的选择。
2. 另外，基于相似的原理实现expire效果也会更好，因为key expire带来的负面效果和tombs是一样的。
3. Compaction Checker里compactrange开销可能有点大，可能 compactfile就够了? 如果使用compactfile导致下层文件tomb数量多，会因为needcompact再次触发compaction的。

谢谢

[git-hulk]

问题1，compact meta cf的时候，为什么deleted_keys需要计算 subkey的数量，也就是deleted_keys_ += metadata.size + 1 ？ NeedCompact函数需要依赖metadata.size的原理是什么?

这个数值主要是给 Compaction Checker 使用，Compaction Checker 会处理全部的 Column Family，所以更多会关心对应 Key 范围的 Key-Value 数量，不关心到底是哪个 Column Family(权重一致).

问题2， CompactOnExpiredCollector::AddUserKey函数中的deleted_keys_ += metadata.size + 1大概率是执行不到的代码；meta cf compact过程中，对于metakey1(已经过期了)，先调用MetadataFilter::Filter，把metakey1转换成entry_type rocksdb::kEntryDelete，导致调用CompactOnExpiredCollector::AddUserKey的时候，不会调用到deleted_keys_ += metadata.size + 1;

这个还是取决于 Compaction 调度，Metadata 不一定会比 SubKey 更加早被 Compaction，即使是 Metadata 更早回收也影响不是很大。

1.我理解NewCompactOnExpiredTableCollectorFactory(kMetadataColumnFamilyName, 0.3)大概意图是解决大量tombs的问题，看起来使用rocksdb::CompactOnDeletionCollectorFactory可能是一个更好的选择。

CompactOnExpiredTableCollector 就是为了实现 CompactOnDeletionCollector 不同的 Key 计算逻辑而自己实现的(见第一个问题)。