体验并行导入与高压缩

数据写入效率和存储成本是数据库在大数据量场景下的两大核心诉求。OceanBase 数据库基于 LSM-Tree 存储架构，提供了旁路导入（Direct Load）的并行数据加载能力，可以绕过 SQL 层直接将数据写入底层存储；同时在合并（Compaction）阶段对数据进行编码与压缩，在不影响写入性能的前提下显著降低存储占用。本文将通过一批 100 万行的样例数据，帮助您直观体验 OceanBase 数据库的写入效率与存储成本优化能力。

本文将引导您完成以下体验：

• 准备批量样例数据：生成 100 万行 CSV 格式的测试数据。
• 体验并行导入：使用旁路导入结合并行度完成大批量入库，并与常规导入对比耗时。
• 校验导入结果：核对导入行数，确认数据完整入库。
• 体验数据编码与压缩：创建不同压缩配置的表，对比压缩前后的存储占用。
• 验证查询可用性：确认压缩存储的数据可正常查询且结果一致。

前提条件

在开始本文操作前，确保满足以下条件：

并行导入与高压缩简介

旁路导入

常规的数据导入需要经过 SQL 层的解析、优化和执行，将数据写入内存表（MemTable），再由后台任务转储为静态数据（SSTable）。旁路导入（Direct Load） 是一种导入执行模式，在 LOAD DATA、INSERT INTO SELECT 等语句中添加 DIRECT(...) Hint 即可启用。旁路导入绕过 SQL 层和 MemTable，将数据直接写入底层存储（SSTable），执行路径更短，适用于大表首次导入、10 GB~TB 级别的数据迁移，以及 CPU 和内存不充裕的场景。

在启用旁路导入的同时，通过 parallel(N) Hint 指定并行度，数据库会将导入任务拆分为多个并行子任务执行，进一步提升加载吞吐。

数据编码与压缩

OceanBase 数据库的 LSM-Tree 架构使数据的压缩只发生在合并（Compaction）阶段，不会影响数据的写入。数据落盘为 SSTable 时，以微块（Micro Block）为粒度进行两级压缩：

在 MySQL 模式下，通过建表时的 ROW_FORMAT 和 COMPRESSION 子句控制编码与压缩行为，主要取值如下：

即：新建表默认开启数据编码，并默认使用 zstd_1.3.8 压缩算法。本文将对比"不编码、不压缩"与"默认编码压缩"两种配置下的存储占用差异。

创建测试租户

1. 使用 root 用户登录集群的 sys 租户（密码为部署时随机生成的密码，获取方式见上文前提条件）：

   obclient -h127.0.0.1 -uroot@sys -P2881 -p -A oceanbase
   

2. 创建一个 2C4G 规格的资源单元、资源池和租户 load_tenant：

   obclient [oceanbase]> CREATE RESOURCE UNIT load_unit MAX_CPU=2, MIN_CPU=2, MEMORY_SIZE='4G';
   obclient [oceanbase]> CREATE RESOURCE POOL load_pool UNIT='load_unit', UNIT_NUM=1, ZONE_LIST=('zone1');
   obclient [oceanbase]> CREATE TENANT IF NOT EXISTS load_tenant CHARSET='utf8mb4', PRIMARY_ZONE='zone1', RESOURCE_POOL_LIST=('load_pool') SET ob_tcp_invited_nodes='%';
   

   租户创建需要数十秒（本文环境实测约 6 秒），期间命令行没有输出，属正常现象，等待命令返回即可。

3. 登录 load_tenant。新创建的租户 root 用户默认密码为空，提示输入密码时直接回车即可，后续操作均在此租户中进行：

   obclient -h127.0.0.1 -uroot@load_tenant -P2881 -p -A test
   

准备批量样例数据

