doris中有使用到什么索引，doris中的主键模型、明细明细、聚合模型的底层设计原则是什么

<think>好的，我现在需要回答用户关于Doris中使用的索引类型以及主键模型、明细模型和聚合模型的底层设计原则的问题。首先，我需要回忆一下Doris的相关知识，确保信息的准确性。 关于索引部分，我记得Doris主要使用前缀索引和智能的物化视图来加速查询。前缀索引是按照排序列的前36个字节构建的，可能用户提到的rollup表也属于物化视图的一部分。需要明确说明前缀索引的工作原理，比如匹配列的顺序，以及如何通过rollup调整前缀索引。 接下来是数据模型部分。用户提到了主键模型、明细模型和聚合模型。主键模型（Unique Key）应该是指使用Merge-on-Read的方式，在写入时处理主键冲突，适用于频繁更新的场景。需要解释其底层是LSM-Tree结构，以及数据分为Base数据和Delta数据的部分，还有Compaction的过程。 明细模型（Duplicate Key）应该是存储原始数据，没有聚合，主键由所有排序列组成。需要强调其适用于日志类数据，主键只是排序方式，不用于去重。而聚合模型（Aggregate Key）则是通过预聚合减少数据量，查询时直接取聚合结果，适用于统计报表的场景。需要说明其存储的是聚合后的数据，比如SUM、MAX等。 底层设计原则方面，主键模型的设计原则可能包括高效更新、实时可见性和存储优化。明细模型则是数据全量存储和查询灵活性。聚合模型是计算前置，存储优化和查询加速。需要将这些原则与各自模型的特点对应起来，比如主键模型的Merge-on-Read和LSM-Tree结构，明细模型的全量存储，聚合模型的预聚合。 需要确保回答结构清晰，分点说明，使用中文，并且正确应用LaTeX格式。检查是否有遗漏的索引类型，比如倒排索引或Bloom Filter，如果有的话需要补充。同时，确认每个模型的描述准确，不混淆主键模型和聚合模型的应用场景。 可能还需要验证主键模型是否确实使用Merge-on-Read，以及LSM-Tree的结构是否正确。另外，明细模型的主键是否由所有指定的排序列组成，是否真的不用于去重。聚合模型的聚合时机是在写入时还是查询时，应该是写入时进行预聚合，所以查询时直接读取结果。 最后，组织回答的结构，先介绍索引类型，再分别详细说明每个模型的底层设计原则，确保每个部分都有清晰的标题和要点，使用户能够逐步理解。</think>### Doris索引类型 1. **前缀索引（Prefix Index）** - 自动按建表时`AGGREGATE KEY`/`UNIQUE KEY`/`DUPLICATE KEY`的前36字节生成稀疏索引 - 查询时**严格按列顺序匹配**才能命中，例如建表顺序为`(dt, city, uid)`，则： ```sql WHERE dt = '2023-01-01' AND city = '北京' -- 命中索引 WHERE city = '北京' AND dt = '2023-01-01' -- 不命中 ``` - 可通过`ROLLUP`调整列顺序生成新前缀索引 2. **智能物化视图（Materialized View）** - 自动路由查询到最优物化视图 - 支持预聚合、列裁剪、排序优化等特性 3. **辅助索引**（2.0+版本） - **倒排索引**：支持文本字段快速检索 - **Bloom Filter索引**：高效判断数据是否存在 - **ZoneMap索引**：自动记录数据块的最大最小值 --- ### 数据模型底层设计原则 #### 一、主键模型（Unique Key） - **核心机制**：Merge-on-Read + LSM-Tree - **存储结构**： ```text ┌───────────┐ ┌───────────┐ │ 内存Buffer │ → Flush → │ 磁盘Base数据 │ └───────────┘ └───────────┘ ↑ ↓ └── Compaction ←─── Delta数据 ``` - **设计原则**： 1. **高效更新**：写入时主键冲突直接覆盖（内存中处理） 2. **实时可见**：写入后立即可查，通过内存Buffer实现 3. **存储优化**：定期Compaction合并数据，减少读放大 - **适用场景**：订单状态更新、用户属性变更等高频更新场景 #### 二、明细模型（Duplicate Key） - **存储方式**： ```sql CREATE TABLE logs ( ts DATETIME, ip VARCHAR(15), url VARCHAR(500) ) DUPLICATE KEY(ts, ip) -- 仅定义数据排序方式 ``` - **设计原则**： 1. **原始数据存储**：不进行任何聚合，保留明细 2. **全列索引**：所有列均可作为过滤条件 3. **写入高效**：直接追加写入不做计算 - **适用场景**：日志分析、行为轨迹等需要完整原始数据的场景 #### 三、聚合模型（Aggregate Key） - **预聚合机制**： ```sql CREATE TABLE stats ( dt DATE, province VARCHAR(10), uv BIGINT SUM, pv BIGINT SUM ) AGGREGATE KEY(dt, province) ``` 写入数据`(2023-01-01, 北京, 1, 5)`会自动合并到已有记录 - **设计原则**： 1. **计算前置**：在数据加载阶段完成聚合 2. **存储优化**：相同维度数据只保留一行 3. **查询加速**：直接读取预计算结果 - **存储格式**： ```text │ dt │ province │ uv │ pv │ ├────────────┼──────────┼─────┼─────┤ │ 2023-01-01 │ 北京 │ 100 │ 500 │ ← 已聚合结果 ``` - **适用场景**：PV/UV统计、销售报表等分析型场景 --- ### 性能对比 | 特性 | 主键模型 | 明细模型 | 聚合模型 | |---------------|--------------|--------------|--------------| | 写入速度 | 中 | 高 | 中 | | 存储空间 | 中 | 高 | 低 | | 点查效率 | 高 | 低 | 中 | | 更新支持 | ✔️ | ❌ | ❌ | | 数据粒度 | 最新版本 | 原始明细 | 聚合结果 | 实际应用中建议： 1. 需要更新的业务数据 → **主键模型** 2. 日志/行为分析 → **明细模型** 3. 固定维度统计 → **聚合模型**