elastic search 原理介绍

Elasticsearch 原理与实现

文档字段

1 字段索引

默认情况下，只有text类型的字段会保存文档ID、词频、词序以外，其余类型字段均只保存文档ID。用户可以在映射字段时通过index_option参数来设置，它的可选值为 docs、freqs、positions、offsets，编入索引l的信息依次增加，具体含义如下:

docs：只有文档ID会被编入索引;
freqs：文档ID、词频会被编入索引;
positions：文档ID、词频和词序会被编入索引;
offsets：文档ID、词频、词序和偏移量都会被编入索引。

由此也可以看出，尽管在默认情况下所有的字段都会被索引，但是这些字段的原始值是不会被编入索引中的。这意味着用户可以通过某一字段的词项检索到文档，但并不能直接取到这个字段的原始值。因为字段的索引最多只包含上述四项内容，并不包含字段原始值。

2 字段存储

字段原始值 _source

索引提供了一个叫_source的字段用于存储整个文档的原始值。_source字段有一个特性，那就是这个字段在默认情况下是不会被索引的，但是每个查询默认都会带着_source字段返回。如果确定不需要使用_source字段保存源文档，也可以在创建索引通过映射类型的_source参数将其关闭

PUT /users
{"mappings":{_source":{"enabled":false} }
}

于设置映射关系，_source则是控制_source字段的开关。不推荐关闭_source字段通常，因为_source字段与以下一些功能相关联：

• 使用update、update_by_query更新文档，使用reindex重新索引文档;

• 运行时高亮检索结果；

• 在不同的Elasticsearch实例间重新索引|文档;

• 使用源文档对检索和聚集做debug。

关闭_source字段后，上述功能也将无法使用，所以在考虑关闭_source字段时要权衡清楚。通常关闭_source字段的主要原因是出于节省存储空间，Elastic官方建议如果单纯只是考虑节省存储空间可以通过修改index.codec提高压缩效率.

文档值 doc_values

doc_values 存储的并非原始文档内容，而是针对文档中那些可以被用于排序、聚合、脚本操作等的字段（列），将其值以一种列式存储的结构进行存储，便于快速的数据读取和相应的计算操作。它实际上是 Elasticsearch 为了提升查询性能，对特定类型数据进行的一种优化存储方式。例如对于数值型字段（如文章的字数统计数值）、日期型字段（如发布时间）、布尔型字段等，会把这些字段的值按照 doc_values 的方式存储起来，方便后续快速查找和计算分析。

所有非text类型的字段都支持文档值机制，并且都是开启的

fielddata

文档值doc_values机制的数据结构保存在硬盘中，而fielddata机制则是在内存中构建数据结构，所以使用fielddata机制有可能导致JVM内存溢出。不仅如此，fielddata机制保存的也不是字段原始值，而是通过遍历倒排索引建立文档与它所包含词项的对应关系。

具体来说，Elasticsearch会在首次对字段进行聚集、排序等请求时，遍历所有倒排索引并在内存中构建起文档与词项之间的对应关系。在默认情况下，text字段的fielddata机制是关闭的，可以通过在映射字段时修改fielddata参数开启。

在开启fielddata机制前要考虑清楚，因为这种机制显然非常消耗资源，而且使用text类型字段做聚集、排序也往往不是合理的需求。即便是真的有这样的需求，也可以通过字段多数据类型来开启文档值机制，而尽量不要使用fielddata机制。

• 文本字段聚合操作：对于文本类型的字段，若要进行诸如分组统计不同词汇出现的频次、按关键词进行分组等聚合分析时，就需要借助fielddata。比如在一个电商产品索引中，对 “商品评价” 字段进行分析，统计用户提及最多的评价关键词，这时fielddata会帮助解析 “商品评价” 里的文本内容并用于聚合计算。
• 文本字段排序操作：当要依据文本字段里的词项顺序等进行排序时，比如按照用户搜索关键词在文档中的匹配顺序来对搜索结果排序，fielddata能提供相应的数据支持，让这种基于文本内容词项的排序得以实现。
• 脚本中基于文本词项的操作：在自定义脚本里，如果需要对文本字段的词项进行逻辑判断、数值计算等操作（比如判断某个关键词是否在文档的文本字段中出现，出现次数达到一定数值就进行相应处理），fielddata里存储的文本词项相关数据就可以被脚本访问和使用。