我仅使用kibana搜索ElasticSearch，并且我有几个只能接受几个值的字段（最坏的情况，服务器名，30个不同的值）。
我确实了解分析对像这样的更大，更复杂的字段执行的操作，但是对于那些简单的小字段，我却无法理解分析/未分析字段的优点/缺点。
那么，对于“有限的一组值”字段（例如，服务器名：server [0-9] *，没有特殊字符可以打破），使用analyd和not_analyzed有什么好处？我会在基巴纳语中丢失哪种搜索类型？我会获得任何搜索速度或磁盘空间吗？
在其中之一进行测试时，我看到该字段的.raw版本现在为空，但kibana仍将该字段标记为已分析，因此我发现测试没有定论。
如果您需要进一步说明，我将尝试保持简单，让我知道，我将详细说明。
“已分析”字段将使用您为映射中的特定表定义的分析器来创建令牌。如果您使用默认分析器（当您指的是不带特殊字符的内容时，让我们说server [1-9]），则使用默认分析器（数字小写单词经纪人（这实际上不是它的名字，它实际上就是这个名字））是要标记化：
this -> HelloWorld123 into -> token1:helloworld123 OR this -> Hello World 123 into -> token1:hello && token2:world && token3:123
在这种情况下，如果您进行搜索：HeL10，它将变为->“ hello”，并且它将与该文档匹配，因为这里有令牌“ hello”。
在not_analized字段的情况下，它根本不应用任何标记器，您的标记是您的关键字，因此被这样说：
this -> Hello World 123 into -> token1:(Hello World 123)
如果您在该字段中搜索“ hello world 123”
不会匹配，因为它是“区分大小写的”（尽管您仍然可以使用通配符（Hello *），让我们在另一时间解决该问题）。
简而言之：
对要搜索的字段使用“已分析”字段，并希望elasticsearch对它们进行评分。示例：包含单词“ jobs”的标题。查询：“ title：jobs”。
doc1 : title:developer jobs in montreal doc2 : title:java coder jobs in vancuver doc3 : title:unix designer jobs in toronto doc4 : title:database manager vacancies in montreal
这将检索title1 title2 title3。
在这种情况下，您需要“已分析”字段。
如果您事先知道该字段上将包含哪种数据，并且要精确查询所需的内容，则需要“ not_analyzed”。
例：
从server123获取所有日志。
查询：“ server：server123”。
doc1 :server:server123,log:randomstring,date:01-jan doc2 :server:server986,log:randomstring,date:01-jan doc3 :server:server777,log:randomstring,date:01-jan doc4 :server:server666,log:randomstring,date:01-jan doc5 :server:server123,log:randomstring,date:02-jan
仅来自server1和server5的结果。
好吧，我希望你明白了。正如我所说的，保持简单是您需要的。
分析->磁盘上有更多空间（如果分析字段很大，则更多）。分析->更多时间进行索引。分析->更好地匹配文档。
not_analyzed->减少磁盘空间。not_analyzed->更少的索引时间。not_analyzed->字段完全匹配或使用通配符。
问候，
