本节主要介绍 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 及其所有包含的存储结构将被删除。但是并非立即释放资源，要等所有引用失效且资源不被使用时执行清理。
以上便是分区的一生。
如果您有任何疑问，可以通过以下方式与我们进行交流：
钉钉群：33254054
github：https://github.com/oceanbase/oceanbase
博客问答：https://open.oceanbase.com/answer
