大对象存储性能最佳实践

本文档介绍了如何在 OceanBase 中进行大对象存储性能优化，以提高数据库的性能。

背景

大对象概述

大对象（LOB，Large Object）是指数据库中存储的超大文本或二进制数据，如文本文档、图片、音频等。在数据库应用中，大对象常用于存储非结构化数据，为应用提供完整的数据存储解决方案。

大对象存储机制

OceanBase 数据库支持两种大对象存储方式：

• 行内存储：数据直接存储在数据行中
  • 优势：读取性能好，无需额外 I/O。
  • 劣势：占用主表空间，影响其他列的访问效率。
• 行外存储：数据存储在独立的对象存储中
  • 优势：节省主表空间，适合存储超大对象。
  • 劣势：需要额外 I/O，读取性能相对较差。

性能挑战

在实际应用中，行外存储的大对象和 JSON 面临以下主要问题：

• 读取性能：对于行外存储的大对象，每次访问都需要额外的 I/O 操作。
• JSON 类型特殊性：
  • 需要解析结构信息，开销更大。
  • 频繁读写场景下性能表现不优。

性能诊断和优化方案

识别行外存储性能问题

• 性能不优特征：

  • 查询延迟明显增加
  • I/O 等待时间占比高

• 诊断方法：

  • 使用 EXPLAIN 分析执行计划
  • 监控 I/O 相关性能指标

优化方案

采取智能存储策略

在处理大字段数据时，性能下降的主要原因是数据存储在行外，导致访问时的额外开销。可通过配置行内存储阈值，平衡存储空间和访问性能。具体可用方法如下：

通过 ob_default_lob_inrow_threshold 系统变量调大行内存储阈值，以避免行外存储。并重新建表进行测试。

示例如下：

-- 设置行内存储阈值为8192字节	
SET ob_default_lob_inrow_threshold = 8192;

选择更合适的数据类型建表

在实践中，我们发现一些业务场景在使用 LONGTEXT 和 JSON 类型存储数据时，会出现存储效率低下和访问速度慢的问题，尤其是在不需要复杂查询的情况下。实际上，对于不需要进行 JSON 计算的纯 JSON 数据存储，可以考虑使用 VARCHAR 或 TEXT 类型。在数据量较大时，使用更小的存储类型可以减少内存占用和提高访问速度。

升级到合适的 OceanBase 版本

旧版本的 OceanBase 可能会出现无法充分利用新特性的情况，这种情况也可能导致性能瓶颈。在高并发读写场景下，可以通过升级 OceanBase 版本进行性能调优。具体建议升级到 V4.2.x 的 V4.2.2、V4.3.x 的 V4.3.1 以及之后的版本，这些版本优化了行外储存场景，可以提高大对象和 JSON 的读写性能并降低延迟。

示例

测试环境

假设测试环境如下：

• CPU 架构：x86_64
• CPU：4 核
• OBServer版本号：4.2.1.7（V4.2.1 BP7）

问题描述

假设这是一个带有 JSON 字段的主键查询场景，存在慢查询。具体 SQL 和表 DDL 如下：

SELECT
  *
FROM
  `t2_act`
WHERE
  `id` = 1
  AND `del_at` IS NULL
LIMIT
  1;

CREATE TABLE `t2_act` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `title` varchar(128) COLLATE utf8mb4_unicode_ci NOT NULL,
  `page_setting` JSON DEFAULT NULL,
  `rule_setting` JSON DEFAULT NULL,
  `extend` JSON DEFAULT NULL,
  `del_at` timestamp NULL DEFAULT NULL,
  PRIMARY KEY (`id`)
);

通过如下语句可以查询 JSON 字段的数据长度信息：

SELECT /*+parallel(12)*/ max(lengh(page_setting)), min(length(rule_setting)), avg(length(extend)) FROM t2_act;
+--------------------------+--------------------------+--------------------+
| max(lengh(page_setting)) | min(lengh(rule_setting)) | avg(lengh(extend)) |
|                    17736 |                      928 |             113084 |
+--------------------------+--------------------------+--------------------+
1 row in set(0.196 sec)

可见，性能不佳的原因为该查询是涉及 JSON 列的查询，同时 JSON 列数据本身的长度超过了 LOB 行内存储的阈值，导致扫描 JSON 列数据需要额外的 I/O，进而导致 RT（响应时间）明显增加。

优化方案

1. 升级到 OceanBase V4.2.2 及以上版本，以优化开销。

2. 调大行内阈值避免行外存储，调阈值后重建表格，使得数据按照新的存储机制存储。

3. 由于此场景不需要对 JSON 数据进行计算，只是纯粹地存储 JSON 数据，判断可以直接使用 Varchar 或 Text 类型进行存储。