谈谈RocksDB的Compaction2

已于 2025-06-22 18:54:40 修改
阅读量930 收藏 8
点赞数 18
CC 4.0 BY-SA版权
分类专栏： rocksdb 文章标签： rocksdb
于 2024-02-19 20:40:33 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/dlf123321/article/details/136177831

目录

前文已经明确了一次compaction的源层文件与目标层文件。
这次，咱们聊聊怎么具体的执行一次compaction。

线程调度

RocksDB 的 compaction 触发入口是 DBImpl::MaybeScheduleFlushOrCompaction。在这里使用线程池 开启一个个compact任务
它主要包括3种触发方式：

  1. switch wal：当 WAL 的文件大小超过阈值时
  2. writer buffer full：当 memtable 写满时
  3. schedule compaction：其余由更上层逻辑触发的 compaction，如 manual compaction
    前两种的调用路径分别是：
DBImpl::WriteImpl
	DBImpl::PreprocessWrite
		DBImpl::SwitchWAL
			DBImpl::MaybeScheduleFlushOrCompaction
      
DBImpl::WriteImpl
	DBImpl::PreprocessWrite
		DBImpl::HandleWriteBufferFull
			DBImpl::MaybeScheduleFlushOrCompaction

在MaybeScheduleFlushOrCompaction内部，在最终调用

env_->Schedule(&DBImpl::BGWorkCompaction, ca, Env::Priority::LOW, this,
                   &DBImpl::UnscheduleCompactionCallback);

之前会判断unscheduled_compactions_是否大于0.也就是判断是否有需要进行compact的任务。
而unscheduled_compactions_的更新是在SchedulePendingCompaction，它的调用流程是：

  DBImpl::BackgroundFlush
   	DBImpl::FlushMemTablesToOutputFiles
  		DBImpl::FlushMemTableToOutputFile
  			DBImpl::InstallSuperVersionAndScheduleWork
  				DBImpl::SchedulePendingCompaction
   in SchedulePendingCompaction  unscheduled_compactions_++ and AddToCompactionQueue

之后的流程就是

DBImpl::MaybeScheduleFlushOrCompaction
	env_->Schedule(&DBImpl::BGWorkCompaction, ca, Env::Priority::LOW, this,
                   &DBImpl::UnscheduleCompactionCallback);
                   	ca.db->BackgroundCallCompaction();
      					DBImpl::BackgroundCompaction
      						ColumnFamilyData::PickCompaction

上面的PickCompaction就是获取compact需要的文件信息

启动新的线程来执行compaction

划分subCompaction

具体的代码在DBImpl::BackgroundCompaction。
之前生成的Compaction信息（包含源与目标文件的那个结构图），会再被包装成一个CompactionJob。
接着会调用CompactionJob::Prepare，它的功能就是把一个Compaction内部可以并发的部分拆解成多个subCompaction，然后放入CompactionState里面的sub_compact_states里。

示意图如下：
在这里插入图片描述
更详细的内容大家可以参考
https://kernelmaker.github.io/Rocksdb_Study_5
不过默认情况下DBOptions::max_subcompactions的值是1，也就是不开启subCompaction。
不过这里，大家得注意，subcompactions的逻辑只对从L0发起的合并开启，如果是L2到L3的合并，就不能使用这个逻辑了

处理每个subCompaction

相关的代码在

Status CompactionJob::Run() {
  for (size_t i = 1; i < compact_->sub_compact_states.size(); i++) {
    thread_pool.emplace_back(&CompactionJob::ProcessKeyValueCompaction, this,
                             &compact_->sub_compact_states[i]);
  }

  // Always schedule the first subcompaction (whether or not there are also
  // others) in the current thread to be efficient with resources
  ProcessKeyValueCompaction(&compact_->sub_compact_states[0]);

  // Wait for all other threads (if there are any) to finish execution
  for (auto& thread : thread_pool) {
    thread.join();
  }
}

可以看到上面核心的逻辑就在ProcessKeyValueCompaction里面。

读出sst数据

在ProcessKeyValueCompaction里面第一步就是构造迭代器

  // compaction_job.cc
  std::unique_ptr<InternalIterator> input(
      versions_->MakeInputIterator(read_options, sub_compact->compaction,
                                   &range_del_agg, file_options_for_read_));

在MakeInputIterator里面：
对0层的每个sst 建立一个table_cache 迭代器
对非L0的那一层，整体建立一个LevelIterator
最终通过NewMergingIterator，把两组迭代器(我们叫children iterator)合并产生一个InternalIterator。这里面的具体数据结构与实现有点麻烦，但是作用还是很清楚的：

