关于_all
当索引一个文档的时候，Elasticsearch 取出所有字段的值拼接成一个大的字符串，作为 _all 字段进行索引。例如，当索引这个文档时：
{
"tweet": "However did I manage before Elasticsearch?",
"date": "2014-09-14",
"name": "Mary Jones",
"user_id": 1
}
这就好似增加了一个名叫 _all 的额外字段：
"However did I manage before Elasticsearch? 2014-09-14 Mary Jones 1"
关于match和term
match会对于查询字符串（querystring）进行分词，然后针对分词进行查询；
term则是查询全文精准查询。所谓精准就是必须要匹配，多了少了都不行
与之对应的是索引的mapping字段，如果字段设置为"index”属性设置为“not_analyzed”，则在保存的时候就会全文保存，不会进行分词，默认是“analyzed”，即进行分词；
这样的机制意味着，如果term对“analyzed”，可能因为索引存储的时候被分词而导致无法和term全字匹配匹配上。
PUT my_index
{
"mappings": {
"my_type": {
"properties": {
"full_text": {
"type": "string"
},
"exact_value": {
"type": "string",
"index": "not_analyzed"
}
}
}
}
} PUT my_index/my_type/1
{
"full_text": "Quick Foxes!",
"exact_value": "Quick Foxes!"
}
看看下面的查询：
GET my_index/my_type/_search
{
"query": {
"term": {
"exact_value": "Quick Foxes!"
}
}
}
exact是全字保存，保存的内容是["Quick Foxes!"]所以完美匹配。
下面的：
GET my_index/my_type/_search
{
"query": {
"term": {
"full_text": "Quick Foxes!"
}
}
}
则返回结果为空，因为full_test的保存模式分词，真是保存的是["Quick",“Foxes”]
关于过滤器（filter）和查询器（query)
过滤器回答的问题匹配不匹配，查询器回答问题是像不像，像多少；查询器因为要回答像多少的问题，所以存在一个打分的过程，在模糊查询的场景下，这个功能非常重要，比如你在亚马逊淘宝上面敲错了产品名称不会影响你的查出理想的东西。
但是查询器的这种容错是有代价的，性能因为评分而受到影响；filter则更像是传统的SQL查询语句。
参考
https://www.cnblogs.com/yjf512/p/4897294.html
https://elasticsearch.cn/question/2355