时序数据库Influx-IOx源码学习七（Chunk的生命周期）

本文主要是介绍时序数据库Influx-IOx源码学习七（Chunk的生命周期），对大家解决编程问题具有一定的参考价值，需要的程序猿们随着小编来一起学习吧！

InfluxDB是一个由InfluxData开发的开源时序数据库，专注于海量时序数据的高性能读、写、高效存储与实时分析等，在DB-Engines Ranking时序型数据库排行榜上常年排名第一。

InfluxDB可以说是当之无愧的佼佼者，但 InfluxDB CTO Paul 在 2020/12/10 号在博客中发表一篇名为：Announcing InfluxDB IOx – The Future Core of InfluxDB Built with Rust and Arrow的文章，介绍了一个新项目 InfluxDB IOx，InfluxDB 的下一代时序引擎。

接下来，我将连载对于InfluxDB IOx的源码解析过程，欢迎各位批评指正，联系方式见文章末尾。

上一章介绍了数据从客户端写入到服务器端的内存中的整个过程。详情见： https://my.oschina.net/u/3374539/blog/5027429

这一章记录一下数据库中数据管理单元Chunk的生命周期。

在开篇，先介绍一下一个Chunk拥有的生命周期：

//这里需要注意，这些变体里的Chunk结构都是不相同的
//也就是有内存数据拷贝的工作
pub enum ChunkState {
    //内部移动数据时候用的
    Invalid,
    //可以写入
    Open(MBChunk),
    //还能继续写入，但很快会被关闭
    Closing(MBChunk),
    //已经不能写入了，准备移动到readbuffer
    Moving(Arc<MBChunk>),
    //已经被移动到了read buffer
    Moved(Arc<ReadBufferChunk>),
    //准备写入持久化存储
    WritingToObjectStore(Arc<ReadBufferChunk>),
    //写入持久化存储完成
    WrittenToObjectStore(Arc<ReadBufferChunk>, Arc<ParquetChunk>),
}

在第五章中有提到，在Create Database之后，会启动一个后台线程。

该后台线程完成了部分对Chunk的管理功能，通过理解这个后台线程，能够基本理解Chunk的所有生命周期。

    //后台线程的方法入口，在创建完成数据库后，就会调用到这个方法
    pub async fn background_worker(
        self: &Arc<Self>,
        shutdown: tokio_util::sync::CancellationToken,
    ) {
        //创建一个定时器，周期性的执行
        let mut interval = tokio::time::interval(tokio::time::Duration::from_secs(1));
        let mut lifecycle_manager = LifecycleManager::new(Arc::clone(&self));
        //没有收到停止服务器时候的信号就一直执行，1秒一次
        while !shutdown.is_cancelled() {
            //记录执行的次数，每次加1，Ordering::Relaxed代表的单线程里的原子操作
            self.worker_iterations.fetch_add(1, Ordering::Relaxed);
            //进入生命周期的管理
            lifecycle_manager.check_for_work();
            //收到不同信号之后的处理方法
            tokio::select! {
                _ = interval.tick() => {},
                _ = shutdown.cancelled() => break
            }
        }

        info!("finished background worker");
    }

前方高能，请注意：

