存储引擎原理简述

MARS3
HEAP
AORO

1 MARS3 概述

MARS3 是 YMatrix 自研的 LSM-Tree 架构存储引擎，采用行列混存架构，在传统 LSM 的基础上引入先行后列的双存储路径，既继承了行存对写入友好的特性，又保留了列存对分析查询的高性能，支持编码链压缩、数据更新删除、MVCC 机制、Brin 索引和行列混存等功能，能够同时满足 AP 和 TP 场景的需求。

MARS3 支持通过 UPDATE 与 DELETE 子句实现数据更新与删除（ Unique Mode 模式除外）。

MARS3 支持增删列，支持 COPY、pg_dump 操作。

1.1 内部原理

对于每个 MARS3 单表而言，其内部均采用 LSM Tree 结构存储。LSM Tree（Log Structured Merge Tree）是一种分层的，有序的，面向磁盘的数据结构。其核心思想是充分利用磁盘性能进行批量的顺序写操作，性能远高于随机写。

MARS3 内部原理图如下：

我们将以概念逐层剖析的形式来解读上图。

1.1.1 排序键

MARS3 中，数据是有序存储的。在创建表时，需要通过指定排序列（可以多列）的方式指定排序的顺序。这个排序顺序涉及的字段，称为排序键。
排序键只能指定一次，不能修改，不能新增，不能删除。
为了最大化利用顺序性带来的性能提升，最好选择经常使用且过滤效果好的字段作为排序键。比如设备监控表，可以采用事件时间戳和设备 ID 作为排序键。
如果排序键是文本类型，且能接受按照字节顺序排序，那么在这个列采用 COLLATE C 能够加速排序。
指定排序键的 SQL 关键词：ORDER BY。

1.1.2 行存和列存

MARS3 支持采用先行后列的存储方式存储数据，也支持直接写为列存，可通过 prefer_load_mode 参数设置加载模式，详见下文配置项。
如果采用行列混存的模式，则写入的数据会先以行存的形式储存下来，等数据量积累一定程度在进行列存转换。
和直接把数据变成列存相比，有以下几种好处：
- 对于高频、小批量数据来说写入速度更快
- 不需要大量的内存进行数据缓存
- 保证每个数据块元组数量的均匀

1.1.3 Run、增量文件和元信息

根据排序键，MARS3 中存储的数据是有序的，一段连续有序的数据称为 Run。
Run 分成两种，为了能够高速写入，插入的数据会以行存 Run 的形式储存下来，之后为了方便读取和压缩，我们会把行存 Run 转换成列存 Run。
每个 Run 都有自己的增量文件，除了记录主要数据的 Data 文件之外，还有储存大数据块的 Toast 文件，储存删除信息的 Delta 文件，储存索引信息的 Index 文件，储存合并（详见下节"合并与回收"）信息的 link 文件等（行存 Run 和列存 Run 的增量文件稍有不同）。
同时，为了知道这些文件的所在位置，我们额外记录一些信息，称为元信息。元信息会记录文件的存储位置，文件大小，数据条数，压缩状况等信息。
Run（使用 rowstore_size 参数配置）的大小可以灵活的进行调节，以适应不同场景达到最优性能。

1.1.4 合并和回收

Run 中如果数据范围有重叠，则会造成读放大，降低查询效率。因此，当磁盘上的 Run 数量超过一定值时，MARS3 会将磁盘上的多个 Run 进行归并排序，最后输出为一个 Run。这个过程称为合并。
合并过程中，数据依然可读可写：
- 读数据时，只会读合并的输入文件
- 写数据时，合并过程不会读新写入的数据
- 读，写，合并三者之间不会互相阻塞
合并完成后，参加合并的 Run 会根据事务 ID 自动决定何时不再被需要，并且标记为可回收状态。

1.1.5 Level

为了让合并的输入文件尺寸相近（避免超大文件与小文件合并），Run 被组织到 Level 中，最大可有 10 层：L0，L1，L2......L9。
每一层的 Run 个数达到一定数目，或者同一层多个 Run 的大小总和达到阈值都会触发合并，合成一个 Run 后升级到更高层去；并且为了加快 Run 的升级，允许同一层中同时进行多个合并任务。

1.1.6 MARS3 Brin 索引

