一、ES的数据存储结构：

ES底层使用 Lucene 存储数据，Lucene 的索引包含以下部分：

A Lucene index is made of several components: an inverted index, a bkd tree, a column store (doc values), a document store (stored fields) and term vectors, and these components can communicate thanks to these doc ids.

其中：

inverted index：倒排索引。
bkd tree: Block k-d tree，用于在高维空间内做索引，如地理坐标的索引。
column store：doc values，列式存储，批量读取连续的数据以提高排序和聚合的效率。
document store：Store Fileds，行式存储文档，用于控制 doc 原始数据的存储，其中占比最大的是 source 字段。
term vectors：用于存储各个词在文档中出现的位置等信息。

二、ES常见配置项说明：

在很多场合下，我们并不需要存储上述全部信息，因此可以通过设置 mappings 里面的属性来控制哪些字段是我们需要存储的、哪些是不需要存储的。而 ES 的 mapping 中有很多设置选项，这些选项如果设置不当，有的可能浪费存储空间，有的可能导致无法使用 Aggregation，有的可能导致不能检索。下面就简单介绍下 ES 中常见的存储与检索的 mapping 配置项：

配置项	作用	注意事项	默认值
_all	提供跨字段全文检索	（1）会占用额外空间，把 mapping 中的所有字段通过空格拼接起来做索引，在跨字段全文检索才需要打开； （2）在 v6.0+已被弃用，v7.0会正式移除，可以使用 [copy_to] 来自定义组合字段	关闭
_source	存储 post 提交到ES的原始 json 内容	（1）会占用很多存储空间。数据压缩存储，读取会有额外解压开销。（2）不需要读取原始字段内容可以考虑关闭，但关闭后无法 reindex	开启
store	是否单独存储该字段	（1）会占用额外存储空间，与 source 独立，同时开启 store 和 source 则会将该字段原始内容保存两份，不同字段单独存储，不同字段的数据在磁盘上不连续，若读取多个字段则需要查询多次，如需读取多个字段，需权衡比较 source 与 store 效率	关闭
doc_values	支持排序、聚合	会占用额外存储空间，与 source 独立，同时开启 doc_values 和 _source 则会将该字段原始内容保存两份。doc_values 数据在磁盘上采用列式存储，关闭后无法使用排序和聚合	开启
index	是否加入倒排索引	关闭后无法对其进行搜索，但字段仍会存储到 _source 和 doc_values，字段可以被排序和聚合	开启
enabled	是否对该字段进行处理	关闭后，只在 _source中存储，类似 index 与 doc_values 的总开关	开启

在ES的 mapping 设置里，all，source 是 mapping 的元数据字段（Meta-Fields），store、doc_values、enabled、index 是 mapping 参数。

1、_all：

all 字段的作用是提供跨字段查询的支持，把 mapping 中的所有字段通过空格拼接起来做索引。ES在查询的过程中，需要指定在哪一个field里面查询。

{“name”: “smith”,“email”: "John@example.com"
}

用户在查询时，想查询叫做 John 的人，但不知道 John 出现在 name 字段中还是在 email 字段中，由于ES是为每一个字段单独建立索引，所以用户需要以 John 为关键词发起两次查询，分别查询name字段和email字段。

如果开启了 all 字段，则ES会在索引过程中创建一个虚拟的字段 all，其值为文档中各个字段拼接起来所组成的一个很长的字符串（例如上面的例子，all 字段的内容为字符串 “smith John@example.com”）。随后，该字段将被分词打散，与其他字段一样被收入倒排索引中。由于 all 字段包含了所有字段的信息，因此可以实现跨字段的查询，用户不用关心要查询的关键词在哪个字段中。

由于该字段的内容都来自 source 字段，因此默认情况下，该字段的内容并不会被保存，可以通过设置 store 属性来强制保存 all 字段。开启 all 字段，会带来额外的CPU开销和存储，如果没有使用到，可以关闭 all 字段。

2、_source：

source 字段用于存储 post 到 ES 的原始 json 文档。为什么要存储原始文档呢？因为 ES 采用倒排索引对文本进行搜索，而倒排索引无法存储原始输入文本。一段文本交给ES后，首先会被分析器(analyzer)打散成单词，为了保证搜索的准确性，在打散的过程中，会去除文本中的标点符号，统一文本的大小写，甚至对于英文等主流语言，会把发生形式变化的单词恢复成原型或词根，然后再根据统一规整之后的单词建立倒排索引，经过如此一番处理，原文已经面目全非。因此需要有一个地方来存储原始的信息，以便在搜到这个文档时能够把原文返回给查询者。

那么一定要存储原始文档吗？不一定！如果没有取出整个原始 json 结构体的需求，可以在 mapping 中关闭 source 字段或者只在 source 中存储部分字段（使用store）。 但是这样做有些负面影响：

（1）不能获取到原文
（2）无法reindex：如果存储了 source，当 index 发生损坏，或需要改变 mapping 结构时，由于存在原始数据，ES可以通过原始数据自动重建index，如果不存 source 则无法实现
（3）无法在查询中使用script：因为 script 需要访问 source 中的字段
3、store：

store 决定一个字段是否要被单独存储。大家可能会有疑问，source 里面不是已经存储了原始的文档嘛，为什么还需要一个额外的 store 属性呢？原因如下：

（1）如果禁用了 source 保存，可以通过指定 store 属性来单独保存某个或某几个字段，而不是将整个输入文档保存到 source 中。

