梧桐数据库存储格式介绍
梧桐数据库存储格式介绍1前言2存储格式概述3不同存储格式建表3.1ROW 格式表3.2ORC 格式表3.3Hudi 格式表3.4magma 格式表4存储对比说明5存储格式选择6总结
1前言
梧桐数据库，作为一款强大的开源关系型数据库管理系统，不仅提供了卓越的 SQL 查询能力，还在其发展历程中不断优化数据存储结构，以满足不同应用场景下的性能需求。从传统的 ROW 格式到最新的 MagmaAP 格式，梧桐数据库为用户提供了多种存储选择。本文档将详细介绍这些存储格式的特点、使用场景以及不同存储格式之间的区别。
2存储格式概述
1.ROW 格式
ROW 格式采用按行存储的机制。该格式适合常规的关系型数据库应用，特别是那些对实时读写性能有较高要求的场景。ROW 格式简单直观，易于理解和管理。
2.ORC 格式
ORC（Optimized Row Columnar）是梧桐数据库中的默认存储方式，ORC 格式是一种高效的列式存储格式，由 Hadoop 生态系统中的 Hive 项目引入。在梧桐数据库中，ORC 格式通过扩展模块支持，它特别适用于大数据分析和数据仓库场景。列式存储使得 ORC 在读取大量数据时能够跳过不必要的列，从而提高查询性能。
3.Hudi 格式
Hudi 是 Apache 的一个开源项目，旨在提供流处理与大数据存储之间的桥梁。在梧桐数据库中，Hudi 格式通过特定的扩展支持，使得数据库能够处理增量数据，并支持数据的更新和删除操作。Hudi 格式适用于需要实时数据摄取和处理的场景。
4.MagmaAP 格式
MagmaAP 是梧桐数据库 4.0.0.0 版本中引入的全新存储格式。它结合了行式存储和列式存储的优点，旨在提供高性能的读写能力，并支持事务和索引。MagmaAP 格式特别适用于需要高性能、高可靠性和实时数据处理的场景。
3不同存储格式建表
3.1ROW 格式表
梧桐数据库建表的指定存储格式为 ROW 格式，如下：
CREATE TABLE table_a (
id int,
rank int,
year smallint,
gender char(1),
count int )
with (appendonly =false)上面的创建的表一样，显式指定存储格式类型，如下：
CREATE TABLE table_b (
id int,
rank int,
year smallint,
gender char(1),
count int )
with ( orientation =row);创建一个 snappy 压缩格式的 ROW 表，如下：
CREATE TABLE table_c (
id int,
rank int,
year smallint,
gender char(1),
count int)
with (appendonly =true, orientation =row, compresstype = snappy);参数说明：
- appendonly：是否只允许数据追加，true/false。
- orientation：表示表的存储格式，可配置的格式有：ROW、ORC、Hudi，magma等。
- compresstype：表示配置压缩算法，可配置snappy、lz4，zlib等压缩算法。
创建一个 lz4 压缩格式的 ROW 表，如下：
CREATE TABLE table_d (
id int,
rank int,
year smallint,
gender char(1),
count int)
with (appendonly =true, orientation =row, compresstype = lz4);3.2ORC 格式表
创建一个不压缩的 ORC 表，如果不指定压缩类型的话，默认不压缩。
CREATE TABLE table_e (
id int,
rank int,
year smallint,
gender char(1),
count int)
with (appendonly =true, orientation =orc);创建一个带 snappy 压缩的 ORC 表，如下：
CREATE TABLE table_f (
id int,
rank int,
year smallint,
gender char(1),
count int)
with (appendonly =true, orientation =orc, compresstype = snappy);创建一个带 lz4 压缩的 ORC 表，如下：
CREATE TABLE rank_h (
id int,
rank int,
year smallint,
gender char(1),
count int)
with (appendonly =true, orientation =orc, compresstype = lz4);3.3Hudi 格式表
创建一个普通的 Hudi 表，相比 ROW/ORC 表，需要指定 type，默认不压缩。
CREATE TABLE rank_i (
id int,
rank int,
year smallint,
gender char(1),
count int)
with (appendonly =true, orientation =horc, type = mor);创建一个带压缩的 Hudi 表，指定压缩类型为 lz4，如下：
CREATE TABLE rankj (
id int,
rank int,
year smallint,
gender char(1),
count int)
with (appendonly =true, orientation =horc, type = mor,compresstype = lz4);3.4magma 格式表
创建一个压缩的 magma 表，magma 内部自动实现了压缩。
CREATE TABLE rank_k (
id int,
rank int,
year smallint,
gender char(1),
count int)
format 'magmaap';创建一个有 primary key 的 magma 表，magma 内部实现了压缩。
CREATE TABLE rank_l (
id int,
rank int,
year smallint,
gender char(1),
primary key(id) )
format 'magmaap';4存储对比说明
梧桐数据库多种存储格式的特性对比说明如下表：
特性 | ROW | ORC | Hudi | MAGMAAP |
行/列存储 | 行 | 行列混合存储 | 行列混合存储 | 行列混合存储 |
存储格式 | 自定义存储格式 | 兼容标准 ORC 格式 | 兼容 Apache Hudi 表格式 | 自定义存储格式 |
是否支持新执行器 | 不支持 | 支持 | 支持 | 支持 |
压缩 | 支持 SNAPPY, ZLIB | 支持 LZ4, SNAPPY, ZSTD, ZLIB | 支持 LZ4, SNAPPY, ZSTD, ZLIB | 自动选择压缩算法， 不需要用户指定 |
是否UPDATE/DELTE | 支持 | 支持 | 支持 | 支持 |
是否 INDEX | 不支持 | 不支持 | 不支持 | 支持 |
5存储格式选择
- ROW 存储格式：简单直观，易于理解和管理；适用于实时读写性能要求较高的场景。
- ORC 存储格式：高效的列式存储，适用于大数据分析和数据仓库场景；支持压缩和编码，降低存储成本。
- Hudi 存储格式：支持增量数据处理，适用于实时数据摄取和处理场景；支持数据的更新和删除操作。
- MagmaAP 存储格式：结合行式存储和列式存储的优点，提供高性能的读写能力；支持事务和索引，保证数据的一致性和可靠性。
6总结
梧桐数据库提供了多种存储格式，每种格式都有其独特的特点和适用场景。通过选择合适的存储格式，可以充分发挥数据库的性能优势，满足不同业务需求。在未来的发展中，梧桐数据库将继续优化和扩展存储格式的功能，比如 json、parquet，Avro 等格式，为用户提供更加高效、可靠的数据存储解决方案。