本文主要是介绍Elastic字段映射（_source,doc_value,fileddata,index,store），希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
Elastic字段映射（_source,doc_value,filed_data,index,store）
_source：
source 字段用于存储 post 到 ES 的原始 json 文档。为什么要存储原始文档呢？因为 ES 采用倒排索引对文本进行搜索，而倒排索引无法存储原始输入文本。一段文本交给ES后，首先会被分析器(analyzer)打散成单词，为了保证搜索的准确性，在打散的过程中，会去除文本中的标点符号，统一文本的大小写，甚至对于英文等主流语言，会把发生形式变化的单词恢复成原型或词根，然后再根据统一规整之后的单词建立倒排索引，经过如此一番处理，原文已经面目全非。因此需要有一个地方来存储原始的信息，以便在搜到这个文档时能够把原文返回给查询者。
相对于store,它只要建立一个文档索引，当需要对多个字段进行查询的时候，只需要一次io。
那么一定要存储原始文档吗？不一定！如果没有取出整个原始 json 结构体的需求，可以在 mapping 中关闭 source 字段或者只在 source 中存储部分字段（使用store）,关闭后能减少内存和数据大小，提高性能。 但是这样做有些负面影响：
- （1）不能获取到原文
- （2）无法reindex：如果存储了 source，当 index 发生损坏，或需要改变 mapping 结构时，由于存在原始数据，ES可以通过原始数据自动重建index，如果不存 source 则无法实现
- （3）无法在查询中使用script：因为 script 需要访问 source 中的字段
- 文档需要使用update或者update_by_query更新
- 文档高亮（有store也可以）
可以通过在查询的时候进行过滤
//查询
GET index/_search
{"_source": ["field"],"query" : {"match_all": {}}
}
//设置
{
"settings" : {"mappings" : {"_source": {"enable": true,"excludes": [],"includes": []}}}
}
doc_value
DocValue其实是Lucene在构建倒排索引时，会额外建立一个有序的正排索引（基于document => field value的映射列表）。
它是一个列式存储。不能用在text类型的字段。
因为倒排索引不能进行排序和聚合，因此如果字段需要这两个功能就可以开启它。
缺点：有额外的磁盘消耗
//查询
GET index/_search
{"doc_value": ["field"],"query" : {"match_all": {}}
}
//设置
{
"settings" : {"mappings" : {"properties": {"content": {"doc_value": true // 默认开启},}}}
}
fielddata
fielddata 也是用来进行聚合操作的，但是他是针对text的，算是对doc_value的一个补充。
fielddata 不是临时缓存。它是驻留内存里的数据结构，必须可以快速执行访问，而且构建它的代价十分高昂。如果每个请求都重载数据，性能会十分糟糕
在使用这个的过程中 ，应该好好思考两个问题“：
- 为什么要对text类型的字段进行聚合操作
- 如果你真想对这个字段进行聚合，为什么不将他设置为keyword类型，使用doc_value
index
Index：定义字段分词以及创建索引（只有建立索引，才能被检索）。缺点：会额外维护一个索引库
关闭后，字段不建立索引，不被检索，无法通过检索查询到该字段。反过来，有些业务要求某些字段不能被搜索，那么index属性设置为false即可。
store
store开启后
ES会对该字段单独存储倒排索引，每次根据ID检索的时候，会多走一次IO来从倒排索引取数据，以便于快速检索。
注意:如果想要对某个字段实现高亮功能，_source和store至少保留一个。
一般来说_source和store 只要开启一个就行。因为如果_source存在的话，他可以直接在_source检索出来。
store默认是关闭的，它开启的字段越多，索引库就越大，维护的成本就越高，检索的效率也就会会越差、
这篇关于Elastic字段映射（_source,doc_value,fileddata,index,store）的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
