聚合数据内部原理

聚合分析的内部原理是什么？？？？aggs，term，metric avg max，执行一个聚合操作的时候，内部原理是怎样的呢？用了什么样的数据结构去执行聚合？是不是用的倒排索引？

搜索+聚合，写个示例

GET /test_index/test_type/_search 
{
    "query": {
        "match": {
            "search_field": "test"
        }
     },
     "aggs": {
        "group_by_agg_field": {
            "terms": {
                "field": "agg_field"
            }
         }
      }
}

纯用倒排索引来实现的弊端

es肯定不是纯用倒排索引来实现聚合+搜索的

search_field
 doc1: hello world test1, test2
 doc2: hello test
 doc3: worldtest
 倒排索引
 hello    doc1,doc2
 world    doc1,doc3
 test1    doc1
 test2    doc1
 test       doc2,doc3"query": {
    "match": {
        "search_field": "test"
    }
}搜索：
test --> doc2,doc3 --> search result：doc2,doc3
聚合：
 agg_field
 doc2: agg1
 doc3: agg2100万个值
 ...
 ...
 ...
 ...
 agg1    doc2
 agg2    doc3doc2, doc3, search result --> 实际上，要搜索到doc2的agg_field的值是多少，doc3的agg_field的值是多少
 doc2和doc3的agg_field的值之后，就可以根据值进行分组，实现terms bucket操作

doc2的agg_field的值是多少，这个时候，如果你手上只有一个倒排索引，你该怎么办？？？你要扫描整个倒排索引，去一个一个的搜，拿到每个值，比如说agg1，看一下，它是不是doc2的值，拿到agg2,看一下，是不是doc2的值，直到找到doc2的agg_field的值，在倒排索引中。

倒排索引的话，必须遍历完整个倒排索引才可以。。。。
因为可能你要聚合的那个field的值，是分词的，比如说hello world my name --> 一个doc的聚合field的值可能在倒排索引中对应多个value
所以说，当你在倒排索引中找到一个值，发现它是属于某个doc的时候，还不能停，必须遍历完整个倒排索引，才能说确保找到了每个doc对应的所有terms，然后进行分组聚合

如果用纯倒排索引去实现聚合，现实不现实啊？？？性能是很低下。

搜索：用倒排索引，搜那个term，就结束了，性能很高;

聚合：搜索出了1万个doc，每个doc都要在倒排索引中搜索出它的那个聚合field的值，用倒排索引性能及其低下。

实际原理

正排索引

倒排索引+正排索引（doc value）的原理和优势

doc value：正排索引
search_field
 doc1: hello world test1, test2
 doc2: hello test
 doc3: world testhello    doc1,doc2
 world    doc1,doc3
 test1    doc1
 test2    doc1
 test       doc2,doc3


 

"query": {
    "match": {
        "search_field": "test"
}
test --> doc2,doc3 --> search result, doc2,doc3
doc value数据结构，正排索引
...
 ...
 ...
 100万个
 doc2: agg1
 doc3: agg2

我们有没有必要搜索完整个正排索引啊？？1万个doc --> 搜 -> 可能跟搜索到15000次，就搜索完了，就找到了1万个doc的聚合field的所有值了，然后就可以执行分组聚合操作了
 

 

doc value原理

原理

（1）index-time生成

PUT/POST的时候，就会生成doc value数据，也就是正排索引

（2）核心原理与倒排索引类似

正排索引，也会写入磁盘文件中，然后呢，os cache先进行缓存，以提升访问doc value正排索引的性能
如果os cache内存大小不足够放得下整个正排索引，doc value，就会将doc value的数据写入磁盘文件中

（3）性能问题

给jvm更少内存，64g服务器，给jvm最多16g

es官方是建议，es大量是基于os cache来进行缓存和提升性能的，不建议用jvm内存来进行缓存，那样会导致一定的gc开销和oom问题
给jvm更少的内存，给os cache更大的内存
64g服务器，给jvm最多16g，几十个g的内存给os cache
os cache可以提升doc value和倒排索引的缓存和查询效率

 

column压缩

doc1: 550
doc2: 550
doc3: 500

合并相同值，550，doc1和doc2都保留一个550的标识即可

（1）所有值相同，直接保留单值
（2）少于256个值，使用table encoding模式：一种压缩方式
（3）大于256个值，看有没有最大公约数，有就除以最大公约数，然后保留这个最大公约数

doc1: 36
doc2: 24

6 --> doc1: 6, doc2: 4 --> 保留一个最大公约数6的标识，6也保存起来

（4）如果没有最大公约数，采取offset结合压缩的方式：

 

disable doc value

如果的确不需要doc value，比如聚合等操作，那么可以禁用，减少磁盘空间占用
 

PUT my_index
{
  "mappings": {
    "my_type": {
      "properties": {
        "my_field": {
          "type":       "keyword"
          "doc_values": false 
        }
      }
    }
  }
}