我注意到elasticsearch在晚上消耗了超过30GB的磁盘空间。相比之下，我想要索引的所有日志的总大小只有5 GB ......好吧，甚至不是真的，可能更像是2.5-3GB。这有什么理由，有没有办法重新配置它？我正在运行ELK堆栈。
答案 0 :(得分：12)
Elasticsearch内部数据远大于源数据的原因有很多。一般来说，Logstash和Lucene都在努力将结构添加到相对非结构化的数据中。这带来了一些开销。
如果您使用的是3 GB的源，并且索引数据为30 GB，那么这是源数据的10倍左右。这很重要，但不一定闻所未闻。如果您在该测量中包含副本的大小，那么30 GB可能是完全合理的。根据我自己的经验和直觉，我可能会期望相对于源数据的3-5倍范围内的某些内容，具体取决于数据类型以及您在Elasticsearch中使用的存储和分析设置。
以下是尝试缩小Elasticsearch索引时可以尝试的四种不同设置。
_source字段 Elasticsearch会保留每个传入文档的原始原始JSON的副本。如果您想要重建索引的原始内容，或者在搜索结果中匹配突出显示，它会很有用，但肯定会增加。您可能希望创建一个索引模板，用于禁用索引映射中的_source字段。
禁用_source字段可能是磁盘使用量的最大改进。
文档：Elasticsearch _source field
同样但与_source字段分开，您可以控制是否在每个字段的基础上存储字段的值。非常简单，在核心类型的Mapping文档中提到了几次。
如果您想要一个非常小的索引，那么您应该只存储您在搜索响应中返回的最小字段。这可能只是与主数据存储相关联的文档ID。
文档：Elasticsearch mappings for core types
_all字段有时你想要找到与给定术语匹配的文档，而你并不真正关心该术语出现在哪个领域。对于这种情况，Elasticsearch有一个特殊的_all字段，它将所有字段推入其中文档中所有字段的术语。
这很方便，但是如果您的搜索针对特定字段，并且您没有尝试松散地匹配索引中任何位置的任何内容，那么您可以放弃不使用_all字段
这是回到Lucene的主题，为您的非结构化数据添加结构。您打算搜索的任何字段都需要进行分析。这是将一小块非结构化文本分解为标记并分析每个标记以将其标准化或将其扩展为多种形式的过程。这些标记被插入到字典中，并且术语和它们出现的文档（和字段）之间的映射也会被保留。
这一切都需要空间，对于某些领域，您可能无需分析它们。跳过分析还可以在索引时节省一些CPU时间。某些类型的分析可以真正夸大你的总条款，比如使用带有自由设置的n-gram分析器，这会将你的原始术语分解为许多较小的术语。
文档：Introduction to Analysis and Analyzers
答案 1 :(得分：0)
正如先前的评论者详细解释的那样，索引到Elasticsearch后的日志数据的大小可能会增加，原因有很多。他链接到的博客文章现在已经死亡，因为我杀死了我的个人博客，但现在生活在elastic.co网站https://www.elastic.co/blog/elasticsearch-storage-the-true-story上。