OceanBase AP 核心特性

列存引擎

在大规模数据复杂分析或海量数据即时查询场景中，列式存储是 AP 数据库的关键能力之一。列式存储是一种数据文件组织方式，区别于行式存储，它将表中的数据按照列进行物理排列。数据进行列式存储时，分析场景可仅扫描用于查询计算的列数据，避免整行扫描，减少 IO 和内存等资源使用，提升计算速度。另外按列存储也天然具备更好的数据压缩条件，更易获得较高的压缩比，减少存储空间和网络传输带宽。

OceanBase 数据库从诞生起就一直坚持 LSM-Tree 架构，不断打磨功能支持了各类典型的 TP 类型业务，持续优化性能满足各种极限负载压力，积累了大量工程实践经验，打造出一套纯自主研发且有充分特色的业界领先 LSM-tree 存储引擎。常见的 OLAP 场景往往是批量写入，不会有大量随机更新，尽量保证列存组织数据是静态的，这种场景天然适合 LSM-Tree 架构。

在 V4.3 版本，基于原有技术积累，OceanBase 存储引擎继续扩展，实现对列存的支持，实现存储一体化，一套代码一个架构一个 OBServer，列存数据和行存数据完美共存，这样真正实现了对 TP 类和 AP 类查询的性能的兼顾。

整体架构

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

• 基线数据。

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

• 增量数据。

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

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

• 基线数据存储为列存模式，增量数据保持行存，用户所有 DML 操作不受影响，上下游同步无缝接入，列存表数据仍然可以像行存表一样进行所有事务操作。
• 列存模式下每列数据存储为一个独立 SSTable，所有列的 SSTable 组合成为一个虚拟 SSTable 作为用户的列存基线数据，如下图所示。
• 根据用户建表指定设置，基线数据可以有行存，列存，行存列存冗余三种模式。

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

• SQL一体化
  • 为列存设计实现了新的代价模型，并增加列存相关统计信息，优化器根据数据表存储模式根据代价自动选择计划。
  • 实现新的向量化引擎，完成关键算子的新引擎重构，不同类型计划根据代价自适应选择向量化以及批大小。
• 存储一体化
  • 用户数据根据表模式指定，可以根据业务负载类型灵活设置为列存行存或者行列冗余模式，用户查询/备份恢复等操作完全透明。
  • 列存表完整支持所有在线及离线 DDL 操作，完整支持所有数据类型及二级索引创建，保证用户使用方法和行存别无二致。
• 事务一体化
  • 增量数据全部为行存，事务内修改、日志内容以及多版本控制等和行存完全共享逻辑。

核心特性

• 特性 1：自适应 Compaction

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

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

• 特性 2：列式编码算法

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

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

• 特性 3：Skip Index

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

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

• 特性 4：查询下压

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

  • 所有查询 filter 下压，同时根据 filter 类型，能够进一步利用 skip index 以及编码信息加速。
  • 常用聚合函数的下压，非 group by 场景下，目前 count/max/min/sum/avg 等聚合函数已能下压到存储引擎。
  • group by 下压，在 NDV 较少的列上，支持 group by 下压存储计算，利用微块内字典信息进行大幅加速。

  有关列存的详细介绍和使用指导，参见列存。

全新向量引擎

向量化执行是一种高效的按批处理数据的技术，在分析型查询中，向量化执行可以大大提升执行性能。OceanBase 数据库在 V3.2 版本引入了向量化执行引擎，但默认关闭。从 OceanBase 数据库 V4.0 版本开始，默认开启了向量化执行引擎，并在 OceanBase 数据库 V4.3 版本中实现了向量化引擎 2.0，通过对数据格式，算子实现优化及存储向量化优化等大幅提升了向量化引擎执行性能。

数据格式优化

向量化数据格式优化是向量化引擎 2.0 核心改进点，向量化引擎 1.0 实现中，存储层数据投影后，某列表达式一批数据在内存中的组织格式，是由多个连续数据描述单元及实际数据组成，每个数据描述单元中，均包含 null 描述，数据长度 len 及数据指针 ptr，实际数据值并不在数据单元描述中，而是存在 ptr 指向的地址，对于定长数据，存在以下几个问题：

