一、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