OceanBase 源码解读（三）：分区的一生

引言

源码是OceanBase的“方向盘”，本系列主要围绕“源码解读”，通过文章阐述，帮助大家理清数据库的内在本质。此前，带你读源码第二篇《戳这里回顾：OceanBase源码解读（二）：SQL的一生》为大家介绍了OceanBase 数据库中一条 SQL 的执行流程主路径，包括接收、处理、返回结果给客户端的过程，探讨了OceanBase的SQL引擎模块。

本文为 OceanBase 数据库源码解读系列文章的第三篇，将主要为大家介绍 OceanBase  的存储层像相关知识。

正文

假若分区是 OceanBase 的一等公民。一个表由一个或者若干个分区组成，分区是 OceanBase 逻辑上水平可扩展概念和物理上数据组织的基本单位。分区是自包含的：每个分区有自己独立的选举和 leader，独立的事务日志、数据存储和索引。分区可大可小，一般大小在 G B量级，它可以被 RS 在多个节点之间调度以实现负载均衡。

每个分区有一个唯一标识 OBPartitionKey，由租户 id、表 id、分区 id 组成。从存储层来说，每个节点就是存储和组织这些 key 对应的分区副本，每个节点上可以有数万个副本。副本有多种类型，比如只读副本与主副本之间不是通过 paxos 协议，而是异步消息同步事务日志。

storage/ob_partition_service.h 是存储层的总入口，它对外提供了存储层的所有 RPC 服务，如创建删除分区副本。实际上，它是每个节点上所有分区级接口的入口，包括事务控制接口、分区读写的接口等。

前面讲过，建表和新增分区等 DDL 语句是由 RS 执行的，RS 在根据一定策略选定节点后，就会 RPC 调用这里的 create_xxx。

从这个入口一层一层追下去，可以找到所有存储结构。但存储层内部有大量类似的接口，很容易混淆。每个分区都是一个“索引组织表”，索引结构是多层的 LSM-Tree。虽然是多层，但是有参数可以调整，尽量只有内存里的 memtable（见storage/memtable）和磁盘上的 major sstable（见 storage/blocksstable）两层。每次 major compaction 的时候，memtable, minor sstable 的数据与原来的 major sstable 合并，产生新版本的 major sstable。在合并期间，可能有多个版本的 major sstable 同时提供服务。一个分区副本的多层存储结构合起来，就是类 OBPartitionStore。

分析到这里，大家还以为“分区是 OB 的一等公民”嘛吗？其实PG 才是。此 PG 非彼 PG。PG，Partition Group，表示共享同一个事务日志流和 memtable 的“有紧密关系的”一组分区。外部一般不使用这个特性，一般一个 PG 里面只有一个分区，这就是为什么这里的存储结构和操作对象会有奇怪的pg前缀和 OBPGKey了。

为了表达诚意，献上我画的存储结构相关类图。

一图胜千言。

sql/engine/table 是 SQL 物理执行计划中执行表扫描的算子，它通过 ob_partition_service.h 的 table_scan 接口获得一个迭代器（迭代结束要调用 revert_scan_iter），这就是存储层提供的数据访问入口。还有 DML（sql/engine/dml）使用的insert_rows, delete_rows, update_rows和lock_rows 等接口。

当分区或表被删除的时候，OBPGPartition 及其所有包含的存储结构将被删除。但是并非立即释放资源，要等所有引用失效且资源不被使用时执行清理。

以上便是分区的一生。在后续的源码解读第四篇我们将会为大家解析OceanBase 数据库事务的外部接口，敬请期待。

文章转载自公众号：OceanBase