• 读写访问不够高效

  每次访问(读/写)都需要先获取数据描述单元，然后通过数据描述单元中 ptr 访问数据，不能直接访问数据。

• 内存使用更多

  比如存放 N 行 int32_t 数据，数据描述单元结构占 12 个字节，从而总共需要 N * (12+4) 字节，而实际数据只有 N * 4 个字节，空间会放大 4 倍，导致内存访问、数据物化和数据 shuffle 时开销均更高。

• SIMD计算不够友好

  一批数据对应的实际数据不一定连续存放，对 SIMD 的使用不够友好。

• 序列化/物化开销更多

  在进行数据序列化和数据物化时，需要进行指针的 swizzling，即将指针转换为相对偏移。

为优化向量化 1.0 数据格式带来的以上不足，向量化引擎 2.0 中，实现了新的按列的数据格式。将数据描述信息 null、len、ptr 信息，分别按列的方式，分开连续存放，避免数据信息冗余存储，针对不同数据类型和使用场景，实现了 3 种数据格式：定长数据格式、 变长离散格式、变长连续格式。

• 定长数据格式

  只需要 null bitmap 和连续的数据信息、length 信息，只需要存放一份 length 值，不需要一批数据中每个数据冗余存放相同值，也不再需要间接访问的指针信息。相比以前向量化 1.0 数据格式，数据信息没有冗余存放，更加节省空间；可以直接访问，并且访问数据局部性更好；数据能确保连续存放，对于 SIMD 使用也更友好；此外在进行物化及序列化时，不需要对数据进行指针的 swizzling 操作，效率更高。

• 变长离散格式

  是指一批数据中，每个数据在内存中存放可能是不连续的，每个数据使用数据地址指针和长度描述，长度信息和指针信息，分别按列的方式连续存放；使用这种格式，存储层如果是编码数据，投影时不需要深拷贝数据，只需要投影 len 和 ptr 信息，并且对于短路计算场景，一批数据可能仅计算其中几行，这时也可以使用该格式描述并且不需要重整数据。

• 变长连续格式

  是指数据是连续存放在内存中的，每个数据的长度信息和偏移地址，使用 offset 数组描述，该描述格式，相比离散格式，在数据组织时，需要确保数据连续，对数据访问和数据按批 copy 效率更高，不过对于短路计算场景及列存编码数据投影不是很友好，需要对数据进行数据重整及深拷贝，当前该格式主要用于按列物化场景。

算子及表达式性能优化

向量化引擎 2.0，对算子及表达式实现进行了全面优化，主要优化思路是基于新的格式，使用 batch 数据属性信息、算法数据结构优化及特化实现，从而减少 CPU 数据 Cache Miss，降低 CPU 分支预测错误及 CPU 指令开销，提升整体执行性能；向量化 2.0 将 Sort、Hash Join、Hash Group By、数据 Shuffle、聚合计算等算子和表达式按新格式进行了重新设计与实现，整体计算性能全面提升。

• 利用 batch 数据属性信息

  向量化引擎 2.0，维护了执行过程中过程中，batch 数据的特征信息，包括是否不存在 null，是否 batch 中行均不需要被过滤等信息，利用这些信息，可大大加速表达式计算，比如 NULL 如果不存在，则表达式计算过程中不需要考虑对 NULL 的特殊处理，如果数据行均没有被过滤，则不需要计算时每行去判断是否已经被过滤，并且数据是连续的，没有被过滤，对使用 SIMD 计算也更友好。

• 算法及数据结构优化

  在算法及数据结构优化方面，实现了更加紧凑的中间结果物化结构，支持按行/列物化数据，空间更省，访问也更更加高效；Sort 算子实现了 sort key 与非 sort key 分离物化，结合对 sort key 保序编码(将多列数据编码为 1 列，可直接使用 memcpy 进行比较)，Sort 在比较过程中访问数据 Cache Miss 更低，比较计算本身更快，整体排序效率更高；HashGroupBy 对 Hash 表结构均进行了优化，HashBucket 中数据存放更加紧凑，并对低基数 Group Key 使用 ARRAY 优化，分组及聚合结果内存连续存放等优化等。

