Apache Doris Unique 模型：深度解析主键更新与部分列操作优化-171主机测评

Apache Doris Unique 模型：深度解析主键更新与部分列操作优化

Apache Doris 的 Unique 模型是一种特殊的表模型，它通过维护一个唯一键来实现数据的更新和删除操作。与传统的 OLAP 数据库不同，Doris 的 Unique 模型允许在数据仓库中进行高效的数据更新操作，这对于需要频繁更新数据的业务场景非常重要。

1. Doris Unique 模型基础原理与特点

Unique 模型的核心原理是基于主键构建一个索引结构，当有新的数据插入时，系统会根据主键查找是否已存在相同主键的记录。如果存在，则使用新数据替换旧数据；如果不存在，则直接插入新记录。这种机制实现了数据的高效更新和删除操作。

与其他表模型相比，Unique 模型的特点在于：

支持数据的原地更新，不需要删除和重新插入整行数据

保证主键的唯一性，避免重复数据

提供高效的查询性能，尤其适用于点查询和范围查询

支持部分列更新，只更新变化的数据列，提高更新效率

Unique 模型适用于以下场景：

需要频繁更新数据的业务系统
主键明确的维度表
需要支持增量更新的实时分析场景
对数据一致性要求较高的应用

#publish-mermaid-0-1790499237792{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;fill:#333;}@keyframes edge-animation-frame{from{stroke-dashoffset:0;}}@keyframes dash{to{stroke-dashoffset:0;}}#publish-mermaid-0-1790499237792 .edge-animation-slow{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 50s linear infinite;stroke-linecap:round;}#publish-mermaid-0-1790499237792 .edge-animation-fast{stroke-dasharray:9,5!important;stroke-dashoffset:900;animation:dash 20s linear infinite;stroke-linecap:round;}#publish-mermaid-0-1790499237792 .error-icon{fill:#552222;}#publish-mermaid-0-1790499237792 .error-text{fill:#552222;stroke:#552222;}#publish-mermaid-0-1790499237792 .edge-thickness-normal{stroke-width:1px;}#publish-mermaid-0-1790499237792 .edge-thickness-thick{stroke-width:3.5px;}#publish-mermaid-0-1790499237792 .edge-pattern-solid{stroke-dasharray:0;}#publish-mermaid-0-1790499237792 .edge-thickness-invisible{stroke-width:0;fill:none;}#publish-mermaid-0-1790499237792 .edge-pattern-dashed{stroke-dasharray:3;}#publish-mermaid-0-1790499237792 .edge-pattern-dotted{stroke-dasharray:2;}#publish-mermaid-0-1790499237792 .marker{fill:#333333;stroke:#333333;}#publish-mermaid-0-1790499237792 .marker.cross{stroke:#333333;}#publish-mermaid-0-1790499237792 svg{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:16px;}#publish-mermaid-0-1790499237792 p{margin:0;}#publish-mermaid-0-1790499237792 .label{font-family:\”trebuchet ms\”,verdana,arial,sans-serif;color:#333;}#publish-mermaid-0-1790499237792 .cluster-label text{fill:#333;}#publish-mermaid-0-1790499237792 .cluster-label span{color:#333;}#publish-mermaid-0-1790499237792 .cluster-label span p{background-color:transparent;}#publish-mermaid-0-1790499237792 .label text,#publish-mermaid-0-1790499237792 span{fill:#333;color:#333;}#publish-mermaid-0-1790499237792 .node rect,#publish-mermaid-0-1790499237792 .node circle,#publish-mermaid-0-1790499237792 .node ellipse,#publish-mermaid-0-1790499237792 .node polygon,#publish-mermaid-0-1790499237792 .node path{fill:#ECECFF;stroke:#9370DB;stroke-width:1px;}#publish-mermaid-0-1790499237792 .rough-node .label text,#publish-mermaid-0-1790499237792 .node .label text,#publish-mermaid-0-1790499237792 .image-shape .label,#publish-mermaid-0-1790499237792 .icon-shape .label{text-anchor:middle;}#publish-mermaid-0-1790499237792 .node .katex path{fill:#000;stroke:#000;stroke-width:1px;}#publish-mermaid-0-1790499237792 .rough-node .label,#publish-mermaid-0-1790499237792 .node .label,#publish-mermaid-0-1790499237792 .image-shape .label,#publish-mermaid-0-1790499237792 .icon-shape .label{text-align:center;}#publish-mermaid-0-1790499237792 .node.clickable{cursor:pointer;}#publish-mermaid-0-1790499237792 .root .anchor path{fill:#333333!important;stroke-width:0;stroke:#333333;}#publish-mermaid-0-1790499237792 .arrowheadPath{fill:#333333;}#publish-mermaid-0-1790499237792 .edgePath .path{stroke:#333333;stroke-width:1px;}#publish-mermaid-0-1790499237792 .flowchart-link{stroke:#333333;fill:none;}#publish-mermaid-0-1790499237792 .edgeLabel{background-color:rgba(232,232,232, 0.8);text-align:center;}#publish-mermaid-0-1790499237792 .edgeLabel p{background-color:rgba(232,232,232, 0.8);}#publish-mermaid-0-1790499237792 .edgeLabel rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#publish-mermaid-0-1790499237792 .labelBkg{background-color:rgba(232, 232, 232, 0.5);}#publish-mermaid-0-1790499237792 .cluster rect{fill:#ffffde;stroke:#aaaa33;stroke-width:1px;}#publish-mermaid-0-1790499237792 .cluster text{fill:#333;}#publish-mermaid-0-1790499237792 .cluster span{color:#333;}#publish-mermaid-0-1790499237792 div.mermaidTooltip{position:absolute;text-align:center;max-width:200px;padding:2px;font-family:\”trebuchet ms\”,verdana,arial,sans-serif;font-size:12px;background:hsl(80, 100%, 96.2745098039%);border:1px solid #aaaa33;border-radius:2px;pointer-events:none;z-index:100;}#publish-mermaid-0-1790499237792 .flowchartTitleText{text-anchor:middle;font-size:18px;fill:#333;}#publish-mermaid-0-1790499237792 rect.text{fill:none;stroke-width:0;}#publish-mermaid-0-1790499237792 .icon-shape,#publish-mermaid-0-1790499237792 .image-shape{background-color:rgba(232,232,232, 0.8);text-align:center;}#publish-mermaid-0-1790499237792 .icon-shape p,#publish-mermaid-0-1790499237792 .image-shape p{background-color:rgba(232,232,232, 0.8);padding:2px;}#publish-mermaid-0-1790499237792 .icon-shape .label rect,#publish-mermaid-0-1790499237792 .image-shape .label rect{opacity:0.5;background-color:rgba(232,232,232, 0.8);fill:rgba(232,232,232, 0.8);}#publish-mermaid-0-1790499237792 .label-icon{display:inline-block;height:1em;overflow:visible;vertical-align:-0.125em;}#publish-mermaid-0-1790499237792 .node .label-icon path{fill:currentColor;stroke:revert;stroke-width:revert;}#publish-mermaid-0-1790499237792 .node .neo-node{stroke:#9370DB;}#publish-mermaid-0-1790499237792 [data-look=\”neo\”].node rect,#publish-mermaid-0-1790499237792 [data-look=\”neo\”].cluster rect,#publish-mermaid-0-1790499237792 [data-look=\”neo\”].node polygon{stroke:#9370DB;filter:drop-shadow(1px 2px 2px rgba(185, 185, 185, 1));}#publish-mermaid-0-1790499237792 [data-look=\”neo\”].swimlane.cluster rect{filter:none;}#publish-mermaid-0-1790499237792 [data-look=\”neo\”].node path{stroke:#9370DB;stroke-width:1px;}#publish-mermaid-0-1790499237792 [data-look=\”neo\”].node .outer-path{filter:drop-shadow(1px 2px 2px rgba(185, 185, 185, 1));}#publish-mermaid-0-1790499237792 [data-look=\”neo\”].node .neo-line path{stroke:#9370DB;filter:none;}#publish-mermaid-0-1790499237792 [data-look=\”neo\”].node circle{stroke:#9370DB;filter:drop-shadow(1px 2px 2px rgba(185, 185, 185, 1));}#publish-mermaid-0-1790499237792 [data-look=\”neo\”].node circle .state-start{fill:#000000;}#publish-mermaid-0-1790499237792 [data-look=\”neo\”].icon-shape .icon{fill:#9370DB;filter:drop-shadow(1px 2px 2px rgba(185, 185, 185, 1));}#publish-mermaid-0-1790499237792 [data-look=\”neo\”].icon-shape .icon-neo path{stroke:#9370DB;filter:drop-shadow(1px 2px 2px rgba(185, 185, 185, 1));}#publish-mermaid-0-1790499237792 :root{–mermaid-font-family:\”trebuchet ms\”,verdana,arial,sans-serif;}是否是否