MARS3 支持创建 Brin 索引，支持 Brin 索引的删除和新增。
每个 Run 在生成的时候都会创建自己独立的 Brin 索引文件。
示例：CREATE INDEX brin_idx ON t1 USING mars3_brin(time,tag_id);

1.1.7 压缩

默认情况下，MARS3 所有的数据列，采用 lz4 进行压缩。
支持手动指定编码链压缩算法，可以整个表指定，也可以单个列指定。

1.1.8 支持 MVCC 机制

MVCC（Multiversion Concurrency Control）机制通常被称为多版本管理。它的核心是对数据的更新、修改和删除处理。
多版本管理中，数据的更新和删除并不一定会在原数据上进行修改，而是需要创立一个新的版本，把原数据标记为失效的数据，再在新版本上增加新数据，数据具有多个版本。每个数据带有一个版本信息，且历史版本均会被保存。
MARS3 的更新和删除操作都不是采用原地修改数据的方式，而是依靠 Delta 文件和版本信息屏蔽掉了老数据，从而控制数据的可见性。
注意：持续进行更新或删除同一个 Run 的数据会让此 Run 的 Delta 文件占用的物理空间持续增加，但当当前 Run 的所有数据都被删除之后就不会再增加了。而且 MARS3 的合并操作可以自动清除已 Dead 的数据，当然你也可以有计划地定期使用 VACUUM 清理已 Dead 的数据。

1.1.9 数据写入

数据通过 INSERT 写入到内存中，再写入 L0 的 Run 中。
L0 中的 Run 大小是可以配置的，详见下文配置项部分。

1.1.10 更新和删除

MARS3 通过 DELETE 进行删除，删除会在对应 Run 的 Delta 文件中进行记录，在进行 Run 合并的时候真正把数据删除。
MARS3 通过 UPDATE 进行更新，更新会先删除原本数据，再重新插入一条新数据。
MARS3 的 Unique Mode 模式暂时不支持删除，更新则无需显式使用 UPDATE 子句，直接执行 INSERT 子句即可自动完成操作。如果想要更新某个 Unique Key（即建表时指定的排序键所对应的具体键值）对应的某条数据，直接插入一条相同 Unique Key 的新数据即可。例如 CREATE TABLE mars3_t(c1 int NOT NULL, c2 int) USING MARS3 WITH (uniquemode=true) ORDER BY (c1, c2);，其中 Unique Key 即为 (c1, c2)。

注意！
如开启 Unique Mode，则 ORDER BY 子句的第一个字段在定义时需要添加 NOT NULL 约束。

1.2 MARS3 使用

1.2.1 创建 MARS3 表

在已创建 matrixts 扩展的前提下，最简洁的建表方式，只需要在 CREATE TABLE 语句加上 USING 子句，并附加 ORDER BY 子句。延伸示例请见表设计最佳实践。

=# CREATE TABLE metrics (
    ts              timestamp,
    dev_id          bigint,
    power           float,
    speed           float,
    message         text
) USING MARS3 
  ORDER BY (dev_id,ts);

注意！
MARS3 表支持创建 Brin 索引，但非必须创建；
从 6.3.0 版本开始，MARS3 表建表时去除必须使用 ORDER BY 子句制定排序键的使用限制。

1.2.2 配置项

注意！
此部分配置项为表级配置项，只能在创建数据表时使用 WITH(mars3options='a=1,b=2,...') 子句配置（MARS2 同样支持的参数 compress_threshold 除外，直接使用 WITH 子句配置即可），适用于单表，且一旦配置便无法修改。更多信息请见数据表配置参数。

以下参数用于调节 L0 层 Run 的大小，也可间接控制 L1 层之上的 Run 大小。

参数	单位	默认值	取值范围	描述
rowstore_size	MB	64	8 ～ 1024	用于控制 L0 Run 何时切换。当数据大小超过该值，将会切换下一个 Run

以下参数用于设置压缩阈值，可用于调节压缩效果和改善读取效率，如果配置过低压缩效果不明显，配置过高消耗内存较多。

参数	单位	默认值	取值范围	描述
compress_threshold	元组	1200	1 ～ 100000	压缩阈值。用于控制单表每一列的多少元组（Tuple）进行一次压缩，是同一个单元中压缩的 Tuple 数上限

