Elasticsearch索引远大于它索引的日志的实际大小？

我注意到,弹性搜索过夜消耗了超过30GB的磁盘空间.相比之下,我想要索引的所有日志的总大小只有5 GB ......好吧,甚至不是真的,可能更像是2.5-3GB.这有什么理由,有没有办法重新配置它？我正在运行ELK堆栈.

Elasticsearch内部数据远大于源数据的原因有很多.一般来说,Logstash和Lucene都在努力为那些相对非结构化的数据添加结构.这带来了一些开销.

如果您使用的是3 GB的源并且索引数据为30 GB,那么这是源数据的10倍左右.这很重要,但不一定闻所未闻.如果您在该测量中包含副本的大小,那么30 GB可能是完全合理的.根据我自己的经验和直觉,我可能会期望相对于源数据的3-5x范围内的某些内容,具体取决于数据类型以及您在Elasticsearch中使用的存储和分析设置.

在尝试减少Elasticsearch索引时,您可以尝试以下四种不同的设置.

该_source场

Elasticsearch保留每个传入文档的原始原始JSON的副本.如果您想要重建索引的原始内容,或者在搜索结果中匹配突出显示,它会很有用,但肯定会增加.您可能希望创建一个索引模板,用于禁用_source索引映射中的字段.

禁用该_source字段可能是磁盘使用量的最大改进.

文档:Elasticsearch _source字段

个别存储的字段

同样但与_source字段分开,您可以控制是否在每个字段的基础上存储字段的值.非常简单,并在映射文档中提到了几次核心类型.

如果您想要一个非常小的索引,那么您应该只存储您在搜索响应中返回的最小字段.这可能只是与主数据存储相关联的文档ID.

文档:核心类型的Elasticsearch映射

该_all场

有时您希望找到与给定术语匹配的文档,并且您并不真正关心该术语出现在哪个字段中.对于这种情况,Elasticsearch有一个特殊_all字段,在其中推送文档中所有字段中的所有字词.

这很方便,但如果您的搜索针对特定字段,并且您不想在索引中的任何地方松散地匹配任何内容,那么您可以不使用该_all字段.

文档:Elasticsearch _all字段

分析一般

这又回到了Lucene的主题,为您的非结构化数据添加了结构.您打算搜索的任何字段都需要进行分析.这是将一小块非结构化文本分解为标记,分析每个标记以将其标准化或将其扩展为多种形式的过程.这些令牌被插入到字典中,并且还保持术语与它们出现的文档(和字段)之间的映射.

这一切都需要空间,对于某些领域,您可能无需分析它们.跳过分析还可以在索引时节省一些CPU时间.某些类型的分析可以真正夸大你的总条款,例如使用具有自由设置的n-gram分析器,这会将原始术语分解为许多较小的术语.

文档:分析和分析器简介

更多阅读

Peter Kim最近写了一篇关于这个主题的文章:硬件规模或"我真的需要多少台服务器？"