ES概念区分

ES概念区分  source&store

（1）：_source默认是打开的，将原始文档以JSON的形式存储在_source字段中，在lucene中_source只是一个字段，即在一个字段中存储了一个文档中所有字段的值。_source是es层面的设置，相当于给lucene多加了一个字段用于存储整个原始文档的值。

（2）：字段中的store属性默认是false，即为不存储该字段；如果该字段的store属性设置为true，则在lucene中该字段的值被单独存储。

从以上可知，_source字段和字段属性store设置为true这两种情况都可以存储文档的字段值，如果同时都存储，岂不是重复存储了吗？那这两种情况有区别吗？
（1）：在_source设置为打开，并且所有字段的store属性都设置为false的情况下，只在 _source字段中存储原始文档；当搜索时默认返回_source中的完整文档；如果只想返回某几个字段，则可以通过fields或者_source指定需要返回的字段，此时，es会自动从_source中抽取指定要返回的字段值。在这种情况下，无论是返回完整的文档，还是通过设置只返回某几个字段的值，都只需要一次磁盘IO，因为完整的文档都在_source一个字段中存储。

（2）：在_source设置为关闭，并且所有字段的store都设置为true的情况下，_source字段中不再存储完整的原始文档了，文档的内容都以字段为单位，单独的被存储了。在这种情况下，查询结果中返回几个字段，就要进行几次磁盘IO，因为每个字段都是被单独存储的。

（3）：在_source设置为打开，并且某几个字段的属性store被设置为true的情况下，_source字段中存储了原始文档，且那几个字段又被单独的存储了一次；在这种情况下，如果想返回这几个字段中的某一个或某几个时，es不会再从_source中抽取字段值了，而是直接从单独存储的字段中加载。

结论：
（1）：即使文档中每个字段都设置成store=false：即不存储，es也把文档的原始内容在_source字段中存储了下来。

（2）：如果字段被设置成store=true：即存储，则相当于字段值被存储了两次；如果考虑磁盘IO的性能和内容抽取方面的事情，存储两次可能有好处，但是在其他情况下存两次就是多余。

doc_values&fielddata

搜索需要用到倒排索引，而排序和聚合则需要使用 "正排索引"

倒排索引的优势在于查找包含某个项的文档，而反过来确定哪些项在单个文档里并不高效

doc_values和fielddata就是用来给文档建立正排索引的。他俩一个很显著的区别是，前者的工作地盘主要在磁盘，而后者的工作地盘在内存。

维度doc_valuesfielddata创建时间index时创建使用时动态创建创建位置磁盘内存(jvm heap)优点不占用内存空间不占用磁盘空间缺点索引速度稍低文档很多时，动态创建开销比较大，而且占内存

虽然速度稍慢，doc_values的优势还是非常明显的。一个很显著的点就是他不会随着文档的增多引起OOM问题。正如前面说的，doc_values在磁盘创建排序和聚合所需的正排索引。这样我们就避免了在生产环境给ES设置一个很大的HEAP_SIZE，也使得JVM的GC更加高效，这个又为其它的 *** 作带来了间接的好处。

而且，随着ES版本的升级，对于doc_values的优化越来越好，索引的速度已经很接近fielddata了，而且我们知道硬盘的访问速度也是越来越快（比如SSD）。所以 doc_values 现在可以满足大部分场景，也是ES官方重点维护的对象。

所以我想说的是，doc values相比field data还是有很多优势的。所以 ES2.x 之后，支持聚合的字段属性默认都使用doc_values，而不是fielddata。

对于非text字段类型，doc_values默认情况下是打开的；doc values 支持大部分字段类型，但是text 字段类型不支持（因为analyzed）

Painless脚本使用ctx、doc、_source区别

• ingest 场景，使用：ctx.XXX；

• update / update / update_by_query / reindex 场景，使用：ctx._source；

• search和聚合场景，使用：doc['value']。