体验 HTAP 混合负载场景

OceanBase 数据库采用一体化架构，同一套引擎、同一份数据即可同时支撑在线交易（TP）和实时分析（AP）负载。通过行存列存一体化存储技术，OceanBase 在同一张表上既能高效处理高并发点查与短事务更新，又能执行大范围扫描与聚合分析，无需维护分离的 OLTP 与 OLAP 系统。

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

• 创建 HTAP 测试表：创建行列混存表，同一份数据同时保持行存与列存两种基线形态。
• 体验 TP 业务：在混存表上执行写入、更新和主键点查，体验行存路径的高效事务处理。
• 体验 AP 业务：在同一张表上执行复杂分析查询，体验列存路径的向量化扫描与聚合能力。
• 体验资源隔离：配置租户内资源组，观察 AP 大查询对 TP 负载的影响及启用资源隔离后的改善。

前提条件

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

创建 HTAP 测试表

关于行存、列存与行列混存

OceanBase 默认建表为行存表。通过 WITH COLUMN GROUP 选项，可以指定不同的存储格式：

行列混存表同时保留行存基线与列存基线，优化器会根据查询特征自动选择访问路径：点查倾向走行存路径，宽范围扫描倾向走列存路径。详细信息请参见 使用列存与行列混存。

操作步骤

1. 登录业务租户（oltp_tenant 租户的 root 用户密码默认为空，提示输入密码时直接回车即可登录）：

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

2. 创建行列混存表。以支付流水业务为例：

   obclient [test]> CREATE TABLE payment_ledger_htap (
       txn_id       BIGINT       NOT NULL COMMENT '流水号',
       order_id     BIGINT       NOT NULL COMMENT '订单号',
       user_id      BIGINT       NOT NULL COMMENT '用户ID',
       pay_time     DATETIME     NOT NULL COMMENT '支付时间',
       pay_channel  VARCHAR(32)  NOT NULL COMMENT '支付渠道',
       txn_status   TINYINT      NOT NULL COMMENT '0待支付 1成功 2失败',
       amount       DECIMAL(18,2) NOT NULL COMMENT '金额',
       merchant_id  BIGINT       NOT NULL COMMENT '商户ID',
       PRIMARY KEY (order_id, pay_time, txn_id)
   )
   PARTITION BY HASH(order_id) PARTITIONS 4
   WITH COLUMN GROUP(all columns, each column);
   

   说明

   WITH COLUMN GROUP(all columns, each column) 同时声明行存列组与列存列组，基线冗余两份。优化器可按代价在点查走行存路径、在宽范围扫描走列存路径。

3. 写入测试数据：

   obclient [test]> INSERT INTO payment_ledger_htap (txn_id, order_id, user_id, pay_time, pay_channel, txn_status, amount, merchant_id)
   VALUES
       (1, 1001, 100, '2025-01-15 10:30:00', 'ALIPAY', 1, 128.50, 2001),
       (2, 1002, 101, '2025-01-15 11:00:00', 'WECHAT', 1, 256.00, 2002),
       (3, 1003, 100, '2025-01-15 14:20:00', 'ALIPAY', 2, 99.90,  2001),
       (4, 1004, 102, '2025-01-15 16:45:00', 'UNIONPAY', 1, 1024.00, 2003),
       (5, 1005, 101, '2025-01-16 09:00:00', 'WECHAT', 1, 56.80, 2002);
   

4. （可选）批量写入更多数据。上述示例数据仅 5 行，用于快速走通操作流程；数据量较小时，优化器不会为分析查询选择列存路径，后续步骤中的部分效果也不易观察。如希望完整体验 AP 查询的列存路径，可执行以下语句批量写入约 100 万行测试数据（实际耗时与机器性能相关）。

   单条 SQL 语句默认的执行超时时间为 10 秒，递归 CTE 默认的递归深度限制为 1000，批量写入数据耗时较长且数据量大，均需先调大。此处将执行超时时间调整为 60 秒（如仍报 ERROR 4012 超时，可继续调大）并将递归深度调整为 1100000：

   obclient [test]> SET SESSION ob_query_timeout = 60000000, cte_max_recursion_depth = 1100000;
   

   执行以下语句批量写入数据：

   obclient [test]> INSERT INTO payment_ledger_htap
                   WITH RECURSIVE seq(n) AS (SELECT 1 UNION ALL SELECT n+1 FROM seq WHERE n < 1000000)
                   SELECT n+1000000, 3000000+n, 100+(n%50),
                          DATE_ADD('2025-01-15 00:00:00', INTERVAL (n%20000) MINUTE),
                          ELT(1+(n%3),'ALIPAY','WECHAT','UNIONPAY'), 1+(n%2),
                          ROUND(RAND()*1000,2), 2000+(n%10)
                   FROM seq WHERE n <= 1000000;
   