children iterator为：
= Child Iterator 1 =
InternalKey(user_key=“Key1”, seqno=10, Type=Put) | Value = “KEY1_VAL2”
= Child Iterator 2 =
InternalKey(user_key=“Key1”, seqno=9, Type=Put) | Value = “KEY1_VAL1”
InternalKey(user_key=“Key2”, seqno=15, Type=Delete) | Value = “KEY2_VAL1”
InternalKey(user_key=“Key4”, seqno=5, Type=Put) | Value = “KEY4_VAL1”
= Child Iterator 3 =
InternalKey(user_key=“Key2”, seqno=16, Type=Put) | Value = “KEY2_VAL2”
InternalKey(user_key=“Key3”, seqno=7, Type=Delete) | Value = “KEY3_VAL1”

MergingIterator将所有children iterator放入堆中，使其有序
InternalKey(user_key=“Key1”, seqno=10, Type=Put) | Value = “KEY1_VAL2”
InternalKey(user_key=“Key1”, seqno=9, Type=Put) | Value = “KEY1_VAL1”
InternalKey(user_key=“Key2”, seqno=16, Type=Put) | Value = “KEY2_VAL2”
InternalKey(user_key=“Key2”, seqno=15, Type=Delete) | Value = “KEY2_VAL1”
InternalKey(user_key=“Key3”, seqno=7, Type=Delete) | Value = “KEY3_VAL1”
InternalKey(user_key=“Key4”, seqno=5, Type=Put) | Value = “KEY4_VAL1”

最终返回的InternalIterator，实现了seek，next等方法，说白了通过InternalIterator我们就能有序的读取需要进行caompaction的两个level的多个sst文件了。
具体来说
最外层通过下面的result 拿到compact级别的两层的所有sst的一个有序的kv对

 // version_set.cc
  InternalIterator* result =
      NewMergingIterator(&c->column_family_data()->internal_comparator(), list,
                         static_cast<int>(num));

构造MergingIterator的时候把两层的两个InternalIterator都交给了 MergingIterator的children_
同时用这些childer构造成了一个MergerMinIterHeap minHeap_;
这是一个小跟堆，里面任何一个根节点都小于它的子节点。
同时 MergingIterator的current_变量就指向minHeap_的根节点。
我们看看 MergingIterator的next方法就明白 这个小跟堆的作用了
virtual void Next() override
{
current_->Next();
if (current_->Valid())
{
minHeap_.replace_top(current_);
}
else
{
minHeap_.pop();
}
current_ = CurrentForward();
}​
但是 但是 我们知道 通过MergingIterator 我们拿到了在compact的时候两层逻辑下有序的kv对。
但是这里面有墓碑呀。
所以在MergingIterator外面还有一个 CompactionIterator。它处理的就是 墓碑相关的逻辑（包含墓碑但不限于墓碑）
更具体的请参考 https://blog.csdn.net/dlf123321/article/details/141938746

之后的逻辑是

    IterKey start_iter;
    start_iter.SetInternalKey( sub_compact->start, kMaxSequenceNumber, kValueTypeForSeek);
    input->Seek(start_iter.GetInternalKey());
    sub_compact->c_iter.reset(new CompactionIterator(input.get()));
    while (status.ok() && !cfd->IsDropped() && c_iter->Valid()) {
		    // Invariant: c_iter.status() is guaranteed to be OK if c_iter->Valid()
		    // returns true.
		    const Slice& key = c_iter->key();
		    const Slice& value = c_iter->value();

		    // Open output file if necessary
		    if (sub_compact->builder == nullptr) {
		      status = OpenCompactionOutputFile(sub_compact);
		      if (!status.ok()) {
		        break;
		      }
		    }
		    status = sub_compact->AddToBuilder(key, value);
    }

如上代码里AddToBuilder就算把一个个key写到sst里面了。这部分代码和从immemtable到sst的逻辑一致，参见：
https://blog.csdn.net/dlf123321/article/details/136337948 里面的 把数据从immemtable刷新到sst文件 一节

这里还有一个问题，compcat的时候数据是从源层不断读出来，然后加入到sst里面。那么什么时候开启新的sst呢？
1 当sst的容量超过了那那个限定值。
2 如果当目标层的那个sst一旦加入了某个key之后，我们发现这个新的sst和更下一层的既有sst的交叠范围大于25倍的target_file_size_base，那就该停止了，后面就要产生一个新的sst了。

