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

本文涉及的产品
检索分析服务 Elasticsearch 版,2核4GB开发者规格 1个月
简介: 我们很高兴地宣布,在 Elasticsearch 7.10 中创建的索引将更小了。一味求大并非都是好事,我们的内部基准测试报告显示,空间占用降幅高达 10%。

 作者: Adrien Grand  Elasticsearch Tech Lead

   我们很高兴地宣布,在 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 编码结合起来,以便进一步压缩数据。

image.png

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



消解压缩之困的字典


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

image.png

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

image.png

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

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

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



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


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


相关实践学习
使用阿里云Elasticsearch体验信息检索加速
通过创建登录阿里云Elasticsearch集群,使用DataWorks将MySQL数据同步至Elasticsearch,体验多条件检索效果,简单展示数据同步和信息检索加速的过程和操作。
ElasticSearch 入门精讲
ElasticSearch是一个开源的、基于Lucene的、分布式、高扩展、高实时的搜索与数据分析引擎。根据DB-Engines的排名显示,Elasticsearch是最受欢迎的企业搜索引擎,其次是Apache Solr(也是基于Lucene)。 ElasticSearch的实现原理主要分为以下几个步骤: 用户将数据提交到Elastic Search 数据库中 通过分词控制器去将对应的语句分词,将其权重和分词结果一并存入数据 当用户搜索数据时候,再根据权重将结果排名、打分 将返回结果呈现给用户 Elasticsearch可以用于搜索各种文档。它提供可扩展的搜索,具有接近实时的搜索,并支持多租户。
相关文章
|
6月前
|
弹性计算 运维 监控
阿里云 Elasticsearch Serverless 全新发布,平均可省50%成本
阿里云 Elasticsearch Serverless 全新发布,平均可省50%成本,致力于为用户打造更低成本、弹性灵活、开放兼容、开箱即用的云上 Elasticsearch 使用体验。
877 0
|
24天前
|
存储 缓存 自然语言处理
【Elasticsearch专栏 04】深入探索:Elasticsearch倒排索引中的词条是如何存储和管理
倒排索引中,词条以有序方式存储在词典中,关联倒排列表,记录文档ID和位置信息。词条的添加涉及分词、添加到词典和更新倒排列表。删除涉及从词典和倒排列表中移除词条。查询时,快速定位词条,获取倒排列表以定位相关文档。整个过程涉及高效的数据结构和优化策略。
30 0
|
3月前
|
存储 SQL 监控
从 Elasticsearch 到 SelectDB,观测云实现日志存储与分析的 10 倍性价比提升
SelectDB 助力观测云完成日志数据存储和分析架构升级,实现整体性价比 10 倍提升,为日志存储和分析场景服务提供强大动力。
|
3月前
|
存储 缓存 监控
Elasticsearch elastic io 100%,但磁盘的iops和吞吐量没爆没啥原因吗?
Elasticsearch elastic io 100%,但磁盘的iops和吞吐量没爆没啥原因吗?
44 2
|
3月前
|
搜索推荐 索引
Elasticsearch elastic io 100%,但磁盘的iops和吞吐量没爆没啥原因吗?
Elasticsearch elastic io 100%,但磁盘的iops和吞吐量没爆没啥原因吗?
49 3
|
4月前
|
存储 弹性计算 运维
阿里云 Elasticsearch Severless 如何做到成本降低50%
阿里云 Elasticsearch Serverless 服务正式上线。全新产品形态,基于云原生 Serverless 技术,致力于为用户打造更低成本、弹性灵活、开放兼容、开箱即用的云上 Elasticsearch 使用体验。
|
5月前
|
存储 自然语言处理 监控
ElasticSearch第三讲:ES详解 - Elastic Stack生态和场景方案
ElasticSearch第三讲:ES详解 - Elastic Stack生态和场景方案
|
10月前
|
数据采集 数据可视化 搜索推荐
带你读《Elastic Stack 实战手册》之3:——3.1.1.从 Elasticsearch 到 Elastic Stack(上)
带你读《Elastic Stack 实战手册》之3:——3.1.1.从 Elasticsearch 到 Elastic Stack(上)
201 0
|
10月前
|
存储 安全 数据可视化
带你读《Elastic Stack 实战手册》之3:——3.1.1.从 Elasticsearch 到 Elastic Stack(中)
带你读《Elastic Stack 实战手册》之3:——3.1.1.从 Elasticsearch 到 Elastic Stack(中)
141 0
|
10月前
|
测试技术 Apache
带你读《Elastic Stack 实战手册》之3:——3.1.1.从 Elasticsearch 到 Elastic Stack(下)
带你读《Elastic Stack 实战手册》之3:——3.1.1.从 Elasticsearch 到 Elastic Stack(下)
139 0

相关产品

  • 检索分析服务 Elasticsearch版