接收更新请求

解析主键值

查询现有数据

是否已存在相同主键?

比较数据版本

插入新数据

新数据是否更新?

执行更新操作

操作结束

更新索引和统计信息

2. 主键更新机制与性能优化

在 Doris Unique 模型中，主键更新是最常见的操作之一。主键更新的实现依赖于 Doris 内部的索引结构和数据处理机制。

主键更新的实现原理

当执行主键更新操作时，Doris 会按照以下流程处理：

根据主键值定位到对应的行数据

比较新旧数据的版本号或时间戳

使用新数据替换旧数据，同时保留数据的版本信息

更新相关的索引和统计信息

这一过程保证了数据的原子性和一致性，同时尽可能减少了不必要的 I/O 操作。

性能优化策略

为了提高主键更新的性能，可以采取以下策略：

批量更新操作：将多个小的更新操作合并为批量更新，减少元数据操作的开销

合理设置分区键：将热点数据分散到不同的分区，避免单个分区成为性能瓶颈

优化索引结构：根据查询模式选择合适的索引类型，减少数据扫描量

调整并发度：根据系统资源情况，合理设置更新的并发度

使用内存表进行临时更新：对于频繁更新的数据，可以先在内存表中进行更新，然后定期同步到物理表

实际应用案例

假设有一个用户行为分析系统，需要记录用户的每次登录行为，并根据用户ID进行更新。使用 Doris Unique 模型可以高效实现这一需求：