1. 在部署 OceanBase 的机器上，执行以下命令生成 100 万行测试数据：

   seq 1 1000000 | awk '{printf "%d,user_%06d,city_%d,%d\n", $1, $1, $1%20, $1%1000}' > /tmp/load_sample.csv
   

   该命令生成包含以下字段的 CSV 文件：id（递增编号）、user_name（用户名）、city（20 个城市值循环取值）、amount（金额）。其中 city 取值仅 20 种、user_name 具有相同的 user_ 前缀，数据中存在大量重复和相似内容，便于观察压缩效果。

2. 检查数据文件：

   head -3 /tmp/load_sample.csv
   wc -l /tmp/load_sample.csv
   ls -lh /tmp/load_sample.csv
   

   head 命令返回的前 3 行数据如下：

   1,user_000001,city_1,1
   2,user_000002,city_2,2
   3,user_000003,city_3,3
   

   wc -l 返回 1000000 表示数据行数正确；ls -lh 显示文件大小约 29 MB。记录该文件大小，后续将与数据库中的实际存储占用进行对比。

体验并行导入

本节创建三张结构相同、配置不同的测试表，分别以不同方式导入同一份数据：

操作步骤

1. 登录 load_tenant，创建三张测试表：

   obclient [test]> CREATE TABLE load_normal (
                       id BIGINT PRIMARY KEY,
                       user_name VARCHAR(32),
                       city VARCHAR(32),
                       amount INT
                    );
   obclient [test]> CREATE TABLE load_direct (
                       id BIGINT PRIMARY KEY,
                       user_name VARCHAR(32),
                       city VARCHAR(32),
                       amount INT
                    );
   obclient [test]> CREATE TABLE load_none (
                       id BIGINT PRIMARY KEY,
                       user_name VARCHAR(32),
                       city VARCHAR(32),
                       amount INT
                    ) ROW_FORMAT=REDUNDANT COMPRESSION='none';
   

   load_none 通过 ROW_FORMAT=REDUNDANT COMPRESSION='none' 同时关闭数据编码与压缩；其余两张表使用默认配置（ROW_FORMAT=DYNAMIC、COMPRESSION='zstd_1.3.8'）。

2. 设置导入的文件路径。出于安全原因，secure_file_priv 系统变量只能通过本地 Unix Socket 连接执行修改：

   # Socket 路径取决于部署方式，obd demo 部署时可通过以下命令查找：
   find / -name sql.sock 2>/dev/null
   # 使用找到的 socket 路径连接（示例）：
   obclient -S /path/to/sql.sock -uroot@load_tenant -p
   

   提示输入密码时直接回车（新创建的租户 root 用户默认密码为空）。

   obclient [(none)]> SET GLOBAL secure_file_priv = "/tmp";
   Query OK, 0 rows affected
   

   secure_file_priv 用于限制 LOAD DATA INFILE 等语句的文件访问路径，该变量为全局变量，修改后新建立的连接生效。本文后续通过 obclient -e 执行的导入语句每次都会新建连接，无需额外操作。设置完成后，可新开一个连接执行 SHOW VARIABLES LIKE 'secure_file_priv'; 进行确认，返回值为 /tmp 即表示设置成功。

   说明

   secure_file_priv 的详细说明请参见 secure_file_priv。

3. 在操作系统终端中执行以下命令，使用常规导入方式将数据导入 load_normal，并记录耗时：

   time obclient -h127.0.0.1 -uroot@load_tenant -P2881 -A test -e "SET ob_query_timeout=3600000000; LOAD DATA INFILE '/tmp/load_sample.csv' INTO TABLE load_normal FIELDS TERMINATED BY ',';"
   

   命令执行完成后，time 命令会输出 real（实际耗时）、user（用户态耗时）、sys（内核态耗时）三行统计信息，记录 real 的值作为常规导入耗时。

