HappenLee commented on code in PR #3975: URL: https://github.com/apache/doris-website/pull/3975#discussion_r3581695620
########## i18n/zh-CN/docusaurus-plugin-content-docs/current/query-acceleration/query-cache.md: ########## @@ -179,6 +179,54 @@ Query Cache 依赖内部 OLAP 表的三个特有属性： 外部表的缓存需求请改用 [SQL Cache](./sql-cache-manual.md)。 +## 增量合并（实验性） + +<!-- 知识类型：原理 + 操作 --> +<!-- 适用场景：小时级批量导入不断写入热分区，导致其缓存条目反复失效 --> + +默认情况下，版本落后的缓存条目（例如按小时导入的表的当前分区）会被直接作废，对应的 Pipeline 实例回到全量扫描重算。开启**增量合并**后，BE 会复用这条过期条目：只扫描 `(缓存版本, 当前版本]` 区间的增量 rowset，把增量的聚合中间状态与缓存的中间状态**并排**交给上游合并聚合（两者本就是同构的可合并输入），并以新版本回写合并后的条目。对小时级导入场景，热分区的扫描成本从“每小时扫整个分区”降为“只扫最近一小时的新数据”。 + + + +```sql +SET enable_query_cache = true; +SET enable_query_cache_incremental = true; -- SHOW VARIABLES 中显示为 experimental_enable_query_cache_incremental +``` + +### 生效前提 + +增量合并仅在**同时**满足以下条件时生效；任一不满足都会静默回退为全量重算，查询结果始终正确： + +1. 被扫描的索引（基表或选中的 rollup）为**追加写**模型：**DUP_KEYS** 表，或增量窗口内未改写既有主键的**写时合并（merge-on-write）UNIQUE_KEYS** 表。对写时合并表，BE 会按 tablet 检查 `(cached_version, current_version]` 窗口内的 delete bitmap：窗口内只新增了全新主键（主键表上常见的“每小时追加导入”模式）即可增量合并；一旦有 upsert、部分列更新或 delete sign 命中了更早的主键，则回退一次全量重算，重算会以新版本重建条目，下一次纯追加导入即恢复增量。读时合并（merge-on-read）UNIQUE 表在读取时跨 rowset 归并去重、AGG 表在存储层合并行，“缓存快照 + 增量 = 新快照”不成立；聚合物化视图同理被拒绝。 +2. 缓存点是**直接位于扫描之上、且不做 finalize 的聚合**（常见的两阶段聚合形态，例如按非分桶列 `GROUP BY`）。单阶段聚合与嵌套聚合缓存点会被拒绝。 +3. 集群为**存算一体（本地存储）**部署。 +4. 增量版本路径仍可捕获（未被 compaction 合并跨界），且增量中**不含 DELETE 谓词**（增量中的删除会逻辑上移除已折入缓存块的行，无法通过合并撤销）。 + +写时合并表的 delete bitmap 窗口检查方式如下： + + + +### 合并条目的压实 Review Comment: 这里的中文表述可能不是很好理解，我建议改成增量部分的合并或者刷新会比压实更好理解一些 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
