活动专区

活动公告

上车！GBase 8a开发者联盟发车了 技术福利、人脉资源全都有！

认证培训专区

认证培训资料

GBase 8s GDCA 认证培训课前准备

GBase 8a

其他

物化视图报错：references invalid table(s) or column(s) or function(s) or definer/invoker of view lack rights to use them

01-GBase 8s 事务型数据库 安装与卸载

GBase 8s

适配迁移

[GBase 8s 教程]GBase 8s 常用函数、表达式


&gt; UPDATE 和 DELETE 在 MySQL 中是轻量级操作：找到行、原地修改、写入日志，完成。但同样的操作在 GBase 8a 的列存 MPP 引擎里代价完全不同。理解这种差异，才能在设计数据模型和 ETL 流程时做出正确的选择——避免把 GBase 8a 当成 OLTP 数据库来写数据，导致更新性能比预期差几十到几百倍。

---

## 一、列存引擎为什么不擅长 UPDATE 和 DELETE

要理解这个问题，需要先理解列存引擎在物理层面是如何组织数据的，以及一次更新操作会触发哪些底层动作。

在行存数据库（如 MySQL InnoDB）中，数据按行存储，每一行是一个连续的物理单元。更新一行数据时，引擎定位到这行的物理地址，在原地修改对应字段的值，再把变更写入事务日志。整个过程只涉及极小范围的磁盘操作，加上 B-Tree 索引能快速定位目标行，单行 UPDATE 的延迟通常在毫秒级别。

GBase 8a 的 Express 列存引擎采用完全不同的存储结构：同一列的所有值被连续存储在一个列块（Column Block）里，列块被压缩后以整体的形式写入磁盘。列块是数据写入和读取的最小单位，不是单行，也不是单个字段值。当需要更新某一行的某个字段时，引擎没有办法"原地修改"——列块已经被压缩了，修改一个值就必须解压整个列块、修改值、重新压缩、重新写回磁盘。如果这一行的数据分布在多个列块里（行数很多时一定是这样），多个列块都需要经历这个解压-修改-重压-写回的流程。

更麻烦的是 MPP 分布式架构带来的额外代价。GBase 8a 在执行 UPDATE 或 DELETE 时，协调节点（gcluster）需要先把过滤条件广播给所有数据节点（gnode），每个 gnode 扫描本地数据确定哪些行需要被修改，然后在本地执行修改，再把结果汇报给 gcluster。这个过程没有行锁可以精确定位目标行，每次更新都是一次分布式全集群扫描。对于一张分布在 6 个 gnode 上的 5 亿行表，哪怕只更新 1 条记录，6 个 gnode 也会各自扫描自己负责的分区来找到那一行。

这就解释了为什么在 GBase 8a 里，更新 10 万行数据可能需要数分钟，而同样的操作在 MySQL 上只需要几秒钟。这不是 GBase 8a 的"缺陷"，而是列存 MPP 数据库为了追求高吞吐的批量分析性能，在单行随机写入方面做出的主动权衡。理解了这一点，就能理解为什么正确的使用姿势是在设计层面绕开频繁的 UPDATE/DELETE，而不是靠调优参数来提升单行更新性能。

---

## 二、UPDATE 和 DELETE 的实际代价测量

在做架构决策之前，先用实测数据建立直觉，感受 GBase 8a 的更新代价到底有多高。

```sql
-- 准备：1 亿行的测试表
CREATE TABLE bench_orders (
    order_id    BIGINT,
    customer_id INT,
    status      TINYINT,
    amount      DECIMAL(18,2),
    order_date  DATE
) DISTRIBUTED BY HASH(customer_id);

-- 实验 1：更新 1 行（按主键精确更新）
UPDATE bench_orders SET status = 2 WHERE order_id = 12345678;
-- 预期耗时：数秒（需要扫描所有 gnode 定位这一行）

-- 实验 2：更新 1 万行（批量状态变更）
UPDATE bench_orders SET status = 2
WHERE order_date = '2024-06-01' AND status = 1
LIMIT 10000;
-- 预期耗时：数十秒到数分钟

-- 实验 3：删除 1 个月的数据（按时间范围删除）
DELETE FROM bench_orders WHERE order_date BETWEEN '2024-01-01' AND '2024-01-31';
-- 预期耗时：分钟级（远不如 DROP PARTITION 快）

-- 实验 4：删除分区（等效操作）
ALTER TABLE bench_orders DROP PARTITION p2024_01;
-- 预期耗时：秒级（直接删除文件，不扫描数据）
```

对比实验 3 和实验 4 的结果，会直观地感受到"删除分区"比"按条件 DELETE"快几十倍甚至更多——这种差距背后的原因正是本文要讲的核心：在列存 MPP 里，任何绕过行级扫描的操作都比行级操作快得多。

---

## 三、正确的数据更新设计模式

既然 UPDATE/DELETE 代价高，正确的做法不是接受慢速更新，而是在设计层面选择对列存更友好的数据更新模式。以下几种模式覆盖了生产中绝大多数的数据更新需求。