5. 执行合并操作并收集统计信息，以改善列存查询性能：

   -- 在 sys 租户中触发合并
   obclient [oceanbase]> ALTER SYSTEM MAJOR FREEZE;
   

   -- 在业务租户中收集统计信息
   obclient [test]> CALL DBMS_STATS.GATHER_SCHEMA_STATS('test');
   

   说明

   合并（Major Compaction）是 OceanBase 将增量数据整理为基线数据的后台操作，新写入的数据需经过合并进入基线层后，才能被列存路径高效读取。合并状态可通过查询 oceanbase.CDB_OB_ZONE_MAJOR_COMPACTION 视图确认，当 STATUS 显示为 IDLE 时表示合并完成，实际耗时与数据量相关。DBMS_STATS 系统包收集统计信息的详细说明请参见 手动统计信息收集。

体验 TP 业务

行列混存表中，点查和高频短事务更新通过行存路径处理，具备与传统行存表相当的事务处理性能。

操作步骤

obclient 默认会在查询结果后显示执行耗时，例如 1 row in set (0.00 sec)，无需额外开启计时。下述各步骤的查询响应时间（RT）均可通过该显示直接观察。

1. 写入数据（模拟新增支付流水）：

   obclient [test]> INSERT INTO payment_ledger_htap (txn_id, order_id, user_id, pay_time, pay_channel, txn_status, amount, merchant_id)
   VALUES (6, 1006, 103, '2025-01-16 10:00:00', 'ALIPAY', 1, 388.00, 2001);
   

2. 更新数据（模拟支付状态变更）：

   obclient [test]> UPDATE payment_ledger_htap SET txn_status = 1 WHERE order_id = 1003;
   

3. 主键点查（模拟按订单号查询流水）：

   obclient [test]> SELECT txn_id, pay_time, amount, pay_channel
                   FROM payment_ledger_htap
                   WHERE order_id = 1001 AND txn_status = 1
                   ORDER BY pay_time DESC
                   LIMIT 1;
   

   对于主键点查，响应时间通常在毫秒级甚至亚毫秒级，体现了行存路径的点查效率。

   说明

   上述查询倾向走行存路径，通过主键快速定位数据。可使用 EXPLAIN 查看执行计划确认访问路径。

体验 AP 业务

同一张行列混存表上，复杂分析查询会倾向走列存路径，仅扫描涉及列，利用向量化执行引擎加速聚合与扫描。

操作步骤

1. 按渠道汇总支付金额（聚合分析查询）：

   obclient [test]> SELECT pay_channel, SUM(amount) AS total_amt, COUNT(*) AS cnt
                   FROM payment_ledger_htap
                   WHERE pay_time >= '2025-01-15 00:00:00'
                     AND pay_time <  '2025-01-17 00:00:00'
                     AND txn_status = 1
                   GROUP BY pay_channel;
   

2. 按商户统计支付总额：

   obclient [test]> SELECT merchant_id, DATE(pay_time) AS dt, SUM(amount) AS daily_amt
                   FROM payment_ledger_htap
                   WHERE pay_time >= DATE_SUB(CURDATE(), INTERVAL 7 DAY)
                     AND txn_status = 1
                   GROUP BY merchant_id, DATE(pay_time);
   

