工程

在 Elasticsearch 7.10 中通过提高存储效率节省空间和成本

我们很高兴地宣布,在 Elasticsearch 7.10 中创建的索引将更小了。一味求大并非都是好事,我们的内部基准测试报告显示,空间占用降幅高达 10%。 

对于小型用例来说,这个数字可能看起来不算大,但对于处理 PB 量级数据(并需要为之支付云存储费用)的团队来说,这无疑是一笔非常可观的费用。特别是,对于我们的 Elastic 可观测性Elastic 安全解决方案所创建的索引,由于其中保存的数据具有重复性,因此节省效果会最明显。

我们下面先看看这项改进的工作原理,然后再探索一下让节省变为现实的 Apache Lucene 8.7 更新

当前存储的字段是如何压缩的

存储的字段是索引的一部分,用于存储文档的 _id 及其 _source。现在,存储的字段会被拆分成独立压缩的块。

为什么我们要拆分成数据块?数据块有助于保持对数据的快速随机访问。如果您要从存储的字段中检索字节序列,只需解压缩包含此字节序列中一个或多个字节的块即可。反之,如果您一次性压缩了所有数据,那么您会别无选择,只能在读取时解压缩所有数据,即使只需要其中的一个字节也要这样做。

Elasticsearch 提供了两种压缩选项:index.codec: default,指示 Elasticsearch 使用经 LZ4 压缩的 16kB 块;index.codec: best_compression,指示 Elasticsearch 使用经 DEFLATE 压缩的 60kB 块。

这两种压缩算法的一个重要组成部分就是字符串去重。每当在流中找到先前出现过的字符串时,便会将该字符串替换为对先前出现的那个字符串的引用。实际上,这是 LZ4 唯一做的事情,而 DEFLATE 会将字符串去重与 Huffman 编码结合起来,以便进一步压缩数据。

在对可观测性用例所产生的索引空间效率进行调查后,我们注意到增加块大小会显著提高压缩比。遗憾的是,增加块大小不是没有成本的,因为它们需要在检索时解压缩更多数据,这可能会降低 _search 的性能。

消解压缩之困的字典

通过字典既可以获得增大块大小的益处,又不会牺牲检索效率。具体方案是为压缩算法提供一个数据字典,该字典也可用于字符串去重。如果要压缩的数据流和字典之间有很多重复字符串,那么您可能最终会得到更好的压缩比。您要做的只是在解压时提供完全相同的字典,以便能够解压缩数据。

从 7.10 版开始,Elasticsearch 使用了更大的数据块,这些数据块本身被拆分为一个字典和 10 个使用该字典进行压缩的子块。

检索子块中包含的文档时,需要使用这个字典解压缩字典和包含文档的子块。

index.codec: default 现在使用经 LZ4 压缩的 4kB 字典和 60kB 的子块,而 index.codec: best_compression 使用经 DEFLATE 压缩的 8kB 字典和 48kB 的子块。默认编解码器增加的块大小可能会让您感到意外,因为上面提到过,更大的块大小会增加检索时间。 

但是,我们的基准测试表明,从 16kB 增加到 60kB 可以显著提高压缩比,而对检索时间的影响却很小。因为我们的测试显示,大多数用户不会注意到任何形式的速度下降,所以我们决定使用更大的块。

这个更新什么时候最有益?

可观测性(数据日志、指标和跟踪)和安全数据(终端数据、日志)的一个特殊性在于,生成的文档包含有关所观测内容的重要元数据,并且这些元数据在各个文档之间的变化不大。即使您正在监测许多主机或终端,其中的许多系统通常也会有共同的属性(如它们的操作系统)。这就使得这些文档具有高度可压缩性,使用字典将有助于移除更多重复的字符串,因为操作系统将不再是每 60kB 重复一次(假设是 best_compression),而是每 8+10*48=488kB 重复一次。

结论

默认情况下,7.10 版中创建的所有新索引都将利用这项效率改进。您现有的任何索引都会在下次合并时自动更新,以使用这项改进,尽管这可能只会影响到您的热索引。 

我们鼓励您在现有的部署中尝试一下,或者在 Elastic Cloud 上轻松免费试用 Elasticsearch Service(始终会提供最新版的 Elasticsearch)。我们期待听到您的反馈,请前往讨论区告知我们您的想法。