温馨提示:文本由机器自动转译,部分词句存在误差,以视频为准
00:00
传统的日志存储方式已不堪重负,高昂的存储成本、漫长的查询等待成为企业发展的沉重负担。幸运的是,Elas such8.17为我们带来了LUX DB日志存储的全新解决方案。Lu DB通过多种手段帮我们优化日志索引的存储,平均成本降幅能达到63%。首先是合成源优化,通过去除不必要的航存,有效减少索引大小,如system CS日志索引大小从三点四零千兆锐减至二点一零千兆,减少了38.24%,对于各种日志索引的平均减达到了40%。通过应用GSTD压缩算法快速无损压缩,让数据体积大幅缩小,就像system报日志索引升用级STD后。
01:01
减少了11.13%,索引排序优化是另一个优化手段,当来自相同实体的日志,比如按主机名、时间戳排序时,可显著提高存储效率,测试中心层or日志索引减少31.75%,而快编解码器则可对不同字段施展魔法,对数值和日期字段采用高效编码方式,关键字字段通过邮程编码让system slo日志中相关字段索引大小减少40.23%,高开D压缩通过优化ID字典,让system slo日志的ID倒排索引从343.95兆减少到66.64兆,减少了80.63%,而在分段合并之后,删除sequence number信息也能节省大量空间。如在5点。
02:01
三四千兆的索引中,C no字短,原本占950兆,删除后可节省10%的整个索引空间。让我们再来看一个具体的例子,原始数据为三十二千兆的http log数在为其用lockd历史索引的大小为十六点一七千兆,在拉斯TB持续迭代的过程后,一路降到了七点八五千兆,降幅达到了60%。通过对比两个索引的字段的磁盘占用信心,我们发现提升是全面的。而在8.17版本之后,我们还将计划持续提升lock DB的效能,以帮助用户降本增效。还等什么呢?快来使用吧。
我来说两句