# 使用DWS磁盘缓存（disk cache）功能提升查询性能最佳实践
#### 场景介绍
在云计算时代，随着存算分离架构技术日趋成熟，越来越多的企业选择将大量用户数据存放在云端存储中，这导致了频繁的OBS云端存储读写需求。在这种架构下，数据访问速度逐渐成为了性能瓶颈，如何在这样的背景下，提升云上数据处理速度，成为了一个亟待解决的问题。
DWS通过利用本地硬盘上的缓存来加速数据访问，并采用了一种先进的**多队列 LRU（Least Recently Used，最近最少使用）** 策略来高效管理缓存空间。针对跨VW（**[Virtual Warehouse，弹性计算组](https://support.huaweicloud.com/bestpractice-dws/dws_05_0115.html#ZH-CN_TOPIC_0000002518184071__section422944215516)**）的应用场景，DWS 还提供了缓存预热功能，以便在弹性VW建立时，能够迅速加载特定数据（如表或分区）到缓存中，从而提升查询性能。
**本功能仅9.1.0.x及以上集群版本支持，其中TTL队列仅9.1.1.x及以上集群版本支持。**
#### 了解多队列LRU
- **LRU**
  LRU（Least Recently Used，最近最少使用）通过维护一个数据访问队列来管理缓存。当数据被访问时，该数据会被移动到队列的前端。新加入缓存的数据同样会被置于队列前端，以防止其过早被淘汰。**当缓存空间达到上限时，队列尾部的数据将优先被移除，即最近最少使用的数据优先被淘汰**。
  DWS通过引入LRU-2Q算法，优化了LRU的缓存污染问题，确保了**不会因为访问大量历史数据而导致** **核心业务的热数据被冲刷出缓存**。
  **LRU2Q共包含3个队列** ，分别是**A1in/A1out/Am**，其中数据首次命中时会进入到A1in队列中，后续如果A1in队列满了（可调整GUC参数，通常默认值为整个队列大小的0.25倍），会淘汰到A1out（实际并不存储数据到缓存，只是A1in队列淘汰的延长记忆），等A1out队列中的block被命中时，才会插入到Am队列。在Am队列中的数据，是最热的数据。
  
- **TTL (Time-To-Live)**
  **TTL** **策略确保新导入的数据在缓存中保留一段时间不被淘汰。** 在这段时间内，数据具有最高优先级，且所有TTL数据之间地位平等，不会因为某些数据即将过期而被提前淘汰。当TTL缓存空间不足时，会尝试抢占LRU队列的空间，以确保TTL数据能够被写入，TTL队列最大可使用的空间由GUC参数**disk_cache_ttl_max_ratio**控制，默认值是0.5，即整个缓存空间的一半。当TTL队列的缓存空间到达上限后，如果仍然有新的数据要进入TTL队列，此时会触发TTL队列自身的LRU淘汰，被淘汰的数据将进入到LRU空间中。
  应用场景：TTL策略特别适用于希望在本地持久化的小规模数据表。对于常驻表，可以设置较长的TTL值来保护其数据；对于实时表，可以根据热数据的活跃时间设定相应的TTL值。
  
- **多队列**
  海量大数据场景下，随着业务和数据量的不断增长，数据存储与消耗的资源也日益增长。根据业务系统中用户对不同时期数据的不同使用需求，对膨胀的数据本身进行"冷热"分级管理，可以有效提升本地缓存的使用效率。
  例如，在网络流量分析系统中，用户可能对最近一个月内安全事件和网络访问情况感兴趣，而很少关注几个月前的数据。针对这样的一些场景，可以将数据按照时间分为：热数据、冷数据。
  冷热数据主要从数据访问频率、更新频率进行划分。
  - **Hot（热数据）**：访问、更新频率较高，未来被调用的概率较高的数据，对访问的响应时间要求很高的数据。
  
  - **Cold（冷数据）**：不允许更新或更新频率比较低，访问频率比较低，对访问的响应时间要求不高的数据。
  
  
  **对于热数据，应该尽可能地将其留在本地缓存中**；对于冷数据，既应该享受到本地缓存带来的空间局部性优势（即将当前访问数据及相邻数据都缓存下来，减少后续OBS读的次数），又应该具备比热数据更容易被淘汰的性质。最终决定给冷数据单独提供一个简化的、固定 1GB 的磁盘空间，这部分数据由A0队列进行管理，该部分缓存也遵循LRU策略。
  DWS采用基于LRU的多队列策略，根据TTL属性及冷热属性将数据分为三类，分别置于**TTL队列、LRU - 2Q队列、A0 队列**中。设置了TTL属性的热数据被放置到TTL队列，没有设置TTL属性的热数据被放置到LRU - 2Q队列，冷数据都放置到A0队列中。
  在数据读取和写入过程中，DWS会选择填充和读取的队列，以最大化缓存利用率。具体机制如下：
  表1DWS数据读取和写入机制 
  | 操作         | 未命中时填充的队列           | 写入数据时填充的队列          |
  |:---|:---|:---|
  | 导入(开启缓存双写) | TTL / LRU - 2Q / A0 | TTL / LRU - 2Q / A0 |
  | 查询         | TTL / LRU - 2Q / A0 | N/A                 |
  | 预热         | N/A                 | TTL / LRU - 2Q / A0 |
     
  以查询操作为例，在读取数据时如果未命中，先判断数据是否是冷数据，如果是冷数据会直接进入 A0 缓存，如果是热数据则需要再判断当前表是否设置了 TTL 参数，如果设置了参数并且当前数据还没有过期，则数据会进入到 TTL 缓存，否则会进入 LRU - 2Q 缓存。
  
- **淘汰**
  A0队列可使用的缓存空间固定为1GB， TTL 队列和LRU - 2Q队列共同使用由GUC参数**disk_cache_max_size** 设置的缓存空间，初始状态时缓存空间都给LRU - 2Q使用，在后续访问到设置TTL属性的数据或者TTL中有大量数据过期时，会动态调整TTL队列与LRU - 2Q队列的比例关系，以充分利用缓存空间，TTL所使用缓存空间的最大比例不超过**disk_cache_ttl_max_ratio**。
  - **TTL队列的淘汰**
    当有新的数据进入TTL队列时，会将部分已经过期的数据淘汰至LRU - 2Q队列。
    后台线程会定期清理TTL中已过期的数据，并淘汰至LRU - 2Q队列。
    当TTL空间使用达到上限，且没有过期的数据时，会触发自身的LRU淘汰策略，被淘汰出去的数据会进入LRU - 2Q队列。
    当用户删除**设置了过期时间**的表数据时，后台线程会定期清理TTL中无效的数据。
    
  
  - **LRU - 2Q队列的淘汰**
    当有新的数据插入且当前LRU空间使用达到上限，会触发自身的LRU淘汰策略，被淘汰出去的数据会被清除缓存。
    当TTL队列空间不足，但未到达上限，会抢占LRU - 2Q队列的空间。如果LRU - 2Q的空间已满，也会触发自身的LRU淘汰。
    当用户删除**设置了过期时间**的表数据时，后台线程会定期清理LRU - 2Q中无效的数据。
    
   
 
#### 多盘缓存
云上环境，对不同云盘的访问，其流量会走不同的网卡，因此不同云盘的带宽是可以叠加的。在有多块云盘（EVS）的情况下，DWS支持设置多块盘作为缓存的路径，尽可能将cache文件分散在不同云盘上以提升缓存访问的性能。为了提升集群正常时主DN的性能并充分利用节点上的磁盘空间，目前会默认使用主备两块硬盘作为当前节点上主DN缓存介质，通过查询以下参数查看相关信息：
通过**disk_cache_base_paths**（该参数不支持用户自行配置，默认即可，如需设置请联系技术支持）参数查看和增减缓存硬盘路径，举例某个节点上的目录配置，实例名为h10dn1：
主DN多盘缓存路径默认如下：
- 路径1：/DWS/data1/h10dn1/primary0/disk_cache
- 路径2：/DWS/data2/h9dn1/primary0/disk_cache
备DN多盘缓存路径默认如下：
- 路径：/DWS/data2/h9dn1/secondary/disk_cache
备机的多盘缓存路径与当前节点上主DN的缓存路径2在同一块盘上，因此限制备机升主后的磁盘缓存空间最大为1GB，性能对比切换前会有较大劣化，需要尽快修复集群至均衡状态。
#### 缓存预热
在存算分离模式下，DWS支持搭建跨VW集群，各VW间共享数据但不共享缓存。新的VW创建时，其缓存为空，可能影响查询性能。为此，DWS提供缓存预热功能，允许用户从远端存储主动拉取数据至本地缓存。该功能支持以下两种模式：
- **表数据预热** ：预热指定表 A 的数据。
  ```
  /* 将表A的数据预热至A1in队列中 */
  EXPLAIN warmup SELECT * FROM A;
   /* 将表A的数据预热至Am队列中 */
  EXPLAIN warmup hot SELECT * FROM A;
  ```
  
- **分区数据预热** ：预热指定表 A 的分区 p1 的数据。
  ```
  /* 将表A p1分区的数据预热至A1in队列中 */
  EXPLAIN warmup SELECT * FROM A partition(p1); 
  /* 将表A p1分区的数据预热至Am队列中 */
  EXPLAIN warmup hot SELECT * FROM A partition(p1);
  ```
  
 
**使用示例：**
![](https://support.huaweicloud.com/bestpractice-dws/figure/zh-cn_image_0000002499504342.png "点击放大")
**warmup信息解读**：
- Read Cache Size : 从磁盘缓存中读取的数据大小。
- Write Cache Size : 从OBS读到本地缓存的数据大小。
- Avg Write Cache time : OBS请求的平均执行时间。
#### 查看缓存数据
**查看磁盘空间及命中率：**
用户可通过查看disk cache视图[pgxc_disk_cache_all_stats](https://support.huaweicloud.com/devg-dws/dws_04_1234.html)查看disk cache当前缓存状态，使用方式为：
```
SELECT * FROM pgxc_disk_cache_all_stats;
```
图1pgxc_disk_cache_all_stats   
![](https://support.huaweicloud.com/bestpractice-dws/figure/zh-cn_image_0000002499358660.png "点击放大")
其中各个字段含义如下：
表2PGXC_DISK_CACHE_ALL_STATS字段 
| 名称              | 类型           | 描述                                                         |
|:---|:---|:---|
| node_name       | text         | 节点名称。                                                      |
| total_read      | bigint       | 访问disk cache的总次数。                                          |
| local_read      | bigint       | disk cache访问本地磁盘的总次数。                                      |
| remote_read     | bigint       | disk cache访问远端存储的总次数。                                      |
| hit_rate        | numeric(5,2) | disk cache的命中率。                                            |
| cache_size      | bigint       | disk cache保存的数据总大小，单位kbytes。                               |
| fill_rate       | numeric(5,2) | disk cache的填充率。                                            |
| ttl_rate        | numeric(5,2) | TTL空间占整个disk cache空间的比率。该字段仅9.1.1.100及以上集群版本支持。            |
| temp_file_size  | bigint       | 临时/冷缓存文件的总大小(kbytes)。                                      |
| a1in_size       | bigint       | disk cache中a1in队列保存的数据的总大小，单位kbytes。                       |
| a1out_size      | bigint       | disk cache中a1out队列保存的数据的总大小，单位kbytes。                      |
| am_size         | bigint       | disk cache中am队列保存的数据的总大小，单位kbytes。                         |
| ttl_size        | bigint       | disk cache中ttl队列保存的数据的总大小，单位kbytes。该字段仅9.1.1.100及以上集群版本支持。 |
| a1in_fill_rate  | numeric(5,2) | disk cache中a1in队列的填充率。                                     |
| a1out_fill_rate | numeric(5,2) | disk cache中a1out队列的填充率。                                    |
| am_fill_rate    | numeric(5,2) | disk cache中am队列的填充率。                                       |
| ttl_fill_rate   | numeric(5,2) | disk cache中ttl队列的填充率。该字段仅9.1.1.100及以上集群版本支持。               |
| fd              | integer      | disk cache正在使用的文件描述符数量。                                    |
| pin_block_count | bigint       | disk cache中被pin住block的数量。该字段仅9.1.0.100及以上集群版本支持。           |
   
**查看特定语句的OBS读写统计信息**：
对于3.0表，由于数据的实际存储位置位于OBS，DWS增强了对OBS读写请求统计信息的监控能力，用于辅助定位特定SQL慢问题。
可以通过TopSQL视图以及EXPLAIN PERFORMANCE语句查看特定语句的OBS读写统计信息。
```
/* TopSQL视图 */
SELECT * FROM pgxc_wlm_session_info;    ---注意在连接postgres数据库下执行
 /* EXPLAIN PERFORMANCE */
 EXPLAIN PERFORMANCE + SQL语句
```
图2OBS读写信息   
![](https://support.huaweicloud.com/bestpractice-dws/figure/zh-cn_image_0000002531200125.png "点击放大")
其中新增字段含义如下：
表3OBS读写信息 
| 新增字段名称                      | 字段含义                               |
|:---|:---|
| vfs_scan_bytes              | OBS虚拟文件系统接收到上层请求的扫描的字节数(bytes)。    |
| vfs_remote_read_bytes       | OBS虚拟文件系统实际从OBS读取的字节数(bytes)。      |
| preload_submit_time         | 预读流程提交IO请求的总时间(microseconds)。      |
| preload_wait_time           | 预读流程等待IO请求的总时间(microseconds)。      |
| preload_wait_count          | 预读流程等待IO请求的总次数(count)。             |
| disk_cache_load_time        | 读取diskcache的总时间(microseconds)。     |
| disk_cache_conflict_count   | 读取diskcache中block产生哈希冲突的次数(count)。 |
| disk_cache_error_count      | 读取diskcache失败的次数(count)。           |
| disk_cache_error_code       | 读取diskcache失败的错误码。                 |
| obs_io_req_avg_rtt          | OBS IO请求的平均RTT(microseconds)。      |
| obs_io_req_avg_latency      | OBS IO请求的平均延迟(microseconds)。       |
| obs_io_req_latency_gt_1s    | OBS IO请求延迟超过1s的数量(count)。          |
| obs_io_req_latency_gt_10s   | OBS IO请求延迟超过10s的数量(count)。         |
| obs_io_req_count            | OBS IO请求的总数量(count)。               |
| obs_io_req_retry_count      | OBS IO请求重试的总次数(count)。             |
| obs_io_req_rate_limit_count | OBS IO请求被流控的总次数(count)。            |
   
#### 打开磁盘缓存功能
当前云上集群的**磁盘缓存默认是打开的**，即对所有v3表的访问都会使用到磁盘缓存。可以通过以下方式检查当前集群的磁盘缓存是否打开。以下内容仅供参考，无需用户单独配置，如需配置请联系技术支持。
1. 在DN上执行以下查询命令：
   ```
   SHOW enable_aio_scheduler; 
   SHOW obs_worker_pool_size;
   ```
   确保enable_aio_scheduler=on，obs_worker_pool_size \>=4。
   
2. CN上执行以下查询命令：
   ```
   SHOW enable_disk_cache
   ```
   确保enable_disk_cache=on。
   
上述两点必须同时满足。
#### 指定表级缓存策略
当前disk cache支持的缓存策略有以下四种：
- **HPN(HOT PARTITION NUMBER)**
  cache policy选项可以在执行CREATE TABLE或者ALTER TABLE语句时设置成HPN : N，⽤户需要提供⼀个数字N(N \>= -1600 \&\& N \<= 1600)，之后获取表中的数据，更晚创建的N个分区中的数据会被热缓存，其余分区会被冷缓存。当N等于0时，所有分区中的数据都会被冷缓存。HPN只对V3表中的range分区表和list分区表⽣效。
  ```
  CREATE TABLE IF NOT EXISTS lineitem
  (
   L_ORDERKEY BIGINT NOT NULL
   , L_PARTKEY BIGINT NOT NULL
   , L_SUPPKEY BIGINT NOT NULL
   , L_LINENUMBER BIGINT NOT NULL
   , L_QUANTITY DECIMAL(15,2) NOT NULL
   , L_EXTENDEDPRICE DECIMAL(15,2) NOT NULL
   , L_DISCOUNT DECIMAL(15,2) NOT NULL
   , L_TAX DECIMAL(15,2) NOT NULL
   , L_RETURNFLAG CHAR(1) NOT NULL
   , L_LINESTATUS CHAR(1) NOT NULL
   , L_SHIPDATE DATE NOT NULL
   , L_COMMITDATE DATE NOT NULL
   , L_RECEIPTDATE DATE NOT NULL
   , L_SHIPINSTRUCT CHAR(25) NOT NULL
   , L_SHIPMODE CHAR(10) NOT NULL
   , L_COMMENT VARCHAR(44) NOT NULL
  ) with (
   orientation = column,
   colversion = 3.0,
   cache_policy = 'HPN : 3'
  )
  TABLESPACE cu_obs_tbs
  DISTRIBUTE BY HASH(L_ORDERKEY)
  PARTITION BY RANGE(L_SHIPDATE)
  (
  PARTITION L_SHIPDATE_4 VALUES LESS THAN('1993-01-01 00:00:00'), -- 冷缓存
  PARTITION L_SHIPDATE_5 VALUES LESS THAN('1994-01-01 00:00:00'), -- 冷缓存
  PARTITION L_SHIPDATE_3 VALUES LESS THAN('1995-01-01 00:00:00'), -- 冷缓存
  PARTITION L_SHIPDATE_1 VALUES LESS THAN('1996-01-01 00:00:00'), -- 冷缓存
  PARTITION L_SHIPDATE_2 VALUES LESS THAN('1997-01-01 00:00:00'), -- 热缓存
  PARTITION L_SHIPDATE_7 VALUES LESS THAN('1998-01-01 00:00:00'), -- 热缓存
  PARTITION L_SHIPDATE_6 VALUES LESS THAN('1999-01-01 00:00:00')  -- 热缓存
  );
  ```
  
  
- **HPL(HOT PARTITION LIST)**
  cache policy选项可以在执⾏CREATE TABLE或者ALTER TABLE语句时设置成HPL : , , ...，⽤户需要提供意图指定成热分区的分区名，之后获取表中的数据，热分区中的数据会被热缓存，⽽其余分区中的数据则会被冷缓存。HPL只对V3表中的range分区表和list分区表⽣效。
  ```
  CREATE TABLE IF NOT EXISTS nation
  (
   N_NATIONKEY INT NOT NULL,
   N_NAME CHAR(25) NOT NULL,
   N_REGIONKEY INT NOT NULL,
   N_COMMENT VARCHAR(152)
  ) WITH (
   orientation = column,
   colversion = 3.0,
   cache_policy = 'HPL : ASIA, AMERICA, REST'
  )
  TABLESPACE cu_obs_tbs
  DISTRIBUTE BY ROUNDROBIN
  PARTITION BY LIST(N_NAME)
  (
  PARTITION ASIA VALUES ('INDIA', 'INDONESIA', 'JAPAN'), -- 热缓存
  PARTITION EUROPE VALUES ('FRANCE', 'GERMANY', 'UNITED KINGDOM'), -- 冷缓存
  PARTITION AFRICA VALUES ('ALGERIA', 'ETHIOPIA', 'KENYA'), -- 冷缓存
  PARTITION AMERICA VALUES ('ARGENTINA', 'BRAZIL', 'CANADA'), -- 热缓存
  PARTITION REST VALUES (DEFAULT) -- 热缓存
  );
  ```
  
- **NONE**
  cache policy选项可以在执⾏CREATE TABLE或者ALTER TABLE语句时设置成NONE，之后获取表中的数据，所有数据都会被冷缓存。
  ```
  CREATE TABLE IF NOT EXISTS partsupp
  (
   PS_PARTKEY BIGINT NOT NULL,
   PS_SUPPKEY BIGINT NOT NULL,
   PS_AVAILQTY BIGINT NOT NULL,
   PS_SUPPLYCOST DECIMAL(15,2) NOT NULL,
   PS_COMMENT VARCHAR(199) NOT NULL
  )
  WITH (
   orientation = column,
   colversion = 3.0,
   cache_policy = 'NONE'
  )
  TABLESPACE cu_obs_tbs
  DISTRIBUTE BY HASH(PS_PARTKEY);  -- 冷缓存
  ```
  
- **ALL**
  cache policy选项可以在执⾏CREATE TABLE或者ALTER TABLE语句时设置成ALL，之后获取表中的数据，所有数据都会被热缓存。
  ```
  CREATE TABLE IF NOT EXISTS orders
  (
   O_ORDERKEY BIGINT NOT NULL,
   O_CUSTKEY BIGINT NOT NULL,
   O_ORDERSTATUS CHAR(1) NOT NULL,
   O_TOTALPRICE DECIMAL(15,2) NOT NULL,
   O_ORDERDATE DATE NOT NULL,
   O_ORDERPRIORITY CHAR(15) NOT NULL,
   O_CLERK CHAR(15) NOT NULL,
   O_SHIPPRIORITY BIGINT NOT NULL,
   O_COMMENT VARCHAR(79) NOT NULL
  )
  WITH (
   orientation = column,
   colversion = 3.0,
   cache_policy = 'ALL'
  )
  DISTRIBUTE BY ROUNDROBIN;  -- 热缓存
  ```
  
  
 
#### 设置TTL策略
在建表时，设置相应的表级参数[disk_cache_ttl](https://support.huaweicloud.com/sqlreference-911-dws/dws_06_0177.html)，即可将该表的数据使用TTL策略进行缓存。disk_cache_ttl表示，新导入的数据期望在缓存中保留的时间，参数的类型为interval，最小值为"1 second"、最大值为 "100 years"。
```
CREATE TABLE IF NOT EXISTS ProductDimension
(
    ProductID INT,
    ProductName VARCHAR(100),
    Category VARCHAR(50),
    Price DECIMAL(10, 2),
    Description TEXT
)
WITH (
 orientation = column,
 colversion = 3.0,
 disk_cache_ttl = '1 day'
)
DISTRIBUTE BY ROUNDROBIN;  -- 热缓存
```
上表中，所有新导入的数据将在缓存中被保留 1天。系统当前支持修改表的 TTL 时间，用户可以根据实际需求将 TTL 的时间延长或减短。
```
ALTER TABLE ProductDimension SET (disk_cache_ttl = '1000 seconds');
```
![](https://support.huaweicloud.com/bestpractice-dws/public_sys-resources/caution_3.0-zh-cn.png)
- 修改后的 TTL 值不会对已经在缓存中的数据生效，仅对后续进入缓存的数据有效。
- 如果在建表时没有设置 TTL，用户同样可以通过执行ALTER语句来修改表的TTL属性。
 
#### TTL设置典型场景
- 维度表，数据量较小、变动不大，但是**访问频繁，可以设置较长的TTL时间** ，例如1年，避免查询大表数据时被替换出缓存，以确保其数据在一年内都能被快速访问。
  客户新建维度表设置disk_cache_ttl为1年：
  ```
  CREATE TABLE dimension_table(a int, b text) with (orientation = column, COLVERSION = 3.0, disk_cache_ttl = '1 year');
  ```
  已有维度表通过alter设置disk_cache_ttl：
  如果不确定表数据导入的时间，可以把disk_cache_ttl设置为10年
  ```
  ALTER TABLE dimension_table SET (disk_cache_ttl = '10 years');
  ```
  也可以设置为1年后，对维度表做VACUUM FULL，更新数据的导入时间。
  ```
  ALTER TABLE dimension_table set (disk_cache_ttl = '1 years'); 
  VACUUM FULL dimension_table;
  ```
  
- **非频繁更新实时表** ，主要做数据导入与查询业务，可以根据客户业务设置合理的TTL时间。比如客户业务会频繁访问最近半天的数据，则可以设置TTL时间为0.5天。
  ```
  ALTER TABLE dimension_table set (disk_cache_ttl = '0.5 day');
  ```
  
- 频繁更新实时表，UPSERT业务比较频繁，可以根据需要做UPSERT的时间范围给表增加TTL时间，提升UPSERT操作的性能。设置过期时间时也根据客户具体的业务确定，如果主要对近两天导入的数据进行UPSERT，可将过期时间设置为2天。
  ```
  ALTER TABLE dimension_table set (disk_cache_ttl = '2 days');
  ```
  
 
#### 常见问题
1. **为什么我通过du、ls命令看到的disk cache目录占用的空间远大于我实际的数据量** ？（用户无法执行du、ls命令，仅技术支持人员可操作）
   disk cache的磁盘占用空间代表的是历史上的最高水位，和当前实际缓存的数据量并没有关系，假设导入了100G的数据，之后进行了UPSERT等业务，数据量变成了200G，然后之后进行了VACUUM，数据量变成了100G，那么disk cache的磁盘占用空间仍然会保持在最高水位200G，但是disk cache内部的实际缓存数据量会是100G。失效数据需要将整个disk cache用满后触发LRU淘汰策略后才能清理。
   
2. **disk cache是否会自动淘汰？为什么我的磁盘水位一直维持在配置的最高点，不下降** ？
   会。目前策略是达到磁盘使用上限（参数可控制，默认主备盘总空间的50%）、或当前磁盘使用率达到80%才会开始淘汰。但淘汰不会实际删除数据，只是将缓存的磁盘位置标记为空，后面的新缓存写入时会覆盖老缓存。所以即使发生淘汰，磁盘占用空间也不会下降，不会影响实际使用。
   
3. **为什么我执行DROP表操作后，OBS也显示表文件已删除，但是我的disk cache实际存储的数据量没有下降？**
   DROP 表数据不会进行disk cache缓存的删除，已经不存在的表的缓存会随着时间的推移，通过disk cache的内部LRU逻辑淘汰（删除），不影响实际使用。
   
4. **为什么我各个节点之间的缓存占用差异很大？**
   各个节点之间的节点缓存占用是无法保证在相邻水位的，这是单机缓存天然的限制，只要对查询延迟没有影响就行。占用差异受很多因素影响：
   - 不同实例加入集群的时间先后。
   
   - 不同vw的表数量差异。
   
   - 表数据的分布方式，以及业务实际访问的数据，可能某个业务访问的数据都在一个节点上。
   
   - 不同节点vacuum full的时间差异，vacuum full会导致该表在缓存中占用的空间double，需要随着时间的推移，通过 disk cache 的内部 LRU 逻辑淘汰无需缓存。