Doris系列20-分区缓存

最新推荐文章于 2025-06-09 01:33:03 发布

原创

最新推荐文章于 2025-06-09 01:33:03 发布 · 1.3k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#Doris 缓存 #Doris性能优化 #Doris分区缓存

本文介绍Doris中的分区缓存策略，包括SQLCache和PartitionCache两种方式，重点讲解PartitionCache的设计原理及使用方法，适用于高并发、复杂图表展示等场景。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

文章目录

一. 分区缓存概述
二. 使用方式
- 2.1 开启SQLCache
- 2.2 开启PartitionCache
参考:

一. 分区缓存概述

1.1 需求场景

大部分数据分析场景是写少读多，数据写入一次，多次频繁读取，比如一张报表涉及的维度和指标，数据在凌晨一次性计算好，但每天有数百甚至数千次的页面访问，因此非常适合把结果集缓存起来。在数据分析或BI应用中，存在下面的业务场景：

高并发场景，Doris可以较好的支持高并发，但单台服务器无法承载太高的QPS
复杂图表的看板，复杂的Dashboard或者大屏类应用，数据来自多张表，每个页面有数十个查询，虽然每个查询只有数十毫秒，但是总体查询时间会在数秒
趋势分析，给定日期范围的查询，指标按日显示，比如查询最近7天内的用户数的趋势，这类查询数据量大，查询范围广，查询时间往往需要数十秒
用户重复查询，如果产品没有防重刷机制，用户因手误或其他原因重复刷新页面，导致提交大量的重复的SQL

以上四种场景，在应用层的解决方案，把查询结果放到Redis中，周期性的更新缓存或者用户手工刷新缓存，但是这个方案有如下问题：

数据不一致，无法感知数据的更新，导致用户经常看到旧的数据
命中率低，缓存整个查询结果，如果数据实时写入，缓存频繁失效，命中率低且系统负载较重
额外成本，引入外部缓存组件，会带来系统复杂度，增加额外成本

1.2 解决方案

本分区缓存策略可以解决上面的问题，优先保证数据一致性，在此基础上细化缓存粒度，提升命中率，因此有如下特点：

用户无需担心数据一致性，通过版本来控制缓存失效，缓存的数据和从BE中查询的数据是一致的
没有额外的组件和成本，缓存结果存储在BE的内存中，用户可以根据需要调整缓存内存大小
实现了两种缓存策略，SQLCache和PartitionCache，后者缓存粒度更细
用一致性哈希解决BE节点上下线的问题，BE中的缓存算法是改进的LRU

1.3 SQLCache

SQLCache按SQL的签名、查询的表的分区ID、分区最新版本来存储和获取缓存。三者组合确定一个缓存数据集，任何一个变化了，如SQL有变化，如查询字段或条件不一样，或数据更新后版本变化了，会导致命中不了缓存。

如果多张表Join，使用最近更新的分区ID和最新的版本号，如果其中一张表更新了，会导致分区ID或版本号不一样，也一样命中不了缓存。

SQLCache，更适合T+1更新的场景，凌晨数据更新，首次查询从BE中获取结果放入到缓存中，后续相同查询从缓存中获取。实时更新数据也可以使用，但是可能存在命中率低的问题，可以参考如下PartitionCache。

1.4 PartitionCache

1.4.1 设计原理

SQL可以并行拆分，Q = Q1 ∪ Q2 … ∪ Qn，R= R1 ∪ R2 … ∪ Rn，Q为查询语句，R为结果集
拆分为只读分区和可更新分区，只读分区缓存，更新分区不缓存

如上，查询最近7天的每天用户数，如按日期分区，数据只写当天分区，当天之外的其他分区的数据，都是固定不变的，在相同的查询SQL下，查询某个不更新分区的指标都是固定的。如下，在2020-03-09当天查询前7天的用户数，2020-03-03至2020-03-07的数据来自缓存，2020-03-08第一次查询来自分区，后续的查询来自缓存，2020-03-09因为当天在不停写入，所以来自分区。

因此，查询N天的数据，数据更新最近的D天，每天只是日期范围不一样相似的查询，只需要查询D个分区即可，其他部分都来自缓存，可以有效降低集群负载，减少查询时间。

MySQL [(none)]> SELECT eventdate,count(userid) FROM testdb.appevent WHERE eventdate>="2020-03-03" AND eventdate<="2020-03-09" GROUP BY eventdate ORDER BY eventdate;
+------------+-----------------+
| eventdate  | count(`userid`