### 3.1 分区级删除 + 批量重写（最推荐的全量更新模式）

对于需要修改某个时间范围内大量记录的场景（如每日 ETL 重算昨日数据），最高效的方式不是逐行 UPDATE，而是删除整个分区再重新写入。这个模式的代价只有两部分：一次 `ALTER TABLE DROP PARTITION`（几乎瞬间完成）加上一次批量 `INSERT`（利用 gload 或 INSERT...SELECT 的 MPP 并行写入）。

```sql
-- 场景：每日重算昨日的汇总数据，orders 表按月分区

-- 步骤 1：删除昨日所在月份分区的数据（如果分区粒度是月）
-- 或者：先把昨日数据导出到临时表，删分区数据，重写入
-- 分区粒度是天时最简洁：
ALTER TABLE orders_daily_summary DROP PARTITION p20240601;

-- 步骤 2：重建该分区（先删后 REORGANIZE 重建）
ALTER TABLE orders_daily_summary
REORGANIZE PARTITION pmax INTO (
    PARTITION p20240601 VALUES LESS THAN ('2024-06-02'),
    PARTITION pmax      VALUES LESS THAN MAXVALUE
);

-- 步骤 3：写入最新计算结果
INSERT INTO orders_daily_summary (agg_date, dept_id, total_amount, order_count)
SELECT '2024-06-01', dept_id, SUM(amount), COUNT(*)
FROM orders
WHERE order_date = '2024-06-01'
GROUP BY dept_id;
```

这个模式的关键在于表的分区粒度要与数据更新的粒度对齐。如果每天重算昨日数据，分区最好是按天建；如果每小时重算最近一小时的数据，可以考虑按天建分区然后在应用层管理小时粒度的覆盖逻辑。分区粒度设计错误（比如按季度分区但每天都需要更新），会让这个模式的代价大幅上升（每次要重写整个季度的数据）。

### 3.2 全量覆盖写入（小表场景）

对于行数不超过数百万的小型维度表或配置表，当数据发生变化时，最简单粗暴但往往最有效的策略是：`TRUNCATE TABLE` 清空全表，然后重新写入最新的全量数据。

```sql
-- 维度表更新：全量覆盖
TRUNCATE TABLE dim_product;

-- 重新导入最新的商品维度数据
LOAD DATA INFILE '/data/dim/product_20240601.csv'
INTO TABLE dim_product
FIELDS TERMINATED BY ','
LINES TERMINATED BY '\n';
```

`TRUNCATE TABLE` 在 GBase 8a 里比 `DELETE FROM table`（全表删除）快得多，因为 TRUNCATE 直接重置存储文件，不需要逐行扫描和标记删除。全量覆盖写入的适用边界是表的行数——对于超过 1000 万行的表，全量重写的时间开销可能无法接受，需要考虑增量更新策略。

### 3.3 追加写入 + 版本化（适合有历史追溯需求的场景）

对于需要追溯历史变更的场景（如记录每次状态变更的完整历史，或者缓慢变化维度 SCD 的处理），可以放弃原地更新，改为追加写入新版本的记录，并用版本号或有效期字段来标识哪一条是当前有效记录。

```sql
-- 设计思路：每次数据变更追加一行新记录，不修改原有记录
CREATE TABLE dim_customer_history (
    customer_id   INT,
    customer_name VARCHAR(100),
    level         VARCHAR(20),
    valid_from    DATE NOT NULL,   -- 该版本的生效日期
    valid_to      DATE,            -- 该版本的失效日期（NULL 表示当前有效）
    is_current    TINYINT DEFAULT 1  -- 1 = 当前有效，0 = 历史版本
) DISTRIBUTED BY HASH(customer_id);

-- 数据变更时：不 UPDATE，而是追加新记录并标记旧记录失效
-- 步骤 1：把旧记录的 valid_to 和 is_current 更新（这里的 UPDATE 只涉及极少数行）
UPDATE dim_customer_history
SET valid_to = CURDATE() - INTERVAL 1 DAY, is_current = 0
WHERE customer_id = 10001 AND is_current = 1;

-- 步骤 2：插入新版本记录
INSERT INTO dim_customer_history
    (customer_id, customer_name, level, valid_from, valid_to, is_current)
VALUES (10001, '张三', 'GOLD', CURDATE(), NULL, 1);
```

这个模式下 UPDATE 只发生在极少数目标行上（当前有效版本），对整体性能影响很小。代价是表的总行数会随时间持续增长（每次变更都追加新行），需要定期归档历史版本数据，防止表无限膨胀。查询时也需要加上 `WHERE is_current = 1` 的过滤条件来只读取当前有效数据。

### 3.4 状态标记 + 定期合并（适合高频小批量更新场景）

对于无法完全避免 UPDATE 的场景（如业务需要实时更新少量记录的状态），一种可行的折中方案是引入一张小型的"增量变更表"，把需要更新的记录先写入增量表，定期将增量表的变更合并回主表。