一些额外的功能点：

https://zhuanlan.zhihu.com/p/472115442
https://zhuanlan.zhihu.com/p/665221867
https://zhuanlan.zhihu.com/p/156848134
https://github.com/facebook/rocksdb/wiki/Compaction-Trivial-Move
https://zhuanlan.zhihu.com/p/581682601

rocksdb--compaction源码分析
杨凿让的博客
04-25 1184
前言 rocksdb有多种compaction策略，默认的compaction策略应该为leveled compaction，我们本次分析leveled compaction机制。本次分析主要涉及到几个问题： compaction何时被触发 compaction具体流程 compaction如何与mvcc机制联动 前置知识 一个库的SST文件有多个 每个SST文件都属于某一层 除了第0层的SST文件，其余层的SST文件之间都是有序的 除了第0层以外，其余层的大小都是固定的。c..
Flink面试题
qq_34936033的博客
05-17 5737
关于spark和flink我可能会问这20个问题,当然并不是说简单回答一下就可以了,每一个题都可以引申很多问题,拿第一个问题来说,里面还有很多东西,比如spark的依赖关系是存在什么地方?RDD的宽窄依赖划分等? 因为你如果什么问题都问,问三天三夜都问不完,所以一定有针对性,而且后面一定会有模拟场景现场编程的问题,因为上面的问题都是偏原理的,你不会你也可以背下来,但是编程就考验你的真实水平了,比如给你一个实时计算的场景,让你写出主要的代码实现.这也是为什么我在星球里面很少分享原理性的东西,更多的怎么解决真实
Rocksdb Compaction原理
weixin_34337265的博客
10-28 811
概述      compaction主要包括两类：将内存中imutable 转储到磁盘上sst的过程称之为flush或者minor compaction；磁盘上的sst文件从低层向高层转储的过程称之为compaction或者是major compaction。对于myrocks来说，compaction过程都由后台线程触发，对于minor compaction和major compaction分...
谈谈RocksDB的Compaction1
程序员小董的专栏
02-19 1236
L0层的分数就是L0层所有sst的文件总体积除以max_bytes_for_level_base，max_bytes_for_level_base 上文已经说了，默认256MB。当参数level_compaction_dynamic_level_bytes 是false的时候，很简单，L0的文件合并到L1，L1的文件合并到L2，L2的合并的L3。另外一点level_compaction_dynamic_level_bytes只影响L0的目标层，L1依然是合并到L2的。
RocksDB Compaction（一）介绍
lxzhong1的博客
02-21 3046
RocksDB是facebook开发的一款高性能的kv数据库，被广泛应用于各种工作场景中，并且它针对闪存进行了良好的优化。 RocksDB内部基于LSM tree的结构，LSM（Log-structured Merge Tree，日志结构化的合并书）这里就不多介绍，网上资料很多。总而言之，RocksDB先将写入缓存在内存中，然后定时刷入底层存储（该操作称为flush），这样做的优点是提供很快的写入速度。同时，在底层存储中，为了维护LSM tree的分层有序结构，RocksD...
Rocksdb Leveled-Compaction
zxl386122880的博客
04-27 454
From:  https://rocksdb.org.cn/doc/Leveled-Compaction.htmlStructure of the filesFiles on disk are organized in multiple levels. We call them level-1, level-2, etc, or L1, L2, etc, for short. A special ...
深度解读 RocketMQ 存储机制
数据库技术
07-03 231
RocketMQ 实现了灵活的多分区和多副本机制，有效的避免了集群内单点故障对于整体服务可用性的影响。存储机制和高可用策略是 RocketMQ 稳定性的核心，社区上关于 RocketMQ 目前存储实现的分析与讨论一直是一个热议的话题。本文想从一个不一样的视角，着重于作者眼中的这种存储实现是在解决哪些复杂的问题，因此我从本文最初的版本中删去了冗杂的代码细节分析，由浅入深的分析存储机制的缺陷与优化方向。...
rocksdb介绍之compaction流程
cocoti的博客
06-23 2895
rocksdb最常用的compaction方式是Leveled Compaction，首先介绍一下Leveled Compaction。参考 https://github.com/facebook/rocksdb/wiki/Leveled-Compaction数据库的数据存放在sst文件中，sst文件有多个，会分到不同的level(L0,L1,L2…)中。最新的数据先保存在内存中，满足一定条件后写入到L0的sst文件，sst文件写入后不会再进行修改，只能读取、删除。L0有几个文件数量相关的配置： 当L0层的
Rocksdb Compaction源码详解（二）：Compaction 完整实现过程 概览
热门推荐
天行健，地势坤
07-26 1万+
Rocksdb的compaction流程可以说是比较核心的流程了，它的存在除了保证不同sst 文件之间的key-value之间的有序性，数据的压缩存储，清理过时数据之外，还需要在存储细节上做一些优化来进一步提升LSM tree的读性能（Range tombstone的构造，提升了deleteRange区间的key-value的判断效率；filter block的创建，提升判断一个key是否存在的概率；index block的创建，支持二分查找和hash map的查找，提升针对普通key-value的查找性
RocksDB的Compaction : Leveled Compaction 和 Universal Compaction
qq_40586164的博客
06-14 4291
文章目录Compaction算法LeveledTieredRocksDB的CompactionLeveled Compactionwhich level to compactsubcompactionUniversal CompactionCompaction Picking Algorithm前置条件1、由Space Amplification触发的压缩2、由Individual Size Ratio触发的压缩3、由 number of sorted runs 触发的压缩4、由 age of data 触
RocksDB学习笔记#6 Compaction流程(1) —— 触发流程
最新发布
qq_38876396的博客
11-04 1476
本文介绍了RocksDB的手动触发、自动触发机制和流程。
RocksDB Compaction的常见问题
大隐隐于野
09-30 1838
在RocskDB内每个Column Family都分配了一个ID，在SST文件有Column Family ID，默认L1层sst file的大小由参数target-file-size-base决定，L2-Lmax的sst文件大小为target-file-size-base*target_file_size_multiplier (默认为1), TiDB内支持参数target-file-size-base，默认为8M。在进行读取时首先使用二分查找可能包含数据的文件，然后在文件内使用二分查找需要的数据。
rocksdb compaction流程理解
weixin_37871174的博客
06-29 1241
1、首先通过每层的分数score来决定那个level可以进行compaction操作。 2、然后启动这个compaction放在独立中等待线程调度处理 3、rocksdb对一个大的compaciton进行了切分，切分成了多个subcompation,然后多个subcompaction会通过子线程进行处理。多个线程会并发处理subcompation。 4、每个subcompation处理就是将这个subcompation包含的哪些两个level中的文件放在input数组中，然后通过一个mergeIter
聊聊RocksDB Compact
一缕阳光的博客
11-19 1139
导语对于 LevelCompact 策略，RocksDB会根据每一层不同的策略计算出CompactScore，根据CompactScore大小来决定那一层将会优先进行Compact，然后选择Level-N 和Level-(N+1）的文件进行Compact。如何计算CompactScore？ 如何选择文件进行Compact？Compact有哪些参数？如何知道RocksDB当前的一个状态？ ...
Rocksdb Compaction的文件读写
鲸鱼写程序的专栏
07-07 367
读文件 CompactionJob::processKeyValueCompaction CompactionIterator::Next MergingIterator::Next 正常读文件流程 compaction写文件: BlockBasedTableBuilder::Add BlockBasedTablebuilder::Flush BlockBasedTableBuilder::WriteBlock BlockBasedTableBuilder::WriteRaw...
谈谈Rocksdb的手动Compact
程序员小董的专栏
09-13 514
它默认是true，也就是说，如果我现在手动进行了一次compact，那么在我手动的compact执行完成之前，系统不会再进行内部的compact。也就是说即使L0的sst都满了，也不会把L0的sst往下刷，直到手动compact完成。执行上面的逻辑后，系统就会把L4之前在key1和key100范围内的sst都一层一层合并，最终保证在key1和key100范围内的sst都处于L4层。我已经没想明白为什么要这样，手动compact本身就是个低级别的事情，为什么要阻碍系统内部的compact呢？
Rocksdb 的 rate_limiter实现 -- compaction限速
天行健，地势坤
11-10 3330
LSM 引擎针 的业界相关优化方案已经有很多了，优化的方向也是在不同workload纬度上进行取舍。 比如头条的Amap ，中科的dCompaction 是为了降低Compaction的写放大（写放大除了消耗ss）
Rocksdb auto tune -- compaction的自动调优策略
天行健，地势坤
01-22 2167
从rate limter 到 auto tune 以及 auto tuned compaction的优化实战，主要为了解决write-stall导致的读长尾以及写吞吐降低问题。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值