背景

TsFileResource 会随着数据写入不断生成，当 TsFileResource 中的时间索引粒度较细，单个 TsFileResource 可能包含数十万设备的时间索引条目，大小可到几十M，在有限内存管理海量设备时，将 TsFileResource 全部驻留内存有 OOM 风险。

此外，在系统重启时，所有的TsFileResource都需要load到内存中一遍。

因此，TsFileResource 不能全部驻留在内存中，需要设计以下内容：

结构设计：

• TsFileResource 和 TsFile 的对应关系？（1对1，1对多）
• TsFileResource 的时间索引粒度？

缓存机制设计：

• 将哪些 TsFileResource 放在内存里？
• 内存中的 TsFileResource 何时踢出？
• 查询时如何将未缓存在内存的 TsFileResource 加载进内存？

前提要求

现有的TsFileResource中有过多的冗余字段，有些字段只对于未封口的TsFileResource起作用

将 TsFileResource 抽为接口，两个实现类，ClosedTsFileResource，UnclosedTsFileResource

下面的方案只考虑对于ClosedTsFileResource的缓存管理，默认内存中保留所有的UnclosedTsFileResource

方案1 & 方案2

总体目标

• 引入一个全局的TsFileResourceManager，管理TsFileResource，将最近的 TsFileResource 缓存在内存，踢出老文件

当前TsFileResource的层级关系

         存储组 → 虚拟存储组 → 分区号 → List<TsFileResource> 

方案1

每关闭一个 TsFileResource 时，计算其内存，内存达到设置的阈值后，将最不活跃的分区的整个 List<TsFileResource> 清空

当需要一个分区的文件时，到磁盘上 listFiles，将该分区加载进来

优点：以分区作为缓存管理的粒度，缓存管理的开销小，分区被驱逐后，内存中不需要保留过多信息，只需要把原有的Map<PartitionID, List<TsFileResource>>中所驱逐分区对应的value置成null即可，若该分区再次被使用，只需根据所处存储组名、分区id得到分区文件夹路径，从文件夹中获得所有tsfile resource文件，加载进内存即可

缺点：必须开启分区，当分区数为1时，无法奏效

方案2

主要思想：假设使用 FILE_TIME_INDEX 没有内存问题。根据内存动态切换 FILE_TIME_INDEX 和 DEVICE_TIME_INDEX。

踢出一个 TsFileResource 的操作为：将 TsFileResource 中的 ITimeIndex 改为 FILE_TIME_INDEX，重新加载一个TsFileResource的操作为将 TsFileResource 中的 ITimeIndex 改为 DEVICE_TIME_INDEX

注意，当前的FILE_TIME_INDEX的实现有点问题，不应该存Set<String> devices

优点：不开时间分区依旧能够奏效

缺点：以单个TsFileResource作为缓存管理的粒度，缓存的开销比方案1要大

方案1 & 方案2有个共同的优点，可以复用MTree那边缓存的实现逻辑

方案3

保持现有的 TIME_INDEX 不变，每个存储组保留固定个 TsFileResource，当总内存超过阈值，就将 TsFileResource 合并。可以应用多种合并策略。

例：

File1

root.sg.d1.s1, 1, 10

root.sg.d1.s2, 1, 10

File2

root.sg.d2.s1, 1, 10

root.sg.d1.s2, 11, 20

合并后：

File1, File2

root.sg.d1.s1, 1, 10

root.sg.d2.s1, 1, 10

root.sg.d1.s2, 1, 20