fn check_for_work(&mut self, now: DateTime<Utc>) {
        //获取创建数据库的时候，对于Chunk的相关配置
        let rules = self.rules();
        //根据配置的排序规则，获取出内存里所有的chunk
        let chunks = self.chunks(&rules.sort_order);

        let mut buffer_size = 0;

        //判断是不是有其他的任务正在执行，move我理解针对于read buffer，write对于持久化
        let mut move_active = self.is_move_active();
        let mut write_active = self.is_write_active();

         //遍历所有块，检查哪些块可以被持久化
        for chunk in &chunks {
            //获取当前chunk的锁
            let chunk_guard = chunk.upgradable_read();
            //获取chunk占用的内存大小
            buffer_size += Self::chunk_size(&*chunk_guard);
            //没有移动任务并且Chunk里最后的写入时间比较老
            let would_move = !move_active && can_move(&rules, &*chunk_guard, now);
            //没有写出任务，并且开启了持久化
            let would_write = !write_active && rules.persist;

            //判断chunk的生命周期
            match chunk_guard.state() {
                 //属于open状态，并且是需要移动的（上面的逻辑里有展示什么是需要移动的）
                 //这里我理解就是相当于实时写入时候的一个补充方案
                 //试想，如果一个chunk一直不写入数据，可能有一年了，查询都不再用这些数据了，内存却被一直占用
                ChunkState::Open(_) if would_move => {
                    let mut chunk_guard = RwLockUpgradableReadGuard::upgrade(chunk_guard);
                    //切换状态到closing
                    chunk_guard.set_closing().expect("cannot close open chunk");
                    let partition_key = chunk_guard.key().to_string();
                    let chunk_id = chunk_guard.id();
                    std::mem::drop(chunk_guard);
                    move_active = true;
                    //移动到read_buffer，变为不可写入状态（启动了一个异步的线程，后面看）
                    self.move_to_read_buffer(partition_key, chunk_id);
                }
                //这里有几种情况，同样会在别处触发为closing
                //例如：chunk大小超过了设置的可变内存大小的时候
                ChunkState::Closing(_) if would_move => {
                    let partition_key = chunk_guard.key().to_string();
                    let chunk_id = chunk_guard.id();
                    std::mem::drop(chunk_guard);
                    move_active = true;
                    //移动到read_buffer
                    self.move_to_read_buffer(partition_key, chunk_id);
                }
                //已经被挪动到readbuffer中的
                ChunkState::Moved(_) if would_write => {
                    let partition_key = chunk_guard.key().to_string();
                    let chunk_id = chunk_guard.id();
                    std::mem::drop(chunk_guard);
                    write_active = true;
                    //写入到对象存储
                    self.write_to_object_store(partition_key, chunk_id);
                }
                _ => {}
            }
        }
        //这里是主要检查内存限制的逻辑，当所有chunk的大小超过限制的时候就要清理Chunk
        if let Some(soft_limit) = rules.buffer_size_soft {
            let mut chunks = chunks.iter();

            while buffer_size > soft_limit.get() {
                match chunks.next() {
                    Some(chunk) => {
                        //获取读锁
                        let chunk_guard = chunk.read();
                        //如果配置了可以清理未持久化数据，那么处在read_buffer里的数据也会被清理
                        //一定会清理已经被持久化到对象存储上的数据
                        if (rules.drop_non_persisted
                            && matches!(chunk_guard.state(), ChunkState::Moved(_)))
                            || matches!(chunk_guard.state(), ChunkState::WrittenToObjectStore(_, _))
                        {
                            let partition_key = chunk_guard.key().to_string();
                            let chunk_id = chunk_guard.id();
                            buffer_size =
                                buffer_size.saturating_sub(Self::chunk_size(&*chunk_guard));
                            std::mem::drop(chunk_guard);
                            //真真正正的删除逻辑后面看
                            self.drop_chunk(partition_key, chunk_id)
                        }
                    }
                    //没有什么可以释放的了
                    None => {
                        warn!(db_name=self.db_name(), soft_limit, buffer_size,
                              "soft limited exceeded, but no chunks found that can be evicted. Check lifecycle rules");
                        break;
                    }
                }
            }
        }
    }

这里基本看清楚了Chunk的周期：

1. 在写入时候，如果没有Chunk就会open一个，并处在open状态。
2. 如果写入超过了一些限制，就会被标记为closing；如果数据时间超过了配置的时间，也会被标记为closing。标记为closing的会添加一个后台进程，准备将Chunk移动到read_buffer中。
3. 后台任务启动后，会标记为moving状态，此时禁止Chunk再写入任何数据。
4. 一旦移动完成，会被标记为moved。
5. 程序会对moved状态下的Chunk开始进行持久化。
6. 扫描任务会不断判断内存使用是否超过了限制，如果超过限制，会清理已经持久化的Chunk。如果配置了drop_non_persisted，会把read_buffer中未持久化的也删除掉。