（2）如果 source 中有长度很长的文本（如一篇文章）和较短的文本（如文章标题），当只需要取出标题时，如果使用 source 字段，ES需要读取整个 source 字段，然后返回其中的 title，由此会引来额外的IO开销，降低效率。此时可以选择将 title 的 store 设置为true，在 source 字段外单独存储一份。读取时不必在读取整 source 字段了。但是需要注意，应该避免使用 store 查询多个字段，因为 store 的存储在磁盘上不连续，ES在读取不同的 store 字段时，每个字段的读取均需要在磁盘上进行查询操作，而使用 source 字段可以一次性连续读取多个字段。

4、doc_values：

倒排索引可以提供全文检索能力，但是无法提供对排序和数据聚合的支持。doc_values 本质上是一个序列化的列式存储结构，适用于聚合（aggregations）、排序（Sorting）、脚本（scripts access to field）等操作。默认情况下，ES几乎会为所有类型的字段存储doc_value，但是 text 或 text_annotated 等可分词字段不支持 doc values 。如果不需要对某个字段进行排序或者聚合，则可以关闭该字段的doc_value存储。

5、index：

控制倒排索引，用于标识指定字段是否需要被索引。默认情况下是开启的，如果关闭了 index，则该字段的内容不会被 analyze 分词，也不会存入倒排索引，即意味着该字段无法被搜索。

6、enabled：

这是一个 index 和 doc_value 的总开关，如果 enabled 设置为false，则这个字段将会仅存在于 source 中，其对应的 index 和 doc_value 都不会被创建。这意味着，该字段将不可以被搜索、排序或者聚合，但可以通过 source 获取其原始值。

7、term_vector：

在对文本进行 analyze 的过程中，可以保留有关分词结果的相关信息，包括单词列表、单词之间的先后顺序、单词在原文中的位置等信息。查询结果返回的高亮信息就可以利用其中的数据来返回。默认情况下，term_vector是关闭的，如有需要（如加速highlight结果）可以开启该字段的存储。

三、doc_values 详细说明：

1、doc_values 的作用：

基于 lucene 的 solr 和 es 都是使用倒排索引实现快速检索的，也就是通过建立 “搜索关键词 ==>文档ID列表” 的关系映射实现快速检索，但是倒排索引也是有缺陷的，比如我们需要字段值做一些排序、分组、聚合操作，lucene 内部会遍历提取所有出现在文档集合的排序字段，然后再次构建一个最终的排好序的文档集合list，这个步骤的过程全部维持在内存中操作，而且如果排序数据量巨大的话，非常容易就造成solr内存溢出和性能缓慢。

doc values 就是在构建倒排索引时，会对开启 doc values 的字段额外构建一个有序的 "document文档 ==> field value“ 的列式存储映射，从而实现对指定字段进行排序和聚合时对内存的依赖，提升该过程的性能。默认情况下每个字段的 doc values 都是开启的，当然 doc values 也会耗费一定的磁盘空间。

另外 doc values 保存在操作系统的磁盘中，当 doc values 大于节点的可用内存，ES 可以从操作系统页缓存中加载或弹出，从而避免发生 JVM 内存溢出的异常，docValues 远小于节点的可用内存，操作系统自然将所有Doc Values存于内存中（堆外内存），有助于快速访问。

2、doc_values 与 source 的区别？使用 docvalue_fields 检索指定的字段？

post 提交到 ES 的原始 Json 文档都存储在 source 字段中，默认情况下，每次搜索的命中结果都包含文档 source，即使仅请求少量字段，也必须加载并解析整个 source 对象，而 source 每次使用时都必须加载和解析，所以使用 source 非常慢。为避免该问题，当我们只需要返回相当少的支持 doc_values 的字段时，可以使用 docvalue_fields 参数获取选定字段的值。

doc values 存储与 _source 相同的值，但在磁盘上基于列的结构中进行了优化，以进行排序和汇总。由于每个字段都是单独存储的，因此 Elasticsearch 仅读取请求的字段值，并且可以避免加载整个文档 _source。通过 docvalue_fields 可以从建好的列式存储结果中直接返回字段值，毕竟 source 是从一大片物理磁盘去，理论上从 doc values 处拿这个字段值会比 source 要快一点，页面抖动少一点。

3、如何在 ES 中使用 doc values？

doc values 通过牺牲一定的磁盘空间带来的好处主要有两个：

节省内存
提升排序，分组等聚合操作的性能
那么我们如何使用 doc values 呢？

（1）我们首先关注如何激活 doc values，只要开启 doc values 后，排序，分组，聚合的时候会自动使用 doc values 提速。在 ElasticSearch 中，doc values 默认是开启的，比较简单暴力，我们也可以酌情关闭一些不需要使用 doc values 的字段，以节省磁盘空间，只需要设置 doc_values 为 false 就可以了，如下：

“session_id”:{“type”:“string”,“index”:“not_analyzed”,“doc_values”:false}
（2）使用 docvalue_fields 的检索指定的字段：

GET my-index-000001/_search
{"query": {"match": {"user.id": "kimchy"}},"docvalue_fields": ["user.id","http.response.*", {"field": "date","format": "epoch_millis" }]
}

ES搜索指定字段的不同方式，详情请见官网：https://www.elastic.co/guide/en/elasticsearch/reference/7.x/search-fields.html#search-fields
————————————————
版权声明：本文为CSDN博主「张维鹏」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/a745233700/article/details/117915118