ElasticSearch中倒排索引和正向索引

ElasticSearch搜索使用的是倒排索引，但是排序、聚合等不适合倒排索引使用的是正向索引

倒排索引

倒排索引表以字或词为关键字进行索引，表中关键字所对应的记录项记录了出现这个字或词的所有文档，每个字段记录该文档的ID和关键字在该文档中出现的位置情况。

倒排表的结构图如图2：

如下就是倒排索引，对语句进行分词，按照单位进行索引

由于每个字或词对应的文档数量在动态变化，所以倒排表的建立和维护都较为复杂，但是一旦完成创建，在查询的时候由于可以一次得到查询关键字所对应的所有文档

例如查询hello，通过hello就能够知道包含了hello的全部文档，便于搜索

得到正向索引的结构如下：

当用户在主页上搜索关键词“china”时，在正向索引下，就需要扫描所有文档，找出所有包含关键词“china”的文档，由于一般在搜索引擎中的文档的数目是个天文数字，这样的索引结构根本无法满足实时返回结果的要求。这种结构不适合搜索，但是时候排序和聚合

这里正向索引也叫doc ，Doc values

Doc values 是不支持 analyzed 字符串字段的，正向排序不能支持分词，想象一下，如果一个字段是analyzed，如the first，则在分析阶段则会docvalues则会存储为两条docvalue（the和first），计算时候则会得到，不清楚的看博客ElasticSearch中的sort排序和filedData作用

而非

此时需要Fielddata来解决。

Fielddata

Doc values 是不支持 analyzed 字符串字段的，然而，这些字段仍然可以使用聚合，是因为使用了fielddata 的数据结构。与 doc values 不同，fielddata 构建和管理 100% 在内存中，常驻于 JVM 内存堆。

Fielddata默认是不启用的，因为text字段比较长，一般只做关键字分词和搜索，很少拿它来进行全文匹配和聚合还有排序，因为大多数这种情况是无意义的，一旦启用将会把text都加载到内存中，那将带来很大的内存压力。

Fielddata一些特性：

Fielddata 是延迟加载的。如果你从来没有聚合一个分析字符串，就不会加载 fielddata 到内存中，是在查询时候构建的。

fielddata 是基于字段加载的，只有很活跃地使用字段才会增加fielddata 的负担。

fielddata 会加载索引中（针对该特定字段的）所有的文档，而不管查询是否命中。逻辑是这样：如果查询会访问文档 X、Y 和 Z，那很有可能会在下一个查询中访问其他文档。

如果空间不足，使用最久未使用（LRU）算法移除fielddata。

所以，fielddata应该在JVM中合理利用，否则会影响es性能。

如果一次性加载字段直接超过内存值会发生什么？挂掉？所以es为了防止这种情况，采用了circuit breaker（熔断机制）。

它通过内部检查（字段的类型、基数、大小等等）来估算一个查询需要的内存。它然后检查要求加载的 fielddata 是否会导致 fielddata 的总量超过堆的配置比例。如果估算查询大小超出限制，就会触发熔断，查询会被中止并返回异常。

indices.breaker.fielddata.limit fielddata级别限制，默认为堆的60%

indices.breaker.request.limit request级别请求限制，默认为堆的40%

indices.breaker.total.limit 保证上面两者组合起来的限制，默认堆的70%

最后

1.ElasticSearch原理是倒排索引和正排索引的转化版
2.DocValues满足非analyed字段的正排索引转化版，Fielddata对应analyed
3.DocValues存在于磁盘，消耗Lucene内存来提升效率，Fielddata存在于ElasticSearch内存（jvm）

作者：激情的狼王
链接：https://www.jianshu.com/p/04837bf5863f
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。