• 特化实现优化

  特化实现优化，主要是利用模版针对不同场景进行更加高效的实现，比如 Hash Join 特化实现了将多列定长 join key 编码为一个定长列，并且将 join key 数据放入到 bucket 中，对数据预期也进行了优化，减少了多列数据访问时数据 Cache Miss；支持聚合计算特化实现，不同的聚合计算进行特化分开实现，从而减少每次计算聚合函数指令及分支判断，执行效率大幅提升。

存储向量化优化

存储层全面支持新的向量化格式，对于投影、谓词下压、聚合下压和 groupby下压更多地使用 SIMD。投影定长和变长数据时，按列类型、列长度，以及是否包含 null 等信息定制化模板，按批浅拷投影。计算下压谓词时，对于简单的谓词计算，直接在列编码上进行；复杂的谓词，投影成新向量化格式在表达式上按批计算。聚合下压充分利用了中间层的预聚合信息，如 count、sum、max、min 等。groupby 下压则利用充分利用编码数据信息，对于字典类型的编码，加速效果非常明显。

物化视图

物化视图是支撑 AP 业务的一个关键特性，它通过预计算和存储视图的查询结果，减少实时计算来提升查询性能，简化复杂查询逻辑，常用于快速报表生成和数据分析场景。因为物化视图需要存储查询结果集来优化查询性能，而物化视图与基础表之间存在数据依赖关系，每当基础表数据发生变动时，物化视图中的数据必须进行相应更新以保持同步，所以新版本也引入了物化视图刷新机制，包括全量刷新和增量刷新两种策略。全量刷新是一种较为直接的方式，每次执行刷新操作时，系统会重新执行物化视图对应的查询语句，完整地计算并覆盖原有的视图结果数据，这种方式适用于数据量相对较小的场景。相对来讲，增量刷新仅需处理自上次刷新以来发生变更的部分。为了实现精确的增量刷新，OceanBase 实现了类似 Oracle MLOG（Materialized View Log）的物化视图日志功能，通过日志详细跟踪记录基础表的增量更新数据，从而确保物化视图能够进行快速增量刷新。增量刷新方式尤其适用于数据量庞大且变更频繁的业务场景。

物化视图场景使用示例：

• 数据汇总：汇总每天、每周或每月的销售数据、统计用户行为数据等
• 统计信息报表数据生成：报表系统需要定期生成固定格式的数据报告
• 复杂查询优化：对于特别消耗资源查询，如：JOIN操作，可以将结果物化避免查询重复计算
• 分发数据
• 监控数据的预聚合

有关物化视图的详细介绍和使用指导，参见 物化视图概述（MySQL 模式） 和 物化视图概述（Oracle 模式）。

实时写入

OceanBase 是一个高性能、高可用的分布式关系数据库系统，采用了独特的存储架构设计来满足现代应用的需求。为应对大规模数据的写入和分析处理，OceanBase 引入了列式存储与 LSM-Tree (Log-Structured Merge-tree) 结构相结合的技术。这一设计不仅保证了数据库的实时写入能力，同时也优化了分析查询的性能。下面将对 OceanBase 的实时写入能力进行详细介绍。

核心存储机制

列式存储

OceanBase 数据库通过引入列式存储机制，优化了数据库的分析处理能力。在列式存储中，数据以列的形式独立存储，这使得在进行数据分析查询时，系统可以高效地读取相关列的数据，大幅降低了不必要的I/O操作，提高了查询效率。同时，列式存储还有利于数据的压缩和编码，进一步优化了数据存储空间的使用效率。

LSM-Tree

为了支持高效的实时写入，OceanBase 采用了 LSM-Tree 结构来存储增量数据。LSM-Tree 是一种特殊的树结构，专为优化写入操作而设计。其核心思想是先将写入操作记录在内存中的结构里，待到一定量后再异步批量写入磁盘，这样大大减少了磁盘I/O的次数，提高了写入性能。OceanBase 将这些增量数据定期通过转储、合并过程与基线数据合并，确保数据的一致性和完整性。

