背景
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