以下参数用于指定数据在 MARS3 中的加载模式。

参数	单位	默认值	取值范围	描述
prefer_load_mode		normal	normal / bluk	数据加载模式。`normal` 表示正常模式，新写入数据先写到 L0 层的行存 Run 中，积累到 `rowstore_size` 之后，落至 L1 层的列存 Run，相对于 `bulk` 模式会多一次 I/O，列存转换由同步变成了异步，但适用于 I/O 能力充足且对延迟敏感的高频次小批量写入场景；`bluk` 表示批量加载模式，适用于低频大批量写入场景，直接写至 L1 层的列存 Run，相对于 `normal` 模式，减少了一次 I/O，列存转换由异步变成了同步，适用于 I/O 能力不足且对延迟不敏感的低频大批量的数据写入

以下参数用于指定 Level 尺寸的放大系数。

参数	单位	默认值	取值范围	描述
level_size_amplifier		8	1 ～ 1000	Level 尺寸的放大系数。Level 触发合并操作的阈值，计算方式为：`rowstore_size * (level_size_amplifier ^ level)`。其值越大，读速越慢，写速越快。可以根据具体场景信息（写多读少/读多写少、压缩率等）来决定具体值。注意：确保每个 Level 的 run 数量不要过多，否则会影响查询性能，甚至阻止新数据插入

配置示例：

=# CREATE TABLE metrics (
    ts              timestamp,
    dev_id          bigint,
    power           float,
    speed           float
) USING MARS3
WITH (compress_threshold=1200,mars3options='rowstore_size=64',compresstype=zstd, compresslevel=1)
DISTRIBUTED BY (dev_id)
ORDER BY (dev_id,ts)
PARTITION BY RANGE (ts)
( START ('2023-07-01 00:00:00') INCLUSIVE
  END ('2023-08-01 00:00:00') EXCLUSIVE
  EVERY (INTERVAL '1 day')
,DEFAULT PARTITION OTHERS);

1.2.3 工具函数

matrixts_internal.mars3_level_stats：查看 MARS3 表每一个 Level 层级的状态，据此可以判断 MARS3 表的健康度，例如 Run 有没有按预期的进行合并，其个数是否符合预期等；
matrixts_internal.mars3_files：查看 MARS3 表文件状态，可以用来查看 MARS3 表的扩展文件和增量文件（Data 文件、Delta 文件、Index 文件等）是不是符合预期；
matrixts_internal.mars3_info_brin：查看 MARS3 表某个 Brin 索引的状态。

2 HEAP 概述

HEAP 是 YMatrix 的默认存储引擎，又称作堆存储，从 PostgreSQL 继承而来，只支持行存储，不支持列存储及压缩。它基于 MVCC 机制实现，适用于有大量更新、删除需求的场景。

2.1 使用 MVCC 机制

在 MVCC 机制影响下，HEAP 表在处理更新和删除操作时，并没有真正删除数据，而只是依靠数据版本信息屏蔽了老的数据（控制了数据的可见性）。因此，HEAP 表大量进行更新或删除操作，占用的物理空间会不断增大，需要你有计划地定期使用 VACUUM 清理老数据。

2.2 HEAP 使用

你可以运用以下 SQL 语句在 YMatrix 中创建一个 HEAP 表。

=# CREATE TABLE disk_heap(
    time timestamp with time zone,
    tag_id int,
    read float,
    write float
)
DISTRIBUTED BY (tag_id);

3 AORO 概述

AORO 是一种面向分析型数据库的存储组织范式，指数据以仅追加（append-only）方式按行连续写入，不支持原地更新或删除，通过时间戳或事务 ID 维护版本，兼顾写入吞吐、查询效率与 MVCC 一致性。 AORO 支持行存储。

对于有大量更新及删除操作的 AO 表，同样需要计划地定期清理老数据，不过在 AO 表中，清理数据工具 vacuum 需要对 bitmap 进行重置并压缩物理文件，因此通常比 HEAP 进度慢。

注意！
存储引擎详细信息、使用及最佳实践请见表设计与数据分布最佳实践。

← 上一篇

存储引擎概述

数据分布策略

简体中文 English Русский