OceanBase 列存设计哲学：一套架构下的行、列与行列混存

作者 | 曹晖，OceanBase 研发团队技术专家，现从事存储引擎开发工作。

当前企业数据处理普遍面临一种架构上的两难：若采用“行存数据库（如 MySQL）+ 列存分析库（或外挂引擎）”的分离方案，虽能各自应对事务与分析，却不得不忍受数据同步延迟、存储冗余和运维复杂的高昂代价。这不仅让实时分析变得困难，更意味着业务决策总是基于“过去”的状态，而非当下。

作为数据库内核开发者，我们深知这种割裂之痛，也目睹了外挂列存方案在数据一致性和运维复杂度上的妥协。因此，在 OceanBase 列存引擎设计之初，我们就确立了一个核心原则：一体化而非外挂。

我们选择了一条更艰难但更彻底的道路——基于 OceanBase LSM-Tree “基线-增量”分离架构，让列存与行存在存储、事务、SQL 三层语义上实现天然统一。

具体而言，增量数据维持行格式以保证高效更新与事务 ACID，基线数据则转为列格式以实现极致的压缩与扫描性能。对用户而言，这一切都是透明的：优化器自动选择最优执行路径，所有 DDL、备份恢复等生态工具均可复用。

只需一行 CREATE TABLE … WITH COLUMN GROUP  语句，即可在同一套系统中无缝获得实时分析能力，无需双写、ETL 或修改业务代码。

本文将深入剖析 OceanBase 列存存储引擎的设计理念、核心架构、关键技术及其带来的“一体化”优势，展现其如何在统一系统中高效支持实时交易与复杂分析双重要求。

一体化架构：LSM-Tree 原生的列存设计

OceanBase 作为原生分布式数据库，用户数据默认会多副本存储，为了利用多副本的优势，为用户提供数据强校验以及迁移数据重用等进一步的增强体验，自研的 LSM-Tree 存储引擎也做了较多的针对性设计，首先每个用户数据整体可以分成两个大部分基线数据和增量数据。

• 基线数据。不同于其它主流 LSM-Tree 数据库，OceanBase 利用分布式多副本的基础，提出“每日合并”的概念，租户会定期或者根据用户操作选择一个全局版本号，租户数据的所有副本均以这个版本完成一轮 Major Compaction，最后生成这个版本的基线数据，所有副本同一个版本的基线数据物理完全一致。

• 增量数据。相对基线数据而言，用户数据在最新版本的基线数据之后所有写入数据均属于增量数据。具体来说，增量数据可以是用户刚写入 Memtable 的内存数据，也可以是已经转储为 SSTable 的磁盘数据。 对于用户数据的所有副本来说，增量数据各个副本独立维护，不保证一致，并且不同于基线数据基于指定版本生成，增量数据包含所有多版本数据。

基于列存应用场景随机更新量可控的背景，OceanBase 结合自身基线数据和增量数据的特质，提出了一套对上层透明的列存实现方式：

• 基线数据存储为列存模式，增量数据保持行存，用户所有 DML 操作不受影响，上下游同步无缝接入，列存表数据仍然可以像行存表一样进行所有事务操作。

• 列存模式下每列数据存储为一个独立 SSTable，所有列的 SSTable 组合成为一个虚拟 SSTable 作为用户的列存基线数据，如下图所示。

• 根据用户建表指定设置，基线数据可以有行存、列存、行存列存冗余三种模式。

  
  

OceanBase 列存存储引擎设计

一体化优化：从存储到执行的全链路协同

我们不仅在存储引擎中实现了列存模式，为了让用户能够更容易从其它 OLAP 数据库迁移过来，以及帮助之前有 OLAP 需求的 OceanBase 老客户升级到列存，从优化器到执行器以及存储其它相关模块，都针对列存进行了适配以及优化，让用户迁移到列存后基本对业务无感，能够像使用行存一样享受到列存带来的性能优势，也让 OceanBase 真正实现了 TP/AP 一体化，实现一套引擎一套代码支持不同类型业务的目标，打造完善的一体化引擎。

OceanBase 列存模式的全面适配

• 存储一体化：零冗余、零迁移

• 同一套副本同时服务 TP 与 AP，无需额外列存副本, 支持行列冗余模式：对延迟敏感场景保留行存，对分析场景透明走列存，一份数据双重收益；

• 用户数据根据表模式指定，可以根据业务负载类型灵活切换行存/列存格式，用户查询/备份恢复等操作完全透明；

• 列存表完整支持所有在线及离线 DDL 操作，完整支持所有数据类型及二级索引创建，保证用户使用方法和行存别无二致。

• SQL一体化：代价驱动的智能路由

