使用 match_only_text 在日志数据集上节省 10% 的磁盘空间

2021年8月5日   |   by mebius

Elasticsearch 7.14 引入了 match_only_text,这是一种新的字段类型,可在日志记录用例中直接替代文本字段类型,磁盘占用空间更少,从而降低成本。

Elasticsearch 对日志分析很有吸引力,因为它能够为日志消息建立索引。想要计算过去 24 小时内有多少日志消息包含 access denied?由于其索引结构,Elasticsearch 可以在几毫秒内为你提供答案——但索引结构需要 CPU 时间来构建并且需要磁盘空间。你可以通过不对 message 字段编制索引来节省此 CPU 和磁盘空间,但是你也将失去以交互方式查询日志数据的能力。

为了减少磁盘空间需求,match_only_text 只索引 text 字段索引的信息的子集。这会带来以下缺点:

  • 相关性分数计算为匹配项的数量。这对于日志用例通常无关紧要,因为文档是按降序时间戳而不是按相关性分数排序的。
  • 不支持 span queries。 match_only_text 字段也支持 text 字段支持的所有其他类型的查询。
  • Phrase 和 intervals queries 的运行速度比 text 字段慢,但仍比线性扫描快得多。其他类型的查询与 text 字段的运行速度一样快,甚至略快。

我们使用这种新字段类型运行了各种基准测试,并观察到包含应用程序日志的索引大小平均减少了 10%。这是我们最近几个月引入的第二次显着的索引大小缩减——在 7.10 中,我们通过改进存储字段压缩,再次将索引大小缩减了约 10%。

从 7.14 开始,使用 Elastic Agent 索引的应用程序日志将使用 match_only_text 而不是 text 作为应用程序日志的消息字段,我们计划从 7.15 开始将tgcode此更改推广到我们的集成中。要从这些空间节省中受益,你只需升级到新版本的 Elastic Stack。

它是如何在底层工作的?

match_only_text 是一种新的字段类型,它修剪 text 字段计算和索引的所有内容,这些内容对日志分析并不重要:

  • 长度归一化因子
  • 词频
  • 位置

长度归一化因子和词频仅用于计算分数,因此删除它们很容易,因为相关性评分通常对记录用例无用,因为事件按降序排序而不是按相关性排序。

位置更有趣,因tgcode为 text 字段类型使用它们来运行位置查询,例如 phrase queries 或 intervals queries。那么 match_only_text 如何运行短语查询呢?这种新的字段类型借鉴了 runtime fields 的想法。为了运行短语查询,它将从文档的 _source 加载你的字段的值,以检查术语是否实际出现在连续位置。但它仅在严格需要验证文档是否匹配时才这样做。例如,如果你的查询是 log.level: warn AND message:”node left”tgcode 并且你在 @timestamp 字段上有一个范围过滤器,则 Elasticsearch 将仅加载匹配所有必需子句以及短语查询。因此,在这种情况下,它只会加载以下文档的 _source:

  • 匹配 @timestamp 上的范围过滤器,
  • 匹配 log.level: warn,
  • 并在其 message 字段中包含 node 和 left 。

因此,虽然 match_only_text 在短语和间隔查询上的执行速度比 text 慢,但它仍然比线性扫描执行得好得多。

结论

我们鼓励你在现有部署中试用它,或者在 Elastic Cloud 上免费试用 Elasticsearch Service,它始终具有最新版本的 Elasticsearch。 我们期待听到你的反馈,所以请在 discussion forums 告诉我们你的看法。

参考:

【1】https://www.elastic.co/blog/save-10-percent-disk-space-on-your-logging-datasets-with-match-only-text

文章来源于互联网:使用 match_only_text 在日志数据集上节省 10% 的磁盘空间

相关推荐: Elasticsearch:使用 user agent 处理器来丰富数据

user_agent 处理器从浏览器随其 Web 请求发送的用户代理字符串中提取详细信息。 默认情况下,此处理器在 user_agent 字段下添加此信息。我们知道,发出 Web 请求的浏览器使用 user agent 字符串标识自己。在这个字符串中,这些用户…

Tags: