我注意到，elasticsearch在晚上消耗了超过30GB的磁盘空间。相比之下，我要索引的所有日志的总大小仅为5 GB …嗯，甚至不是，实际上更像是2.5-3GB。是否有任何原因，有没有办法重新配置它？我正在运行ELK堆栈。
有许多原因导致Elasticsearch内部的数据比源数据大得多。一般而言，Logstash和Lucene都在努力为数据 添加 结构，而这些数据原本是相对非结构化的。这会带来一些开销。
如果您使用的是3 GB的源，而索引数据为30 GB，则这是源数据的大约10倍。这很大，但不一定是闻所未闻的。如果在该度量中包括副本的大小，则30 GB可能是完全合理的。根据我自己的经验和直觉，我可能期望相对于源数据在3-5倍的范围内，这取决于数据的类型以及您在Elasticsearch中使用的存储和分析设置。
尝试精简Elasticsearch索引时，可以尝试以下四种不同的设置。
_source
Elasticsearch保留每个传入文档的原始原始JSON的副本。如果您想重建索引的原始内容，或在搜索结果中突出显示匹配项，则很有用，但它肯定会加起来。您可能要创建一个索引模板，该模板会禁用_source索引映射中的字段。
禁用该_source字段可能是磁盘使用情况的最大改进。
文档：Elasticsearch _source字段
与_source字段类似但独立于字段，您可以控制是否按字段存储字段的值。非常简单，并且在“映射”文档中针对核心类型多次提及。
如果您希望索引很小，则只应在搜索响应中存储需要返回的最小字段。与与主要数据存储相关联的文档ID一样，它可能少之又少。
文档：核心类型的Elasticsearch映射
_all
有时，您想查找与给定术语匹配的文档，而您实际上并不在乎该术语出现在哪个字段中。在这种情况下，Elasticsearch有一个特殊的_all字段，该字段将文档中所有字段中的所有术语推入其中。
这很方便，但是如果您的搜索完全针对特定字段，并且您没有尝试松散地匹配索引中任何地方的任何内容，那么您可以不用使用该_all字段了。
文档：Elasticsearch _all字段
这又回到了Lucene的主题，即向其他非结构化数据中添加结构。您要搜索的任何字段都需要进行分析。这是将一堆非结构化文本分解为 标记， 然后分析每个标记以对其进行规范化或将其扩展为多种形式的过程。这些标记被插入字典中，并且术语和它们所出现的文档（和字段）之间的映射也得以维护。
这一切都需要空间，对于某些领域，您可能并不希望对其进行分析。跳过分析还可以在索引时节省一些CPU时间。某些类型的分析确实可以使您的总条款膨胀，例如使用具有自由设置的n- gram分析器将原始条款分解为许多较小的条款。
文档：分析和分析器简介