3. 使用 EXPLAIN 查看执行计划，确认是否走列存路径：

   obclient [test]> EXPLAIN SELECT pay_channel, SUM(amount) FROM payment_ledger_htap
                   WHERE pay_time >= '2025-01-01' GROUP BY pay_channel;
   

   说明

   如果执行计划中出现 COLUMN TABLE FULL SCAN 等列存相关算子，表示查询走了列存路径。数据量较小时（如仅写入示例的 5 行数据），优化器可能选择行存路径（显示 TABLE FULL SCAN），属于正常现象，批量写入数据并完成合并后即可观察到列存路径。实际执行计划以当前版本输出为准。

   TP 点查走行存路径，通常在毫秒级完成；AP 聚合查询由于需要扫描全表数据，响应时间会随数据量增加而上升。得益于列存仅扫描涉及列并配合向量化引擎加速，相同查询在行列混存表上仍能保持较高的执行效率。

体验资源隔离

在 HTAP 场景中，AP 大查询可能消耗大量 CPU 和 IO 资源，影响同时运行的 TP 业务。OceanBase 数据库支持通过资源组（Resource Group） 实现租户内的资源隔离，将 TP 和 AP 负载分配到不同的资源组，各自限制 CPU 和 IOPS 使用上限，确保 AP 查询不会干扰 TP 事务。

资源隔离原理

操作步骤

1. 创建测试用户

在业务租户中创建 TP 和 AP 专用用户：

obclient [test]> CREATE USER tp_user IDENTIFIED BY '******';
obclient [test]> CREATE USER ap_user IDENTIFIED BY '******';
obclient [test]> GRANT ALL PRIVILEGES ON test.* TO tp_user;
obclient [test]> GRANT SELECT ON test.* TO ap_user;

2. 创建资源组

调用 DBMS_RESOURCE_MANAGER 系统包，创建 TP 和 AP 两个资源组：

-- 创建 TP 资源组
obclient [test]> CALL DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
    CONSUMER_GROUP => 'tp_group',
    COMMENT => 'TP 业务资源组'
);

-- 创建 AP 资源组
obclient [test]> CALL DBMS_RESOURCE_MANAGER.CREATE_CONSUMER_GROUP(
    CONSUMER_GROUP => 'ap_group',
    COMMENT => 'AP 业务资源组'
);

3. 创建资源管理计划

obclient [test]> CALL DBMS_RESOURCE_MANAGER.CREATE_PLAN(
    PLAN => 'htap_plan',
    COMMENT => 'HTAP 资源隔离计划'
);

4. 创建资源管理计划内容

为 TP 资源组分配 80% CPU 上限，为 AP 资源组分配 30% CPU 上限：

-- TP 资源组：CPU 上限 80%
obclient [test]> CALL DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    PLAN => 'htap_plan',
    GROUP_OR_SUBPLAN => 'tp_group',
    COMMENT => 'TP 资源限制',
    UTILIZATION_LIMIT => 80,
    MIN_IOPS => 50,
    MAX_IOPS => 90
);

-- AP 资源组：CPU 上限 30%
obclient [test]> CALL DBMS_RESOURCE_MANAGER.CREATE_PLAN_DIRECTIVE(
    PLAN => 'htap_plan',
    GROUP_OR_SUBPLAN => 'ap_group',
    COMMENT => 'AP 资源限制',
    UTILIZATION_LIMIT => 30,
    MIN_IOPS => 20,
    MAX_IOPS => 60
);

5. 绑定用户到资源组

将 tp_user 绑定到 tp_group，ap_user 绑定到 ap_group：

obclient [test]> CALL DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
    ATTRIBUTE => 'user',
    VALUE => 'tp_user',
    CONSUMER_GROUP => 'tp_group'
);

obclient [test]> CALL DBMS_RESOURCE_MANAGER.SET_CONSUMER_GROUP_MAPPING(
    ATTRIBUTE => 'user',
    VALUE => 'ap_user',
    CONSUMER_GROUP => 'ap_group'
);

6. 启用资源管理计划

obclient [test]> SET GLOBAL resource_manager_plan = 'htap_plan';

执行以下语句确认启用成功（SET GLOBAL 语句仅修改全局值，当前会话需通过 SHOW GLOBAL VARIABLES 查看）：

obclient [test]> SHOW GLOBAL VARIABLES LIKE 'resource_manager_plan';

返回结果中 Value 为 htap_plan 即表示启用成功。启用后，tp_user 执行的 SQL 将使用 tp_group 的资源配额，ap_user 执行的 SQL 将使用 ap_group 的资源配额。

7. 验证资源隔离效果

