RocksDB: TrivialMove 与 db_bench 的 fillseq

RocksDB: TrivialMove 与 db_bench 的 fillseq

写这篇文章的起因是我用一晚上 debug 了一个“假想”错误,最后发现我是个憨批,然后因此认识了 RocksDB 的 TrivialMove 机制,并重新认识了 fillseq。

事情开始于我用 db_bench 去 load 数据,给的分布为 fillseq。在代码跑了一段时间之后,去看 /data,结果发现 SST 巨多,更要命的是,SST 从来都没有删除过。并且,每个 SST 都是同样的大小,8Mb,这是我设置的 target_file_size_base。也就是说,从结果上来看 Compaction 根本就没有执行过

为了验证这一想法,我在 Compaction 的调用链上逐步输出日志(这个调用链是真的复杂,每次看都头大),最后证明了 CompactionJob::Run 根本就没有执行。于是我开始怀疑是写的代码出问题了(我们对 RocksDB 进行了改动,不是怀疑 RocksDB 本身有错)。可问题是,NeedCompaction 确实执行了,PickCompaction 也能成功 Pick,并且最关键的,在内存中的 file_[level] 确确实实是分层了的,这就奇怪了。

也就是说,内存中是更改索引了,但磁盘没变。

于是我就开始追踪 Compaction 操作,最终在 BackgroundCompaction() 中的一个分支中找到了答案。

当 BackgroundCompaction 调用 PickCompaction 获取到 Compaction 任务 c 后,会根据 c 的状态进入不同的分支,一共有 5 个。而正常的生成 CompactionJob 是在第 5 个分支,而我则始终进入了第 3 个分支。第 3 个分支的实现体先不看,去看分支条件:

else if (!trivial_move_disallowed && c->IsTrivialMove()) {
  // ...
}

c->IsTrivialMove() 是什么?

通过名字猜一下,就是琐碎的移动。先不看 IsTrivialMove 的实现,去看分支体的代码,一句注释直接阐明答案:

Move files to next level

soga ! 这个分支体的工作和平常 CompactionJob 不一样,它不会删除 SST 然后合并成新的 SST,而是直接把 SST 给 “平移” 到下一层,目的很简单,减少 IO。而这个所谓的 “平移”,其实是内存中索引的移动,而不是磁盘中 SST 的移动,所以就产生了磁盘中 SST 不变但内存索引发生了变化这个现像,并且所有 SST 文件都是刚开始的 target_file_size_base。

然后去看 IsTrivialMove ,来看看如何判断是否能直接 “平移”。

bool Compaction::IsTrivialMove() const {
  // Avoid a move if there is lots of overlapping grandparent data.
  // Otherwise, the move could create a parent file that will require
  // a very expensive merge later on.
  // If start_level_== output_level_, the purpose is to force compaction
  // filter to be applied to that level, and thus cannot be a trivial move.

  // Check if start level have files with overlapping ranges
  if (start_level_ == 0 && input_vstorage_->level0_non_overlapping() == false) {
    // We cannot move files from L0 to L1 if the files are overlapping
    return false;
  }

  if (is_manual_compaction_ &&
      (immutable_cf_options_.compaction_filter != nullptr ||
       immutable_cf_options_.compaction_filter_factory != nullptr)) {
    // This is a manual compaction and we have a compaction filter that should
    // be executed, we cannot do a trivial move
    return false;
  }

  // Used in universal compaction, where trivial move can be done if the
  // input files are non overlapping
  if ((mutable_cf_options_.compaction_options_universal.allow_trivial_move) &&
      (output_level_ != 0)) {
    return is_trivial_move_;
  }

  if (!(start_level_ != output_level_ && num_input_levels() == 1 &&
          input(0, 0)->fd.GetPathId() == output_path_id() &&
          InputCompressionMatchesOutput())) {
    return false;
  }

  // assert inputs_.size() == 1

  for (const auto& file : inputs_.front().files) {
    std::vector<FileMetaData*> file_grand_parents;
    if (output_level_ + 1 >= number_levels_) {
      continue;
    }
    input_vstorage_->GetOverlappingInputs(output_level_ + 1, &file->smallest,
                                          &file->largest, &file_grand_parents);
    const auto compaction_size =
        file->fd.GetFileSize() + TotalFileSize(file_grand_parents);
    if (compaction_size > max_compaction_bytes_) {
      return false;
    }
  }

  return true;
}

当然,这个分支也很多,但是简单的归纳一下,可以解释为:当 SST 之间完全没有任何重叠时,可以直接平移。这是很合理的,因为没有重叠,就没必要在删除和重组文件来占用 IO 了。

再回过头来看 db_bench。我用的是 fillseq,我知道它是顺序写入,但没想过它是严格顺序,以至于所有的 SST 都不曾重叠,才导致了 Compaction 一直都是 TrivialMove。如果换成 fillrandom,那就全部都正常了。

所以这不是个 bug,而是一个优化机制。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值