4. 执行以下命令，使用旁路导入方式将数据导入 load_direct，并记录耗时：

   time obclient -h127.0.0.1 -uroot@load_tenant -P2881 -A test -e "SET ob_query_timeout=3600000000; LOAD DATA /*+ direct(true,1024,'full') parallel(4) */ INFILE '/tmp/load_sample.csv' INTO TABLE load_direct FIELDS TERMINATED BY ',';"
   

   命令中 Hint 的关键参数说明：

   Hint 参数	说明
   direct(true,1024,'full')	启用全量旁路导入：数据排序后写入、最大容忍错误行数为 1024、全量模式（适用于空表首次装载）
   parallel(4)	导入并行度为 4

5. 使用旁路导入将数据导入 load_none：

   time obclient -h127.0.0.1 -uroot@load_tenant -P2881 -A test -e "SET ob_query_timeout=3600000000; LOAD DATA /*+ direct(true,1024,'full') parallel(4) */ INFILE '/tmp/load_sample.csv' INTO TABLE load_none FIELDS TERMINATED BY ',';"
   

   注意

   • 新建租户的 root 用户默认密码为空，以上命令可直接执行；如已设置密码，请在命令中追加 -p密码（如 -p'******'），将密码写入命令行可避免交互式输入密码影响计时结果。
   • 命令中的 SET ob_query_timeout=3600000000 用于将本会话的语句超时时间临时调整为 1 小时，避免大批量导入耗时超过语句默认超时时间（10 秒）导致执行失败，详细信息请参见 ob_query_timeout。

6. 回到 obclient 会话，校验三张表的导入行数：

   obclient [test]> SELECT COUNT(*) FROM load_normal;
   obclient [test]> SELECT COUNT(*) FROM load_direct;
   obclient [test]> SELECT COUNT(*) FROM load_none;
   

   三条语句的返回结果均为 1000000，与源数据文件行数一致，表示数据完整入库：

   +----------+
   | COUNT(*) |
   +----------+
   |  1000000 |
   +----------+
   1 row in set
   

7. 对比第 3 步与第 4 步记录的 real 耗时。本文数据量为 100 万行（约 29 MB），两种导入方式的耗时通常相近（本文环境实测均在 3 秒左右完成），差异不明显属正常现象：数据量较小时，常规导入经过 SQL 层的开销占比很小；而旁路导入的优势体现在 GB 级及以上的大批量数据场景。如需进一步观察差异，可增大数据量后再次对比。

结果解读

体验数据编码与压缩

导入完成后，数据在合并（Compaction）生成 SSTable 的过程中才会应用表的编码与压缩配置。本节手动触发一轮合并，然后对比不同压缩配置下三张表的实际存储占用，并验证压缩后的数据可正常查询。

操作步骤

1. 使用 root 用户登录集群的 sys 租户，对 load_tenant 发起合并：

   obclient -h127.0.0.1 -uroot@sys -P2881 -p -A oceanbase
   

   obclient [oceanbase]> ALTER SYSTEM MAJOR FREEZE TENANT = load_tenant;
   Query OK, 0 rows affected
   

   说明

   发起合并前需确保全局合并开关已开启（集群级配置项 enable_major_freeze，默认开启）。合并的触发方式与详细说明请参见 手动触发合并。

2. 在 load_tenant 的会话中查询合并状态：

   obclient [test]> SELECT STATUS FROM oceanbase.DBA_OB_MAJOR_COMPACTION;
   

   合并进行中时返回 COMPACTING（正在合并）或 VERIFYING（正在校验 Checksum），合并完成后返回 IDLE：

   +------------+
   | STATUS     |
   +------------+
   | COMPACTING |
   +------------+
   1 row in set
   

   反复执行上述查询，直到 STATUS 变为 IDLE 再进行后续操作。合并通常需要数分钟（本文环境实测约 6 分钟），期间每隔 10~30 秒查询一次即可；如查询时合并已完成，则直接显示 IDLE。

