GitHub user qiwei9743 added a comment to the discussion: CompactOnExpiredCollector的工作不符合预期
感谢大佬回复。 我上面提到的不是 优化，是疑问，我怕对代码理解错误，需要帮忙澄清一下。 > 对于 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是一样的。 谢谢 GitHub link: https://github.com/apache/kvrocks/discussions/2898#discussioncomment-12931086 ---- This is an automatically sent email for [email protected]. To unsubscribe, please send an email to: [email protected]
