Page 94 - 《软件学报》2021年第5期

1318 Journal of Software 软件学报 Vol.32, No.5, May 2021

对表格数据的分析能够证实两点结论.
(1) 索引结构设计简捷易于理解、磁盘空间管理上的真实性.基于对两级索引结构的理解,能够分析出索
引文件中各级索引的详细组成.以 Application-3 为例,索引文件为 224KB 大小,即文件中存在 1 个一级
Header 索引以及 6 个 Segment 二级索引(8byte×4K+8byte×4K×6=224KB).进一步分析,一级索引中仅
有 6 个 Entry 空间被占据使用了,二级索引中最多有 24K 个 Entry 被占据,即最多存了 24K 个 LogView.
上述的推论过程能够体现出两级索引结构设计简捷易理解的特性,反推过程也能证实设计方案在磁
盘空间管理上的有效性,即,在需要的时候才开辟新的二级索引空间.
(2) LogView 特征.单条字节量差距很大,Application-4 的索引文件、数据文件大小分别为 64KB,1.1MB,
而 Application-5 的文件大小分别为 96KB,143KB.虽然 Application-4 的索引文件比 Application-5 的
更小,但是数据文件却更大.这能够说明 Application-4 中的 LogView 数量较少,但是它里面的 LogView
的平均字节量却相对很大.这也证实了在第 1.3 节中指出的关于 LogView 特征的真实性.
5 讨 论

本节主要针对当前日志存储方案中存在的限制与不足进行说明,并对后 3 点不足提出了可行的解决方案.
(1) 关于性能测试
在第 4 节中,通过线上的真实运行数据,从读写性能、内存使用情况两方面来说明了本文存储方案的效果.
由于 LogView 日志的数据特点,文中没有对相关存储方案进行测试实验并对比读写性能,仅说明了当前方案的
各项性能,但该部分中的真实数据已经能够体现整体的读写性能也满足在第 2 节所提出的几点要求.
衡量写入性能、查询性能的线上数据实际上是同时发生的,理论上,查询的操作对写入性能存在一定的影
响,即,在第 4.1.1 节中的运行数据存在一定的误差.但是在该时间段内,存储系统整体的写入 TPS 为 6.88M,而整
体的查询 QPS 仅为 168,所以实际上查询操作对存储集群的影响微乎其微,可以忽略.
(2) 存在单点故障问题
如图 2 所示:每台机器上报日志的对象机器是通过路由信息指定的,每条 LogView 日志值仅存于日志存储
集群的单个机器上.所以当某台机器出现宕机后,所有存在该机器上的 LogView 日志都无法访问到也无法进行
日志上传,即,当前存储系统的架构存在单点故障问题.在前面提到,可以使用 HDFS 技术搭建分布式文件系统,
但是会增加系统整体的磁盘存储压力,并且查询效率会相对降低.而实际上,少量的日志数据丢失是系统可以容
忍的,所以考虑引入心跳检测的方式,在机器宕机后及时重启服务或者临时更改上报的路由信息.
(3) 地址空间可能会不够
在二级索引中,每个 Entry 具有 8byte 的空间,用于存储内存块的首地址和块内偏移量.而前 40bit 存储首地
址时,能够表示的最大地址空间为 1TB.如果在当前小时内的日志数据量很大,对应数据文件的大小超过了 1TB
的大小,那么 40bit 的空间就不够用了.
目前考虑两种解决方案.
① 划分小文件,超过 1TB 的文件划分成多个小文件,并额外存储小文件的隶属关于用于日志的查询;
② 扩大 40bit 的空间.
第 2 种方式在实现上会比第 1 种更便捷也更易理解,但是会额外造成内存的开销,且文件大于 1TB 的情况
非常少见.
(4) LogView 出现 id 重复
在第 3.5 节中提到,id 值的重复是由进程中断、机器宕机等导致的,而出现重复后则是直接更新为最新的值,
这种方法会导致部分原日志数据的丢失.理论上可以缩小 3s 的持久化周期,但是文件的 IO 操作会对系统整体性
能有影响.此处提出了新的解决方法,能够进一步降低 id 重复的频率.
考虑将 index 值的更新操作放到索引文件中,如图 11 所示,在二级 Segment 索引中设置 4K+1 个 Entry 空间,
最后一个用于存储 index 值.在每次内存块更新到数据文件之后,需要更新索引文件时,同时更新最后一个