3. 查询三张表的实际存储占用：

   obclient [test]> SELECT t.TABLE_NAME, r.DATA_SIZE, r.REQUIRED_SIZE
       -> FROM oceanbase.DBA_OB_TABLE_LOCATIONS t
       -> JOIN oceanbase.DBA_OB_TABLET_REPLICAS r ON t.TABLET_ID = r.TABLET_ID
       -> WHERE t.TABLE_NAME IN ('load_normal', 'load_direct', 'load_none')
       -> ORDER BY t.TABLE_NAME;
   

   返回结果示例如下（实际大小与数据内容、数据库版本及集群状态相关，请以实际查询结果为准，重点关注三个 DATA_SIZE 的相对关系）：

   +-------------+-----------+---------------+
   | TABLE_NAME  | DATA_SIZE | REQUIRED_SIZE |
   +-------------+-----------+---------------+
   | load_direct |   4057224 |       8114448 |
   | load_none   |  63569253 |     127138506 |
   | load_normal |   4184897 |       6040515 |
   +-------------+-----------+---------------+
   3 rows in set
   

   查询结果说明：

   • DATA_SIZE：数据的实际大小，即压缩编码后落盘的数据量。load_none 关闭了编码与压缩，其 DATA_SIZE 明显大于另外两张表；load_direct 与 load_normal 开启了默认的编码压缩，存储占用明显更小（本文实测约为 load_none 的 1/15）。
   • REQUIRED_SIZE：数据的分配空间大小，包含对齐等存储开销，因此 REQUIRED_SIZE >= DATA_SIZE。

4. 验证压缩存储的数据可正常查询。分别对 load_direct 和 load_none 执行相同的查询：

   obclient [test]> SELECT city, COUNT(*), SUM(amount) FROM load_direct WHERE city IN ('city_0', 'city_1') GROUP BY city;
   obclient [test]> SELECT city, COUNT(*), SUM(amount) FROM load_none WHERE city IN ('city_0', 'city_1') GROUP BY city;
   

   两张表的返回结果完全一致，且与源数据的分布规律相符（100 万行数据按 20 个城市值均匀分布，每个城市值 50000 行；GROUP BY 的输出顺序不保证，可能与下例不同）：

   +--------+----------+-------------+
   | city   | COUNT(*) | SUM(amount) |
   +--------+----------+-------------+
   | city_1 |    50000 |    24550000 |
   | city_0 |    50000 |    24500000 |
   +--------+----------+-------------+
   2 rows in set
   

5. 执行点查，验证行级数据可正常解码读取：

   obclient [test]> SELECT * FROM load_direct WHERE id = 500000;
   

   +--------+-------------+--------+--------+
   | id     | user_name   | city   | amount |
   +--------+-------------+--------+--------+
   | 500000 | user_500000 | city_0 |      0 |
   +--------+-------------+--------+--------+
   1 row in set
   

结果解读

下一步

完成本文的并行导入与高压缩体验后，您可以继续以下探索之旅：

1. 体验数据保护与恢复：通过闪回查询找回误操作前的数据，并了解备份恢复等完整的数据保护能力，参见 体验数据保护与恢复。
2. 体验在线 DDL：在有持续读写的测试表上执行新增列、创建索引等常见 DDL，观察业务连续性，参见 体验在线 DDL。
3. 深入数据加载与压测：体验 Sysbench 与 TPC-C 压测下的高并发性能，参见 体验高并发 OLTP 场景。

相关文档

• 旁路导入的原理与全量/增量模式说明请参见 旁路导入概述。
• LOAD DATA 语句的完整使用说明请参见 使用 LOAD DATA 语句导入数据。
• 压缩与编码的架构原理请参见 压缩与编码。
• 数据编码与压缩的配置方法请参见 使用数据编码和压缩。
• 手动触发合并与查看合并进度的操作请参见 手动触发合并 和 查看合并信息。
• 视图的详细字段说明请参见 DBA_OB_TABLET_REPLICAS 和 DBA_OB_TABLE_LOCATIONS。