• 为列存设计实现了新的代价模型，并增加列存相关统计信息，优化器根据数据表存储模式根据代价自动选择计划。
• 实现新的向量化引擎，完成关键算子的新引擎重构，不同类型计划根据代价自适应选择向量化以及批大小。

• 事务一体化：ACID 语义 100% 继承

• 增量数据全程行存，事务日志、锁管理、MVCC 与现有引擎复用同一套代码；

• 列存表支持所有隔离级别、支持分布式事务；
• 闪回查询、主备切换等行为与行存完全一致。

一体化优势全景：N 套模式，一套代码

基于 LSM-Tree 架构，OceanBase 可以将数据做列存存储，以提供最极限的成本节省。但这并不意味着列存存储是 OceanBase 的唯一选择，它还可以作为缓存、索引和副本，为用户提供更高的灵活性和无限的可能性。

• 首先，OceanBase 可以将列存视作缓存，在缓存中存储部分区域的列存数据，以加速热点范围的查询。

• 其次，OceanBase 可以将列存看做索引，在基线 SSTable 中同时存储行存与列存数据，或者做部分列的聚合冗余存储。根据查询需要，查询列存或者行存，或者更合适的列组。

• 再次，OceanBase 可以将列存视为副本，在主副本中使用行存，在只读副本中使用列存，以提供更高等级的资源隔离。

• 最后，可能在不远的未来，除了提供以上的灵活度以外，OceanBase 或许还可以让用户摆脱行存和列存这些底层存储方式的限制，忘掉 OLTP 和 OLAP 等形态，让数据库回归到最初的本质。用户把数据和查询给到数据库，数据库把结果给用户，无论列存还是行存，数据库总是按照最适合负载的形式组织数据，以最快的速度返回结果。当用户觉得查询有些慢又不想做调优时，只需加资源即可。

OceanBase 实现了存储一体化新的形态：同一套代码、同一个 OBServer 进程，同时支持多种存储模式。这不是简单的功能开关，而是深度集成的架构创新。

基于一体化架构的数据融合方案

传统架构下，OLTP 系统（如 MySQL）负责业务交易，OLAP 系统（如 Hive、ClickHouse）用于数据分析，中间依赖 ETL 工具定时同步。这种方式存在明显短板：

• 数据延迟高（T+1 常见）

• 架构复杂，运维成本大

• 数据口径不一致风险

OceanBase 列存引擎打破壁垒，在同一数据库实例中同时承载事务与分析负载。用户无需搭建独立数仓，即可直接对最新业务数据发起即席查询。

• 一体化运维： 无需部署、维护、同步两套独立的数据库系统（如 OLTP DB + 数仓）。大幅降低架构复杂度、运维成本（安装、监控、备份恢复、升级）和硬件投入。

• 统一数据模型与 SQL：应用使用同一套数据模型（表结构）和标准的 SQL（兼容 MySQL/Oracle 模式）访问数据，无需为 OLTP 和 OLAP 编写不同的代码或进行复杂的数据映射。开发效率显著提升。

• 透明访问： 优化器自动选择行存或列存路径，应用无需感知底层存储格式，也无需手动路由查询。

基于分布式架构的资源复用机制

一体化架构带来显著的资源集约效应：

另外得益于 OceanBase 的分布式架构，列存引擎天然具备水平扩展能力。当分析负载上升时，可通过增加 Observer 节点动态扩容计算资源；当热点表增长过快时，系统自动触发分区再平衡与列存重建，全过程在线无感。

更重要的是，行存与列存共享同一资源池调度机制，可根据负载变化动态分配 CPU、内存配额。例如，在白天交易高峰期优先保障行存性能，在夜间开放更多资源给列存做批量分析任务。

实测表明，在典型 HTAP 场景下，OceanBase 相较分离式架构可节省 40% 以上的硬件投入与 60% 的运维工作量。

兼容性与易用性提升

OceanBase 列存引擎完全兼容 MySQL/Oracle 模式语法，开发者无需学习新语言即可享受列式加速红利。建表时只需参数声明即可启用列存：

CREATE TABLE `tt_column_store` (  `c1` int(11) NOT NULL,  `c2` int(11) DEFAULT NULL,  `c3` int(11) DEFAULT NULL,  PRIMARY KEY (`c1`)) WITH COLUMN GROUP(each column);

后续所有 SELECT 查询将由优化器自动判断是否使用列存路径。对于已有行存表，也可通过 ALTER TABLE 命令在线开启列存功能，数据会通过 DDL 重写为列存数据：

CREATE TABLE `tt_column_store` (  `c1` int(11) NOT NULL,  `c2` int(11) DEFAULT NULL,  `c3` int(11) DEFAULT NULL,  PRIMARY KEY (`c1`));alter table tt_column_store add column group(each column);