通过对比"未启用资源隔离"和"启用资源隔离"两种状态下 TP 点查的响应时间，直观感受资源隔离的作用。建议在两个终端窗口中分别操作。

准备两个连接：

• 终端 A：使用 tp_user 连接：

  obclient -h127.0.0.1 -utp_user@oltp_tenant -P2881 -p -A test
  

• 终端 B：使用 ap_user 连接：

  obclient -h127.0.0.1 -uap_user@oltp_tenant -P2881 -p -A test
  

终端中执行的每条查询语句都会在结果后显示执行耗时（如 N rows in set (X.XX sec)），后续通过对比终端 A 中 TP 点查的耗时变化观察资源隔离效果。

第一步：未启用资源隔离时

1. 先临时禁用资源隔离计划，确保 TP 和 AP 共享资源：

   obclient [test]> SET GLOBAL resource_manager_plan = '';
   

2. 在终端 A 中执行一次 TP 点查，记录响应时间作为基准值：

   obclient [test]> SELECT txn_id, pay_time, amount FROM payment_ledger_htap WHERE order_id = 1001;
   

   此时没有 AP 负载干扰，点查响应时间通常在毫秒级。

3. 在终端 B 中发起 AP 聚合查询（数据量越大，查询耗时越长，效果越明显）：

   obclient [test]> SELECT pay_channel, SUM(amount), COUNT(*) FROM payment_ledger_htap GROUP BY pay_channel;
   

4. 在 AP 查询执行期间，回到终端 A 重复执行 TP 点查，观察响应时间。由于 AP 查询与 TP 事务共享 CPU 和 IO 资源，AP 查询占用大量资源时，TP 点查的响应时间可能出现明显升高。

第二步：启用资源隔离后

1. 重新启用资源隔离计划：

   obclient [test]> SET GLOBAL resource_manager_plan = 'htap_plan';
   

   执行 SHOW GLOBAL VARIABLES LIKE 'resource_manager_plan'; 确认返回值为 htap_plan。

2. 在终端 B 中再次发起 AP 聚合查询：

   obclient [test]> SELECT pay_channel, SUM(amount), COUNT(*) FROM payment_ledger_htap GROUP BY pay_channel;
   

3. 在 AP 查询执行期间，回到终端 A 重复执行 TP 点查，观察响应时间。启用资源隔离后，AP 查询被限制在 ap_group 的 CPU 上限（30%）内，TP 事务享有 tp_group 的资源保障，TP 点查的响应时间应保持稳定，不会因 AP 查询而出现明显波动。

结果对比：

无论延迟差异是否明显，均可使用 oltp_tenant 的 root 用户登录 oceanbase 库后（普通用户无权查询相关视图）执行以下语句确认资源隔离已生效：

obclient [oceanbase]> SELECT * FROM oceanbase.V$RSRC_PLAN;

返回结果中 NAME 为 htap_plan 且 CPU_MANAGED 为 ON，表示资源管理计划已启用。也可执行以下语句查看各资源组的资源限制详情：

obclient [oceanbase]> SELECT PLAN, GROUP_OR_SUBPLAN, UTILIZATION_LIMIT, MIN_IOPS, MAX_IOPS FROM oceanbase.DBA_OB_RSRC_DIRECTIVES;

返回结果中可以看到 tp_group 与 ap_group 的 CPU 与 IOPS 上限配置。

下一步

完成本文的 HTAP 体验后，您可以继续以下探索之旅：

1. 体验 AI 场景：创建向量表和全文索引，体验 OceanBase 数据库的混合检索能力。详见 体验 AI 场景。
2. 体验多租户特性：创建多个业务租户，体验集群级资源隔离和弹性扩缩容。详见 体验多租户与资源隔离。
3. 深入了解 AP 能力：探索列存索引、物化视图、并行查询等 OceanBase AP 核心特性。详见 OceanBase AP 概述。

相关文档

• 列存与行列混存的完整说明请参见 使用列存与行列混存。
• OceanBase AP 核心特性和应用场景请参见 OceanBase AP 概述。
• 资源隔离的完整配置方法和注意事项请参见 配置租户内资源隔离。
• 资源隔离的基础概念和适用场景请参见 资源隔离概述。
• 表创建和存储格式相关的配置项请参见 default_table_store_format。