数据缓存
从 v3.1.7 和 v3.2.3 版本开始，StarRocks 引入了 Data Cache 以加速共享数据集群中的查询，取代了早期版本中的 File Cache。 Data Cache 根据需要以块（MB 级）的形式从远程存储加载数据，而 File Cache 每次都在后台加载整个数据文件，无论实际需要多少数据行。
与 File Cache 相比，Data Cache 具有以下优势
- 从对象存储读取的次数更少，这意味着访问对象存储的成本更低（如果您的对象存储按访问频率收费）。
- 本地磁盘和 CPU 使用率的写入压力更小，因此对其他加载或查询任务的影响更小（因为不再需要后台加载线程）。
- 优化的缓存效果（因为 File Cache 可能会加载文件中不太常用的数据）。
- 优化了对缓存数据的控制，从而避免了本地磁盘因 File Cache 未能逐出过多数据而不堪重负。
启用 Data Cache
从 v3.4.0 版本开始，StarRocks 使用统一的 Data Cache 实例来查询外部目录和云原生表（在共享数据集群中）。
配置 Data Cache
您可以使用以下 CN(BE) 配置项来配置 Data Cache
缓存目录
- storage_root_path（在共享数据集群中，此项用于指定缓存数据存储的根路径。）
缓存磁盘大小
共享数据集群中缓存的磁盘大小采用 datacache_disk_size 和 starlet_star_cache_disk_size_percent 之间的较大值。
查看 Data Cache 状态
-
执行以下语句以查看存储缓存数据的根路径
SELECT * FROM information_schema.be_configs
WHERE NAME LIKE "%storage_root_path%";通常，缓存数据存储在
storage_root_path的子路径datacache/下。 -
执行以下语句以查看 Data Cache 可以使用的最大存储百分比
SELECT * FROM information_schema.be_configs
WHERE NAME LIKE "%starlet_star_cache_disk_size_percent% or %datacache_disk_size%";
监控 Data Cache
StarRocks 提供了各种监控 Data Cache 的指标。
仪表板模板
您可以根据您的 StarRocks 环境下载以下 Grafana 仪表板模板
重要指标
fslib read io_latency
记录 Data Cache 的读取延迟。
fslib write io_latency
记录 Data Cache 的写入延迟。
fslib star cache meta memory size
记录 Data Cache 的估计内存使用量。
fslib star cache data disk size
记录 Data Cache 的实际磁盘使用量。
禁用 Data Cache
要禁用 Data Cache，您需要将以下配置添加到 CN 配置文件 cn.conf 中，并重新启动 CN 节点
datacache_enable = false
storage_root_path =
清除缓存数据
您可以清除缓存数据以应对紧急情况。 这不会影响远程存储中的原始数据。
请按照以下步骤清除 CN 节点上的缓存数据
-
删除存储数据的子目录。
示例
# Suppose `storage_root_path = /data/disk1;/data/disk2`
rm -rf /data/disk1/datacache/
rm -rf /data/disk2/datacache/ -
重新启动 CN 节点。
使用说明
- 如果云原生表的
datacache.enable属性设置为false，则不会为此表启用 Data Cache。 - 如果
datacache.partition_duration属性设置为特定时间范围，则不会缓存超出该时间范围的数据。 - 将共享数据集群从 v3.3 降级到 v3.2.8 及更早版本后，如果要重新使用 Data Cache 中的缓存数据，则需要手动重命名目录
starlet_cache中的 Blockfile，方法是将文件名格式从blockfile_{n}.{version}更改为blockfile_{n}，即删除版本信息的后缀。 v3.2.9 及更高版本与 v3.3 中的文件名格式兼容，因此您无需手动执行此操作。 您可以通过运行以下 shell 脚本来更改名称
#!/bin/bash
# Replace <starlet_cache_path> with the directory of Data Cache of your cluster, for example, /usr/be/storage/starlet_cache.
starlet_cache_path="<starlet_cache_path>"
for blockfile in ${starlet_cache_path}/blockfile_*; do
if [ -f "$blockfile" ]; then
new_blockfile=$(echo "$blockfile" | cut -d'.' -f1)
mv "$blockfile" "$new_blockfile"
fi
done
已知问题
高内存使用率
- 描述：当集群在低负载条件下运行时，CN 节点的总内存使用量远远超过每个模块的内存使用量之和。
- 识别：如果
fslib star cache meta memory size和fslib star cache data memory size的总和占 CN 节点总内存使用量的很大一部分，则可能表明存在此问题。 - 受影响的版本：v3.1.8 及更早的补丁版本，以及 v3.2.3 及更早的补丁版本
- 修复版本：v3.1.9, v3.2.4
- 解决方案
- 将集群升级到修复版本。
- 如果您不想升级集群，可以清除 CN 节点的
${storage_root_path}/starlet_cache/star_cache/meta目录，然后重新启动节点。
问答
Q1: 为什么 Data Cache 目录占用的存储空间（通过 du 和 ls 命令观察到）比实际缓存数据的大小大得多？
Data Cache 占用的磁盘空间代表历史峰值使用量，与当前实际缓存数据大小无关。 例如，如果缓存了 100 GB 的数据，则在压缩后数据大小将变为 200 GB。 然后，经过垃圾回收 (GC) 后，数据大小减少到 100 GB。 但是，Data Cache 占用的磁盘空间将保持在 200 GB 的峰值，即使其中实际缓存的数据为 100 GB。
Q2: Data Cache 是否自动逐出数据？
不。 Data Cache 仅在达到磁盘使用率限制（默认情况下为 80% 的磁盘空间）时才逐出数据。 逐出过程不会删除数据； 它只是将存储旧缓存的磁盘空间标记为空。 然后，新缓存将覆盖旧缓存。 因此，即使发生逐出，磁盘使用率也不会降低，也不会影响实际使用率。
Q3: 为什么磁盘使用率保持在配置的最大级别而不降低？
请参阅 Q2。Data Cache 逐出机制不会删除缓存的数据，而是将旧数据标记为可覆盖。 因此，磁盘使用率不会降低。
Q4: 为什么在我删除表并且表文件从远程存储中删除后，Data Cache 的磁盘使用率保持在同一水平？
删除表不会触发 Data Cache 中数据的删除。 已删除表的缓存将根据 Data Cache 的 LRU（最近最少使用）逻辑随时间逐渐逐出，这不会影响实际使用率。
Q5: 为什么即使配置了 80% 的磁盘容量，实际磁盘使用率也达到 90% 或更高？
Data Cache 的磁盘使用率是准确的，不会超过配置的限制。 过高的磁盘使用率可能是由以下原因造成的
- 运行时生成的日志文件。
- CN 崩溃生成的 Core 文件。
- 主键表的持久索引（存储在
${storage_root_path}/persist/下）。 - 共享同一磁盘的 BE/CN/FE 实例的混合部署。
- 磁盘问题，例如，使用了 ext3 文件系统。
您可以在磁盘根目录或子目录中执行 du -h . -d 1 来检查特定占用空间的目录，然后删除意外的部分。 您还可以通过配置 starlet_star_cache_disk_size_percent 来降低 Data Cache 的磁盘容量限制。
Q6: 为什么节点之间 Data Cache 的磁盘使用率存在显着差异？
由于单节点缓存的固有局限性，无法确保节点之间的缓存使用率一致。 只要不影响查询延迟，缓存使用率的差异是可以接受的。 这种差异可能是由以下原因造成的
- 将节点添加到集群的不同时间点。
- 不同节点拥有的 Tablet 数量不同。
- 不同 Tablet 拥有的数据大小不同。
- 节点之间压缩和 GC 情况的差异。
- 节点遇到崩溃或内存不足 (OOM) 问题。
总而言之，缓存使用率的差异受多种因素影响。