然后继续看程序是怎样将一个chunk移动到read_buffer的，因为篇幅的影响，将会在下一篇介绍数据是怎样真正写入到持久化存储当中的。

pub async fn load_chunk_to_read_buffer(
        &self,
        partition_key: &str,
        chunk_id: u32,
    ) -> Result<Arc<DbChunk>> {
        //根据partition_key及chunk_id获取内存中存储的Chunk
        let chunk = {
            let partition = self
                .catalog
                .valid_partition(partition_key)
                .context(LoadingChunk {
                    partition_key,
                    chunk_id,
                })?;
            let partition = partition.read();

            partition.chunk(chunk_id).context(LoadingChunk {
                partition_key,
                chunk_id,
            })?
        };

        //设置当前的Chunk为Moving状态
        let mb_chunk = {
            let mut chunk = chunk.write();
            chunk.set_moving().context(LoadingChunk {
                partition_key,
                chunk_id,
            })?
        };
        info!(%partition_key, %chunk_id, "chunk marked MOVING, loading tables into read buffer");
        let mut batches = Vec::new();
        //这里是拿到Chunk中每个Cloumn的统计信息，分别是min，max，count
        let table_stats = mb_chunk.table_summaries();

        //从新创建一个ReadBufferChunk，后面准备把所有数据都拷贝到这里
        //还需要告诉内存管理这里新申请了多少空间
        let rb_chunk =
            ReadBufferChunk::new_with_memory_tracker(chunk_id, &self.memory_registries.read_buffer);

        for stats in table_stats {
            //把内存中的数据，全部重新拷贝一次，转换为arrow格式
            mb_chunk
                .table_to_arrow(&mut batches, &stats.name, Selection::All)
                //这里应该是还没有写完，如果出现错误，这个Chunk该怎么处理？
                .expect("Loading chunk to mutable buffer");
            //循环拷贝
            for batch in batches.drain(..) {
                rb_chunk.upsert_table(&stats.name, batch)
            }
        }

        let mut chunk = chunk.write();
        //更新写入缓存里的Chunk为Moved状态，同时Chunk内容修改为了ReadBuffer的Chunk
        //对于Chunk的结构后面看
        chunk.set_moved(Arc::new(rb_chunk)).context(LoadingChunk {
            partition_key,
            chunk_id,
        })?;

        //工作全部都完成了,调用做快照的方法,方法里什么都没做,返回新Chunk的一个Arc指针
        Ok(DbChunk::snapshot(&chunk))
    }

到这里基本清楚了整个Chunk的工作方式，因为Chunk这个名字被代码中重复使用到了，所以特意在文章末尾说一下都有什么Chunk。

//主要是存储一个数据块的描述信息，名字、最后写入时间等
Server::db::catalog::chunk
//数据从客户端直接写入的内存块
mutable_buffer::chunk
//在moving时候拷贝的新数据块，arrow结构
read_buffer::chunk
//parquet对应的chunk
parquet_file::chunk
//query模块下对PartitionChunk重新命名了一下
//对于相同的partition key的数据抽象的行为
query -> type Chunk: PartitionChunk;
//实现PartitionChunk定义的方法，对不同位置下的chunk的操作
//如ParquetFile、MutableBuffer等
server::db::chunk

好了就到这里，希望你也学到了很多

祝玩儿的开心

欢迎关注微信公众号：

或添加微信好友： liutaohua001

关键词：站长资讯中心，站长资讯，站长新闻

这篇关于时序数据库Influx-IOx源码学习七（Chunk的生命周期）的文章就介绍到这儿，希望我们推荐的文章对大家有所帮助，也希望大家多多支持为之网！