在涉及大规模数据的复杂分析或即时查询时，列式存储是支撑业务负载的关键技术之一。相较于传统的行式存储，列式存储采用了不同的数据文件组织方式，它将表中的数据以列为单位进行物理排列。这种存储模式允许在分析过程中，查询计算仅需针对所需的列数据进行扫描，从而避免了不必要的整行扫描，显著降低了IO和内存等资源的消耗，进而提升了计算效率。此外，列式存储天然具备更佳的数据压缩优势，能够实现较高的压缩比，有效节约了存储空间，并降低了网络传输带宽的占用。
常见的列存存储引擎在实现上往往假设不会有大量随机更新, 尽量保证列存组织数据是静态的。当真正伴随大量数据随机更新时，也会不可避免的存在系统性能问题。OceanBase LSM-Tree 架构可以将基线数据和增量数据分别处理，正好可以解决这一场景问题。因此 OceanBase 4.3 版本基于当前架构基础进行扩展，正式推出列存引擎，在一个架构、一个数据库上，实现了列存和行存数据存储一体化，兼顾 TP 和 AP 查询性能。
为了让有分析诉求的用户顺畅使用新版本，围绕列存引擎，从优化器到执行器、从 DDL 到事务处理等多模块都进行了适配优化。包括基于列存的新的代价模型和向量化引擎，查询下压功能的扩展和增强，Skip Index，新的列式编码算法，自适应 Compaction 等。本文将深入探讨 OceanBase 4.3 版本带来的列存能力、应用场景，以及用户关心的未来发展规划。
一、列存整体架构
OceanBase 作为原生分布式数据库，默认情况下会为用户数据创建多个副本。为了充分利用多副本的优势，为用户提供数据强校验和数据迁移重用等增强体验，OceanBase 自研的 LSM-Tree 存储引擎做了深度优化：
○ 基线数据：相较于业内常见的 LSM-Tree 实现逻辑，OceanBase 提出了"每日合并"的概念。用户可定期或根据操作选择一个全局版本号，所有副本的租户数据将在这个版本上进行一轮 Major Compaction，生成这个版本的基线数据。所有副本在同一版本下的基线数据完全一致，物理上保持一致。
○ 增量数据：相对于基线数据，增量数据是指在最新版本的基线数据之后写入的数据。增量数据可以是刚写入Memtable的内存数据，也可以是已经转储为SSTable 的磁盘数据。增量数据在每个副本中独立维护，不保证一致性，并且包含了所有多版本的数据。
基于列存应用场景随机更新量可控的背景，OceanBase 4.3 结合自身基线数据和增量数据的特质，提出了一套对上层透明的列存实现方式：基线数据存储为列存模式，增量数据保持行存，确保用户所有 DML 操作不受影响，上下游同步无缝接入，列存表数据仍然可以像行存表一样进行所有事务操作。列存模式下每列数据存储为一个独立 SSTable，所有列的 SSTable 组合成为一个虚拟 SSTable 作为用户的列存基线数据。同时，用户可根据实际业务诉求在建表环节指定设置，基线数据可以支持行存、列存、行存列存冗余三种模式，提供更好的灵活性。
OceanBase 4.3 版本中不仅在存储引擎中实现了列存模式，更从优化器、执行器以等多维度进行列存的适配优化。用户在迁移到列存模式后基本上不会感受到业务变化，能够像使用行存一样享受到列存带来的性能优势。列存引擎的全面优化，也使得 OceanBase 真正实现了 TP & AP 一体化，实现了一套引擎、一套代码支持不同类型业务的目标，打造更加完善的 HTAP 混合负载实时分析能力。
二、OceanBase 实现列存，有哪些天然优势
（一）成熟的 LSM-Tree 引擎
与传统数据库相比，OceanBase 拥有天然的 Delta Store，非常适合实现列存。基于 LSM-Tree 存储引擎的支持，OceanBase 列存不仅支持完整的事务，而且基础算子的性能不弱于传统的 TP 数据库。在列存上，完整的事务支持使得 OceanBase 在更新方面具有天然优势，所有事物语义和多样事物的管理对用户来说完全透明的，用户可以轻松切换到列存模式，将列存数据库当成行存数据库使用，对业务完全透明，不需要做任何改动。
（二）完善的执行引擎
OceanBase 不仅拥有完整的执行引擎，还具备通用的优化器是通用的。在行存模式下，OceanBase 已经实现向量化存储引擎的无缝对接，无需任何修改即可支持向量化执行。此外，OceanBase 实现一套优化器的代码在上层对行存和列存进行不同代价的估算，使得用户的 SQL 可以自动选择行存或列存。
（三）灵活的原生分布式
OceanBase 天然支持分布式并行查询引擎，未来还可以轻松扩展到列存异构副本。列存异构副本的优势体现在用户需要完全硬隔离的应用场景中，未来的OceanBase 版本将新增这一功能。
综上所述，OceanBase 凭借其天然优势推动了 4.3 版本中列存功能的实现。引入列存储引擎后，OceanBase 整体架构在外部表现上完全不变，并且从架构层面支持了列存相关的三种模式：
○ 基线列存 +增量行存：基线数据采用列存方式存储，增量数据采用行存方式存储。
○ 灵活的行存/列存索引：可以对行存表建立列存索引，也可以对列存表建立行存索引，还可以对两者进行任意组合。由于所有列存表和索引的底层存储结构是统一的，因此 OceanBase 可以自动支持列存和行存的索引。
○ 列存副本：OceanBase 正在研发的列存副本功能。得益于原生分布式能力，只需对模式或表做部分修改，即可以通过 Compaction 将新增的只读副本转换为列存存储模式。
三、列存使用方法
（一）默认创建列存表
对于 OLAP 业务需求，我们推荐默认创建列存表。如何确保租户创建出来的表默认为列存表？只通过下面的配置项即可实现：
alter system set default_table_store_format = "column";随后我们创建的表格没有指定 column group 时，默认创建为列存表。
OceanBase(root@test)>create table t1 (c1 int primary key, c2 int ,c3 int);
Query OK,0 rows affected (0.301 sec)
OceanBase(root@test)>show create table t1;
CREATE TABLE `t1` (
`c1` int(11) NOT NULL,
`c2` int(11) DEFAULT NULL,
`c3` int(11) DEFAULT NULL,
PRIMARY KEY (`c1`)
) DEFAULT CHARSET = utf8mb4 ROW_FORMAT = DYNAMIC COMPRESSION = 'zstd_1.3.8' REPLICA_NUM = 1 BLOCK_SIZE = 16384 USE_BLOOM_FILTER = FALSE TABLET_SIZE = 134217728 PCTFREE = 0
WITH COLUMN GROUP(each column)
1 row in set (0.101 sec)（二）指定创建列存表
为了方便用户创建列存表，列存引入新的语法 with column group，当用户建表时最后指定 `with column group(each column)` ，即表示创建列存表。
OceanBase(root@test)>create table tt_column_store (c1 int primary key, c2 int ,c3 int) with column group (each column);
Query OK,0 rows affected (0.308 sec)
OceanBase(root@test)>show create table tt_column_store;
CREATE TABLE `tt_column_store` (
`c1` int(11) NOT NULL,
`c2` int(11) DEFAULT NULL,
`c3` int(11) DEFAULT NULL,
PRIMARY KEY (`c1`)
) DEFAULT CHARSET = utf8mb4 ROW_FORMAT = DYNAMIC COMPRESSION = 'zstd_1.3.8' REPLICA_NUM = 1 BLOCK_SIZE = 16384 USE_BLOOM_FILTER = FALSE TABLET_SIZE = 134217728 PCTFREE = 0 WITH COLUMN GROUP(each column)
1 row in set (0.108 sec)（三）指定创建列存行存冗余表
在某些场景下，用户可以容忍一定程度的数据冗余，以满足 AP/TP 业务场景的双重需求。此时，可以增加行存数据的冗余，通过 `with column group` 语法增加指定 `all columns` 即可实现。
create table tt_column_row (c1 int primary key, c2 int , c3 int) with column group (all columns, each column);
Query OK, 0 rows affected (0.252 sec)
OceanBase(root@test)>show create table tt_column_row;
CREATE TABLE `tt_column_row` (
`c1` int(11) NOT NULL,
`c2` int(11) DEFAULT NULL,
`c3` int(11) DEFAULT NULL,
PRIMARY KEY (`c1`)
) DEFAULT CHARSET = utf8mb4 ROW_FORMAT = DYNAMIC COMPRESSION = 'zstd_1.3.8' REPLICA_NUM = 1 BLOCK_SIZE = 16384 USE_BLOOM_FILTER = FALSE TABLET_SIZE = 134217728 PCTFREE = 0 WITH COLUMN GROUP(all columns, each column)
1 row in set (0.075 sec)（四）列存扫描
如何查看是否列存扫描计划？计划展示上新增 COLUMN TABLE FULL SCAN，描述列存表的范围扫描。
OceanBase(root@test)>explain select * from tt_column_store;
+--------------------------------------------------------------------------------------------------------+
| Query Plan |
+--------------------------------------------------------------------------------------------------------+
| ================================================================= |
| |ID|OPERATOR |NAME |EST.ROWS|EST.TIME(us)| |
| ----------------------------------------------------------------- |
| |0 |COLUMN TABLE FULL SCAN|tt_column_store|1 |7 | |
| ================================================================= |
| Outputs & filters: |
| ------------------------------------- |
| 0 - output([tt_column_store.c1], [tt_column_store.c2], [tt_column_store.c3]), filter(nil), rowset=16 |
| access([tt_column_store.c1], [tt_column_store.c2], [tt_column_store.c3]), partitions(p0) |
| is_index_back=false, is_glOceanBaseal_index=false, |
| range_key([tt_column_store.c1]), range(MIN ; MAX)always true |
+--------------------------------------------------------------------------------------------------------+计划展示上新增 COLUMN TABLE GET，描述列存表上的指定主键的 get 操作。
OceanBase(root@test)>explain select * from tt_column_store where c1 = 1;
+--------------------------------------------------------------------------------------------------------+
| Query Plan |
+--------------------------------------------------------------------------------------------------------+
| =========================================================== |
| |ID|OPERATOR |NAME |EST.ROWS|EST.TIME(us)| |
| ----------------------------------------------------------- |
| |0 |COLUMN TABLE GET|tt_column_store|1 |14 | |
| =========================================================== |
| Outputs & filters: |
| ------------------------------------- |
| 0 - output([tt_column_store.c1], [tt_column_store.c2], [tt_column_store.c3]), filter(nil), rowset=16 |
| access([tt_column_store.c1], [tt_column_store.c2], [tt_column_store.c3]), partitions(p0) |
| is_index_back=false, is_global_index=false, |
| range_key([tt_column_store.c1]), range[1 ; 1], |
| range_cond([tt_column_store.c1 = 1]) |
+--------------------------------------------------------------------------------------------------------+
12 rows in set (0.051 sec)如何通过 Hint 指定列存行存冗余表走列存扫描？对于列存行存冗余表，优化器会根据代价选择走行存或者列存扫描，如简单场景做全表扫描，会默认使用行存生成计划。
OceanBase(root@test)>explain select * from tt_column_row;
+--------------------------------------------------------------------------------------------------+
| Query Plan |
+--------------------------------------------------------------------------------------------------+
| ======================================================== |
| |ID|OPERATOR |NAME |EST.ROWS|EST.TIME(us)| |
| -------------------------------------------------------- |
| |0 |TABLE FULL SCAN|tt_column_row|1 |3 | |
| ======================================================== |
| Outputs & filters: |
| ------------------------------------- |
| 0 - output([tt_column_row.c1], [tt_column_row.c2], [tt_column_row.c3]), filter(nil), rowset=16 |
| access([tt_column_row.c1], [tt_column_row.c2], [tt_column_row.c3]), partitions(p0) |
| is_index_back=false, is_global_index=false, |
| range_key([tt_column_row.c1]), range(MIN ; MAX)always true |
+--------------------------------------------------------------------------------------------------+如果用户希望通过手动调优走列存扫描，可以通过 hint USE_COLUMN_TABLE 来强制 tt_column_row 表走列存扫描。
OceanBase(root@test)>explain select /*+ USE_COLUMN_TABLE(tt_column_row) */ * from tt_column_row;
+--------------------------------------------------------------------------------------------------+
| Query Plan |
+--------------------------------------------------------------------------------------------------+
| =============================================================== |
| |ID|OPERATOR |NAME |EST.ROWS|EST.TIME(us)| |
| --------------------------------------------------------------- |
| |0 |COLUMN TABLE FULL SCAN|tt_column_row|1 |7 | |
| =============================================================== |
| Outputs & filters: |
| ------------------------------------- |
| 0 - output([tt_column_row.c1], [tt_column_row.c2], [tt_column_row.c3]), filter(nil), rowset=16 |
| access([tt_column_row.c1], [tt_column_row.c2], [tt_column_row.c3]), partitions(p0) |
| is_index_back=false, is_global_index=false, |
| range_key([tt_column_row.c1]), range(MIN ; MAX)always true |
+--------------------------------------------------------------------------------------------------+
类似的方式，通过 Hint NO_USE_COLUMN_TABLE 可以强制表不进行列存扫描。
OceanBase(root@test)>explain select /*+ NO_USE_COLUMN_TABLE(tt_column_row) */ c2 from tt_column_row;
+------------------------------------------------------------------+
| Query Plan |
+------------------------------------------------------------------+
| ======================================================== |
| |ID|OPERATOR |NAME |EST.ROWS|EST.TIME(us)| |
| -------------------------------------------------------- |
| |0 |TABLE FULL SCAN|tt_column_row|1 |3 | |
| ======================================================== |
| Outputs & filters: |
| ------------------------------------- |
| 0 - output([tt_column_row.c2]), filter(nil), rowset=16 |
| access([tt_column_row.c2]), partitions(p0) |
| is_index_back=false, is_global_index=false, |
| range_key([tt_column_row.c1]), range(MIN ; MAX)always true |
+------------------------------------------------------------------+
11 rows in set (0.053 sec)四、未来展望
OceanBase 4.3 列存的引入，为用户的数据分析以及实时分析场景提供了新的选择。未来，OceanBase 列存将持续演进，为用户带来更加丰富的 feature、更强劲的性能以及更灵活的部署模式。
第一，更丰富的功能。目前，我们支持纯列存储引擎，未来将实现可自定义的灵活列组组织支持，满足不同场景的分析需求。此外，我们计划将增量旁路导入功能进一步增强，帮助用户实现高效的数据导入，缩短数据分析准备时间。
第二，更好的性能。增强 Skip Index 的支持，使其能够更好地满足用户的查询需求。此外，我们计划实现格式一体化，目前存储的格式多样化，未来将实现存储格式与 SQL 向量化引擎的紧密结合，使得在执行 SQL 计算时，系统能够识别不同的存储格式，从而帮助用户节省更多的数据转换开销。
第三，更灵活的部署模式。在未来的版本中，我们将支持 OLAP 所需的异构副本，以满足用户对强依赖异构副本的需求。此外，未来还将支持存算分离模式，使得所有用户的 AP 数据库都能够以更低的成本享受存储与计算的分离。
本站资源均来自互联网，仅供研究学习，禁止违法使用和商用，产生法律纠纷本站概不负责！如果侵犯了您的权益请与我们联系！
转载请注明出处： 免费源码网-免费的源码资源网站 » OceanBase 4.3 特性解析：列存技术
发表评论 取消回复