产品动态
Page Store 缓存
Page Store 特性概述
从 GooseFS-1.7.0 以上的版本开始支持 Page Store 缓存新特性。相较于传统的 Block Store 缓存，前者可以极大地优化离散 IO 访问模型的缓存空间利用率以及冷读效率。Page Store 与 Block Store 之间的架构比较如下。
Page Store 存储架构打破了原先 Worker 节点上每个块默认 128MB 作为缓存最小单位的限制，在不额外增加任何 Master 节点上的元数据负担的基础上，允许以默认 1MB 大小的页形式在 Worker 节点上缓存数据。
这种存储架构，一方面可以极大地提高缓存空间的利用率；另一方面也可以在单文件随机冷读场景中，可以非常明显地降低请求响应与缓存生效时延。
下面给出了一个 OLAP 查询的随机读场景中，Block 模式与 Page 模式的冷读延时对比。
Page Store 使用方法
为了使用 Page Store 模式，需要将 Worker 的数据存储增加如下配置：
# ...goosefs.worker.block.store.type=PAGE# Worker page storage type.goosefs.worker.page.store.dirs=/Users/yuyang/goosefs-data/paged-blockgoosefs.worker.page.store.page.size=2MBgoosefs.worker.page.store.size=6MBgoosefs.worker.page.store.overhead=0goosefs.worker.network.reader.buffer.size=1MB# ...
然后将配置同步分发到所有节点以后，重启所有节点的 Worker 进程即可生效。
Page Store 与 Block Store 之间的目录结构说明
在 Page Store 的数据目录下，采用了四级目录结构：
第一级子目录是默认的 LOCAL，不可更改；
第二级子目录表征该目录下的 Page Size。例如，图中的子目录 2097152 表示该目录下每个 Page 的大小都是 2MB；
第三级是一个哈希桶值，该值是使用每个 Block 目录名的哈希值与 ${goosefs.worker.page.store.local.store.file.buckets} 计算得到；
第四级子目录就是 Block 目录了，该目录下存放的都就是属于该 Block 的所有缓存 Page 页，该目录的命名规则为: paged_block_${blockId}。
注意：
在第二级子目录下，通常还会有一个 .TEMP 目录，该目录下会存放所有正在写入的 Block 数据。.TEMP 目录下每个 Block 目录的命名规则为 paged_block_${blockId}session{sessionId}。
关于 Page Store 与 Block Store 之间的互相切换
目前，在默认未开启短路读写的情况下，是允许通过更改配置的方式来自由切换存储类型，即修改配置项 goosefs.worker.block.store.type 为对应的存储类型，然后重启 Worker Server 即可生效。 Worker 将会根据对应的存储类型所指定的数据路径来加载和缓存数据。
在开启短路读的情况下，也可以通过上述方式修改生效，但是必须同时重启 Client 所在进程，否则可能会出现短路读写异常的问题。
PageStore 的配置参数
参数 | 默认值 | 描述 |
goosefs.worker.block.store.type | FILE | 指定 Worker 上的存储类型，可选项为 FILE 和 PAGE。 默认为 FILE，即传统的 Block 存储模式，指定 PAGE 则为 Page 存储模式。 |
goosefs.worker.page.store.page.size | 1MB | 指定每个 Page 页的大小。默认大小为 1MB，这里可以按需指定，例如 128KB 或 256KB 亦可。 |
goosefs.worker.page.store.dirs | /tmp/goosefs-cache | 指定 Page Store 的数据目录。例如： /data/goosefs-data/paged-block。 |
goosefs.worker.page.store.size | 512MB | 指定 Page Store 的数据目录的大小，默认为 512MB，如果超出了容量限制，则会触发 Page 粒度的淘汰。 |
goosefs.worker.cache.request.pending.timeout | 500ms | 用来优化高并发冷读场景下的缓存击穿问题的超时等待选项，默认是 500 毫秒。 如果在同一 Worker 节点上发生了缓存击穿的并发读取，则后到的请求会尝试等待 500ms，以便于直接从缓存中直接返回数据，而不是穿透到底层存储。 若等待超时，才会从底层存储读取并返回。 当该值设置为小于等于 0 的值时候，则相当于关闭了缓存击穿优化。 |
goosefs.worker.page.store.overhead | 0.1 | Page 存储空间的预留分位。默认值为 0.1，表示会预留百分之十的空间作为保留空间。达到水位以后，开始触发淘汰动作。 |
goosefs.worker.page.store.evictor.class | com.qcloud.cos.goosefs.client.file.cache.evictor.LRUCacheEvictor | Page 存储的淘汰算法，支持的选项为： com.qcloud.cos.goosefs.client.file.cache.evictor.LRUCacheEvictor； com.qcloud.cos.goosefs.client.file.cache.evictor.LFUCacheEvictor。 |
goosefs.worker.page.store.eviction.retries | 10 | 最大淘汰尝试次数，默认为 10 次。 |
goosefs.worker.page.store.evictor.lfu.logbase | 2.0 | 指定 LFU 淘汰算法的 LogBase。 |
goosefs.worker.page.store.local.store.file.buckets | 1000 | 存放 Paged Block 目录的 Hash 桶数目，默认为 1000。 |
关于分层存储的说明
GooseFS 在 Page Store 存储类型下，不支持分层存储，即只有默认的第一层存储介质可用。这样设计的原因是在于，离散的 Page 页在多层存储之间索引和流动的开销会很大，对 Worker 节点的资源占用和性能都有极大的影响。
文档反馈