进一步, 如果用户希望整个数据转换列存的动作异步化, 尽量让整个过程不影响线上业务, OceanBase 还提供了 Online 的行列转换模式, 数据会通过后台 Compaction 异步转换为列存：

CREATE TABLE `tt_column_store` (  `c1` int(11) NOT NULL,  `c2` int(11) DEFAULT NULL,  `c3` int(11) DEFAULT NULL,  PRIMARY KEY (`c1`));alter table tt_column_store add column group(each column) delayed;

设计挑战：基于 LSM-Tree 架构构建列存

自适应 Compaction

引入新的列存存储模式之后，数据合并行为和原有行存数据有较大变化，由于增量数据全部是行存，需要和基线数据合并后拆分到每个列的独立 SSTable 中，合并时间和资源占用相对行存会有较大增长。

为了加速列存表合并速度，Compaction 流程进行大幅增强，对于列存表，除了能够像行存表一样进行水平拆分并行合并加速之外，还增加了垂直拆分加速，列存表会将多个列的合并动作放在一个合并任务内进行，并且一个任务内的列数能够根据系统资源自主选择升降，保证整体在合并速度以及内存开销达到更好的平衡。

OceanBase 自适应 Compaction 实现

列式编码算法

OceanBase 一直以来存储数据会经过两级压缩，第一级是 OceanBase 自研的行列混合编码压缩，第二级是通用压缩，其中行列混合编码由于是数据库内置算法，因此可以支持不解压直接查询，同时可以利用编码信息进行查询过滤加速，尤其对 AP 类查询会有极大的加速。 

但是原有行列混合编码算法仍然偏向行组织，因此针对列存表实现了全新的列式编码算法，相比原有编码算法，新算法支持查询的全面向量化执行，支持兼容不同指令集的 SIMD 优化，同时针对数值类型大幅提高压缩比，实现对原有算法在性能和压缩比上的全面提升。

OceanBase 列存压缩算法

Skip Index

常见列存数据库一般均会对每列数据按照一定的粒度进行预聚合计算，聚合的结果随数据一起持久化，当用户查询请求访问列数据时，数据库能够通过预聚合数据过滤数据，大幅减少数据访问开销，减少不必要的 IO 消耗。 

在列存引擎中，我们同样增加了 Skip Index 的支持，针对每列数据会按照微块粒度进行最大值、最小值、和以及 Null 总量等多个维度的聚合计算，并逐层向上聚合累加获得宏块、SSTable 等更大粒度的聚合值，用户查询能够根据扫描范围不断下钻选取合适粒度聚合值进行过滤以及聚合输出。

OceanBase Skip Index 实现

查询下压

OceanBase 在 3.2 版本开始初步支持简单的查询下压，从 4.x 版本开始存储全面支持了向量化以及更多的下压支持，在列存引擎中，下压功能进一步得到增强和扩展，具体包括：

• 所有查询 Filter 下压，同时根据 Filter 类型，能够进一步利用 Skip Index 以及编码信息加速。

• 常用聚合函数的下压，非 Group By 场景目前 Count/Max/Min/Sum/Avg 等聚合函数已能下压到存储引擎。

• Group By 下压，在 NDV 较少的列上，支持 Group By 下压存储计算，利用微块内字典信息进行大幅加速。

  
  

OceanBase 查询下压实现

未来演进：不止于列存

真正的技术突破，不是让复杂变简单，而是让不可能成为可能。

OceanBase 列存引擎不是简单的功能叠加，而是架构层面的深度融合， 让 TP 和 AP 不再是二选一的选择题，而是可以兼得的标准答案。OceanBase 的列存引擎仍在快速演进，大量新功能仍然在路上：

• 列存副本增强：利用分布式架构，OceanBase 目前已经自然支持异构列存副本，未来还将在一致性和读写路由上继续探索，帮助业务实现读写分离的极致优化。

• 存算分离增强：随着近期 OceanBase 的存算分离架构推出和上线，列存数据已经支持下沉到对象存储，计算节点能够按需加载, 未来会进一步支持 Compaction 的卸载让业务更加平滑；

• 表模式拓展：OceanBase 的列存表基于行存表发展而来, 是一个典型的MOR 模式，在 4.3.5 版本增加了 MOW 表模式的支持，未来还会进一步探索更多的表模式， 针对不同的业务场景达到性能的最大化。

• 动态智能列组：目前 OceanBase 仍是纯列存架构，未来会实现自由的列组格式，根据查询模式自动调整表的列存储组织，进一步优化分析性能。

在线咨询

优质资料下载

往期推荐