```sql
-- 增量变更表：只存需要更新的记录，行数少
CREATE TABLE orders_status_delta (
    order_id   BIGINT,
    new_status TINYINT,
    updated_at DATETIME
) DISTRIBUTED BY HASH(order_id);

-- 业务系统将状态变更写入增量表（插入代价低）
INSERT INTO orders_status_delta (order_id, new_status, updated_at)
VALUES (12345678, 2, NOW());

-- 定期合并（每小时或每天执行一次，批量 UPDATE）
UPDATE orders o
JOIN orders_status_delta d ON o.order_id = d.order_id
SET o.status = d.new_status
WHERE d.updated_at &gt;= NOW() - INTERVAL 1 HOUR;

-- 合并后清理增量表
DELETE FROM orders_status_delta
WHERE updated_at &lt; NOW() - INTERVAL 1 HOUR;
```

这个模式把高频的单行更新请求聚合成低频的批量 UPDATE，利用 GBase 8a 对批量操作比单行操作更高效的特性。每次批量 UPDATE 涉及的行数越多，单行的平均更新代价越低。合并窗口的设计（每小时还是每天）需要根据业务对数据新鲜度的容忍程度来决定。

---

## 四、不可避免的 UPDATE/DELETE 时如何降低代价

有些场景确实无法完全避免 UPDATE/DELETE，比如错误数据的修正、紧急的数据清理等。在这类情况下，以下几点能有效降低操作代价。

​**缩小扫描范围**​：UPDATE 和 DELETE 的代价主要来自分布式扫描，WHERE 条件越精确，扫描的范围越小，代价越低。如果表有分区，WHERE 条件中务必包含分区键的过滤条件，让分区裁剪生效，把扫描范围限制在少数几个分区内。

```sql
-- 低效：不带分区键条件，需要扫描所有分区
DELETE FROM orders WHERE order_id = 12345678;

-- 高效：带分区键条件，只扫描特定分区
DELETE FROM orders
WHERE order_date = '2024-06-01'   -- 分区键，触发分区裁剪
  AND order_id = 12345678;
```

​**在业务低峰期执行**​：UPDATE/DELETE 操作会占用 gnode 的 I/O 和 CPU 资源，与同期进行的查询产生竞争。对于非紧急的数据修正，应安排在凌晨业务低峰期执行，降低对正常查询的影响。

​**分批执行大批量更新**​：一次性更新几百万行，比分成 10 次、每次更新几十万行，对系统资源的冲击更大。分批执行虽然总时间可能更长，但对并发查询的影响更小，系统整体的稳定性更好。

---

## 五、设计决策检查清单

在设计涉及数据更新的业务模块时，用以下问题来指导架构选择：

这批数据更新的粒度是什么？如果是按时间范围批量更新，优先考虑分区级删除 + 重写；如果是全维度表更新，用 TRUNCATE+ 全量写入；如果是逐行状态变更，考虑版本化追加或增量合并。

数据更新的频率是多少？每天一次的 ETL 更新，分区级重写是最合适的；每小时一次，可以接受增量合并的延迟；每分钟或更高频，需要在架构层面考虑把实时更新的部分放在一个独立的小型缓存层（如 Redis 或一张小的 GBase 8a 热数据表），定期批量刷入主表。

业务是否需要查询历史状态？如果需要追溯历史，采用版本化设计，追加写入而非原地更新；如果只需要当前状态，分区重写或 TRUNCATE 覆盖更简单高效。

对数据一致性的要求是实时还是准实时？GBase 8a 不支持事务，如果业务要求更新多张表的操作要么全部成功要么全部回滚，需要在应用层实现补偿逻辑，或者接受准实时一致性（通过对账和修复机制来保证最终一致性）。

---

## 六、与 OLTP 数据库的分工协作

理解了 GBase 8a 在数据更新方面的特性，就能更清晰地定位它在整个数据平台中的合理角色。GBase 8a 最擅长的事情是大批量数据的高吞吐写入、以及对海量数据的高效分析查询，这两件事它做得比任何单机 OLTP 数据库都好。GBase 8a 不擅长的是高频的单行随机更新，这正是 MySQL/Oracle 的强项。

因此，架构上最常见也最合理的分工是：业务系统的实时操作数据库（ODS）保留在 MySQL 或 Oracle，承接所有的实时读写；GBase 8a 承接分析查询，通过定期的 ETL（每小时或每天）从 OLTP 库同步数据。在 GBase 8a 内部，同步过来的数据按批量分区写入，查询完全面向分析场景，不存在实时单行更新的需求。这种分工让每个数据库都在自己最擅长的场景下工作，整体系统的性能和稳定性远好于把 GBase 8a 同时当成 OLTP 和 OLAP 来用。



性能调优

GBase 8a 数据更新策略：列存 MPP 中的 UPDATE/DELETE 代价与正确设计模式

GBase 8a 数据更新策略：列存 MPP 中的 UPDATE/DELETE 代价与正确设计模式

评论

热门帖子