对齐时间序列内存存储结构开发总结
Table of Contents |
---|
一、问题背景
四维图新有这样的测试场景,模拟车联网100万台车辆数据的批量写入,每台车包含27列数据共2700万个测点,每个测点每秒采集1条新纪录。共写入1小时的数据,每个测点写入3600个点。写入性能要求在3节点1副本的分布式场景下达到100万行每秒。
在现有存储模型下,我们测试了单机的写入性能,为19万行每秒。即使使用3节点1副本的情况写入性能较单机提升约2倍,也无法达到要求。因此,对现有写入性能提升瓶颈的分析是不可或缺的。
在四维图新的用户场景中,存在每台车27个时间序列的时间戳完全相同的情况。而在现有的存储模型里,每个时间序列均为时间戳与测量值相互对应的形式。在四维的场景下,现有模型会重复存储27列相同的时间戳。
可以预见对时间戳对齐的序列存储进行优化,减少对相同时间戳重复写入,是一个写入性能提升的关键点。在本场景中可减少26次重复时间戳的写入,优化后最多提升1/2的写入速度。
某用户有这样的测试场景,模拟100万设备,每个设备包含27列测点,共2700万个测点,每个测点每秒采集1条数据,每个设备27个测点数据采集的时间戳完全相同。
在现有的存储模型里,每个时间序列均会存储一列时间戳和一列值。由于设备内各序列时间戳相同,因此 27 列时间戳完全相同。因此,在内存中对于可按时间对齐的序列仅存储一列时间戳即可,即对齐的时间序列。在本场景中即可减少26次重复时间戳的写入,优化后写入数据量可减少至 28/54。
同样,原有非对齐序列,需要对各个序列按时间单独排序。排序也仅需要对唯一的时间列进行排序,排序的工作量可降低至1/27。同样,在理论上,排序时间也可节省26列的时间,排序速度最多可提升1/2。
二、方案设计
针对上述背景,优化的主要思路为对多个时间戳相同的时间序列只存储一个时间戳列。为此分别设计了如下几种方案。
方案1: 行式存储(Object)
- 将一行对齐的时间序列(Vector)作为一个measurement,写入memtable时一行Aligned Timeseries为一个时间戳加一个TsPrimitiveType类的数组。
- 内存控制模块在写入前根据Vector每个子项的数据类型检查内存增量,进行内存统计
- PrimitiveArrayManager增加Vector类的数组统计,类似目前TEXT类型的管理,只统计统计 TsPrimitiveType数组 的引用
- 新增VectorTVList,结构为一个long型时间戳数组和一个Object类型数组
...
- 写入Memtable时将放入VectorTVList中,VectorTVList在扩容时向PrimitiveArrayManager申请。
- VectorTVList的其他接口参考BinaryTVList;
- Flush时,按时间戳进行排序,再按行遍历时间戳和每个value,将这一行数据传给TsFile的ChunkWriter进行encoding。
方案2: 列式存储(Primitive Array)
- 将对齐时间序列的内存结构作为一组PrimitiveArray的合集(时间列、索引列和多个值列);
- 内存控制模块在写入前根据Vector每个子项的数据类型检查是否需要向PrimitiveArrayManager申请新增Array,进行内存统计;
- 新增VectorTVList,结构为一个long型时间Array和多个其他类型Array,同时每列维护bitmap用来记录空值, 和一个int 类型数组记录各个值列的rowIndex。bitmap默认为空指针,当客户端传入空值(insertRecord)或者传入代表空值的bitmap(insertTablet)时再创建出来;
- 写入Memtable时,将insertPlan里的值放入VectorTVList中,VectorTVList在扩容时需向PrimitiveArrayManager申请需要的Array类型;
- VectorTVList排序时只需要排时间列和rowIndex列;
- Flush时,按时间戳进行排序时间戳列和rowIndex列,之后的遍历方式为先找到一个时间戳,和对应的rowIndex,再根据rowIndex和bitMap找到各个值列对应的真实值和是否为null,将这一行数据传给TsFile的ChunkWriter进行encoding。Flush时,按时间戳进行排序时间戳列和rowIndex列,之后的遍历方式为先找到一个时间戳,和对应的rowIndex,再根据rowIndex和bitMap找到各个值列对应的真实值和是否为null,将这一行数据传给TsFile的ChunkWriter进行encoding。
方案3: 行式存储(bytes版)
- 将一行Vector作为一个measurement,写入memtable时,一行Vector为一个时间戳和多个值序列化成的一个byte数组,同时使用bitmap记录每一行的空值情况。
- 内存控制模块在写入前根据Vector每个子项的数据类型检查内存增量,进行内存统计
- 新增VectorTVList,结构为一个long型时间戳数组和一个bytes数组,每行维护一个bitmap记录空值
- PrimitiveArrayManager增加Vector类的数组统计,类似目前TEXT类型管理,只统计 byte数组的引用;
- 写入Memtable后放入VectorTVList中,VectorTVList在扩容时向PrimitiveArrayManager申请;
- VectorTVList的其他接口参考BinaryTVList
- Flush时,按时间戳进行排序,再按行遍历时间戳并将对应的bytes值反序列化成具体的值,将这一行数据传给TsFile的ChunkWriter进行encoding。
三、方案评估
方案1行式存储优点 :
- 对null友好,无需维护bitmap记录空值
- 排序逻辑与现有其他类型完全相同,排序时会实际更新值列
...
- 需要将数据装箱,内存利用率较低。以int类型为例,需要先装箱为TsPrimitiveType,再装箱为TsPrimitiveType数组,内存占用为实际内存占用的3倍,会导致一个Chunk太小,影响写入性能。
- 不能复用ArrayPool管理内存
方案2行式存储优点:方案2列式存储优点:
- 节省对象装箱,节省内存占用
- 可复用现有的PrimitiveArrayPool管理数组
- 排序时可通过排rowIndex,节省排序开销
...
- 需要编码解码来读取数据,效率低下
- 不能复用ArrayPool管理内存
- 对空值不友好
- 对TEXT类型的数据不友好,需要找到bytes 中对应的Offset和length来读取中对应的offset和length来读取
四、实验验证
1.目标
比较行式和列式存储在排序和遍历功能上的时间开销,以及存储的性能开销
...
模拟实际应用场景,用户按行写入的场景较多,乱序数据较多。
查询场景
用户可能查Vector内的1列、30列、100列等等。用户可能查对齐时间序列内的1列、30列、100列等等。
测试重点关注:内存占用、write 速度、sort速度、遍历速度、查询
...
在行数为10,000,列数为3,200,数据类型均为int的情况,内存测试结果如下:
内存占用 | |
行式存储 | 600 MB |
列式存储 | 120 MB |
行式存储(bytes版本) | 168 MB |
结论:由于方案一存Object的行式存储占用空间过大(是列式的5倍),所以直接排除掉了,下面只测试列式和行式(byte数组)方式。
...
乱序比例:10%
写入方式:列式按列写入,行式按行写入
write | sort | query | |
列式 | 157ms | 7ms | 1,300ms |
行式(bytes版) | 652ms | 9ms | 1,304ms |
结论:方案二列式存储与方案三行式存储(bytes版)在排序和查询过程的耗时基本相同。但在写入过程中,方案三行式存储为方案二耗时的4倍。因此,方案二的性能更符合要求。
五、最终结论
经综合比较,由于方案一内存浪费过大,方案三写入耗时较高、性能较差,最终选择方案二列式存储方案作为Vector数据类型内存存储结构。开发完成后,测试得到的写入性能,单机性能达到45万行每秒, 在3节点1副本的分布式场景下为109.5万行每秒,达到了100万行每秒的性能预期。