实时写入能力

OceanBase 数据库的这种结合列式存储和 LSM-Tree 架构的设计，使得它在处理实时数据写入时表现出卓越的性能。无论是小量的数据更新还是大量的数据导入，OceanBase 数据库都能快速响应，保证数据的实时写入。其主要体现在以下几个方面：

1. 高效的写入处理：通过 LSM-Tree，OceanBase 将写入操作集中处理，减少了磁盘操作，提升了写入效率。
2. 数据的即时可查性：数据一旦被写入 LSM-Tree 的内存结构，即可对外提供查询，保证了数据的实时性。
3. 优化的数据合并过程：通过智能的转储和合并策略，OceanBase 保证了底层存储的数据总是最新、最优的状态，支持高效查询。
4. 强大的并发处理能力：利用分布式架构，OceanBase 可以在多节点上并行处理写入操作，极大提升了实时数据处理的能力。

MySQL 生态兼容

在追求极致性能与扩展性的同时，OceanBase 数据库还致力于提供与 MySQL 生态系统的高度兼容性，从而让广大 MySQL 用户能够无缝迁移至 OceanBase 数据库，并充分利用现有的 OLAP 生态工具与技术栈，实现数据分析与业务洞察的快速迭代与创新。

语法兼容性：OceanBase 数据库全面支持 MySQL 的 SQL 标准语法，包括但不限于数据定义语言（DDL）、数据操作语言（DML）以及数据控制语言（DCL）。这意味着，如果您之前使用MySQL编写的数据查询、表结构定义、索引创建、权限管理等语句，几乎可以直接在 OceanBase 数据库上运行，无需进行大量语法调整，大大降低了迁移成本和学习曲线。

• 无缝迁移：现有 MySQL 应用可以快速迁移到 OceanBase 数据库，减少迁移过程中的代码修改工作量。
• 技能复用：MySQL 开发人员和 DBA 无需额外学习新的数据库语法，缩短适应周期。
• 生态融合：与 MySQL 生态兼容的语法基础，使得 OceanBase 数据库能更好地融入现有的 BI、ETL、数据可视化等工具链中。

视图兼容性：OceanBase 兼容了 MySQL 的 information_schema 视图，例如：

• 表信息查询：支持如 TABLES、COLUMNS 视图，用户可以查询数据库中所有表的结构、列信息，这对于数据字典管理和第三方工具的集成至关重要。
• 权限管理：支持 SCHEMATA、SCHEMA_PRIVILEGES 等视图，帮助管理员便捷地查看和管理数据库、表的权限设置。

许多数据库管理、监控和分析工具依赖 INFORMATION_SCHEMA 来获取数据库状态和架构信息。OceanBase 数据库的这一兼容特性，使得这些工具可以直接在 OceanBase 数据库上运行，无需定制适配。OceanBase 数据库支持各类 OLAP 生态工具，例如：

BI 工具

• Tableau：作为业界领先的商业智能工具，Tableau 广泛用于数据可视化分析。OceanBase 数据库的 MySQL 兼容性使得 Tableau 可以直接连接数据库，利用 SQL 查询快速构建仪表盘和报告。
• Quick BI：阿里云 Quick BI 是一款高效的企业级大数据分析和展现工具，助力用户快速搭建数据门户、制作交互式报表，灵活分析数据，驱动业务智能化决策。OceanBase 数据库的 MySQL 兼容性使得 Quick BI 可以直接连接数据库。

ETL 工具

• Apache Flink：Apache Flink 是开源流处理和批处理统一框架，擅长高吞吐、低延迟的数据流处理，支持事件时间处理和状态管理。与 OceanBase 数据库兼容，Flink 用户可无缝对接，实现实时数据分析与存储，加强 OLAP 能力。

OceanBase 数据库与 MySQL OLAP 生态的深度兼容，不仅为用户提供了平滑迁移的路径，还保障了在不牺牲原有技术投资的基础上，能够充分利用丰富的 OLAP 生态工具，加速数据分析与业务决策过程。

关于目前 OceanBase 的 OLAP 生态集成情况，参见 生态集成。