— 创建 Unique 模型表
CREATE TABLE user_login_behavior (
user_id VARCHAR(32),
login_time DATETIME,
ip_address VARCHAR(15),
device_type VARCHAR(20),
location VARCHAR(100),
last_login_time DATETIME,
PRIMARY KEY (user_id)
) UNIQUE KEY (user_id)
DISTRIBUTED BY HASH(user_id)
PROPERTIES (
"replication_num" = "3"
);
— 插入或更新用户登录行为
INSERT INTO user_login_behavior VALUES
('user1', '2023-01-01 10:00:00', '192.168.1.1', 'mobile', 'Beijing', '2023-01-01 10:00:00')
ON DUPLICATE KEY UPDATE
login_time = VALUES(login_time),
ip_address = VALUES(ip_address),
device_type = VALUES(device_type),
location = VALUES(location),
last_login_time = VALUES(last_login_time);

这个示例展示了如何使用 Doris 的 Unique 模型高效地实现用户行为数据的更新操作。

3. 部分列更新与删除操作优化

除了主键更新，部分列更新和删除操作也是日常数据维护中的重要内容。Doris Unique 模型针对这些操作提供了专门的优化机制。

部分列更新的技术实现

在 Doris 中，部分列更新主要基于以下机制：

列式存储优势：Doris 采用列式存储，更新特定列时只需要修改对应的数据块，减少 I/O 开销

增量更新技术：只存储列的变化部分，而非整行数据

版本控制机制：通过多版本控制实现并发更新，避免数据冲突

实现部分列更新的 SQL 示例：

— 更新用户表的部分列
UPDATE user_profile
SET
email = 'new_email@example.com',
phone = '13800138000'
WHERE user_id = 'user123';

在 Unique 模型中，这种操作只会更新指定的列，保留其他列的值不变。

删除操作的最佳实践

在 Doris 中，删除操作通常通过以下方式实现：

逻辑删除：设置状态标记而非物理删除，适合需要历史数据的场景

批量删除：一次性删除多条记录，减少元数据操作

分区裁剪：利用分区特性快速删除整个分区的数据

删除操作的优化策略：

— 使用 DELETE 语句删除特定数据
DELETE FROM user_orders
WHERE order_date < '2022-01-01' AND status = 'cancelled';
— 或者先标记为删除，再定期清理
UPDATE user_orders
SET status = 'deleted'
WHERE order_date < '2022-01-01';

性能调优技巧

对于部分列更新和删除操作，可以采取以下性能调优措施：

调整数据分桶数量：根据数据特点选择合适的分桶数量，避免数据倾斜

优化索引策略：为常用于查询条件的列创建合适的索引

使用物化视图：对于复杂的更新操作，可以先构建物化视图再更新

控制并发度：避免高并发更新导致的锁竞争

定期维护表：执行 ANALYZE TABLE 和 OPTIMIZE TABLE 等操作保持性能

更新操作类型性能影响适用场景优化建议

主键更新	高：需要查找和替换整行数据	主键明确且整行数据需要更新的场景	使用批量操作，避免高并发
部分列更新	中：只需更新指定列	仅需更新部分数据的场景	合理设置分区，使用列式存储优势
删除操作	中高：需要标记和清理数据	需要删除历史数据的场景	使用逻辑删除，定期清理分区
批量更新	低：合并多次操作，减少元数据开销	需要更新多条记录的场景	控制批量大小，避免大事务

4. 实战示例与注意事项

为了更好地理解 Doris Unique 模型的更新操作，下面提供一个完整的实战示例和注意事项。

最小可运行示例

— 创建测试数据库
CREATE DATABASE IF NOT EXISTS doris_test;
— 使用数据库
USE doris_test;
— 创建 Unique 模型表
CREATE TABLE employee (
emp_id INT,
name VARCHAR(50),
department VARCHAR(50),
salary INT,
hire_date DATE,
last_update_time DATETIME,
PRIMARY KEY (emp_id)
) UNIQUE KEY (emp_id)
DISTRIBUTED BY HASH(emp_id)
PROPERTIES (
"replication_num" = "3"
);
— 插入初始数据
INSERT INTO employee VALUES
(1, 'John', 'Engineering', 8000, '2020-01-15', '2023-01-01 10:00:00'),
(2, 'Alice', 'Marketing', 7500, '2019-03-20', '2023-01-01 10:00:00'),
(3, 'Bob', 'Sales', 7000, '2021-07-10', '2023-01-01 10:00:00');
— 主键更新：更新整行数据
INSERT INTO employee VALUES
(1, 'John Doe', 'Engineering', 8500, '2020-01-15', '2023-02-01 11:00:00')
ON DUPLICATE KEY UPDATE
name = VALUES(name),
salary = VALUES(salary),
last_update_time = VALUES(last_update_time);
— 部分列更新：只更新特定列
UPDATE employee
SET
salary = 9000,
last_update_time = '2023-03-01 12:00:00'
WHERE emp_id = 2;
— 删除操作
DELETE FROM employee WHERE emp_id = 3;
— 查询更新后的数据
SELECT * FROM employee;

注意事项

在使用 Doris Unique 模型进行更新操作时，需要注意以下几点：

主键选择：选择稳定且唯一性高的列作为主键，避免频繁变更的主键

批量操作：尽量使用批量更新替代单条更新，减少元数据操作开销

避免大事务：大事务会导致内存消耗增加，影响系统稳定性

合理设置超时时间：根据数据量和系统资源，设置合理的更新操作超时时间

监控更新性能：定期监控更新操作的性能指标，及时发现并解决性能问题

数据一致性：在高并发更新场景下，确保数据一致性，避免脏数据产生

定期维护：定期执行表维护操作，如更新统计信息、优化存储等

Apache Doris Unique 模型：深度解析主键更新与部分列操作优化