一、聚合操作内部原理
1.正排索引（doc value）的聚合内部原理
①index-time生成
PUT/POST的时候，就会生成doc value数据，也就是正排索引
②核心原理与倒排索引类似
正排索引，也会写入磁盘文件中，然后os cache先进行缓存，以提升访问doc value正排索引的性能
如果os cache内存大小不足够放得下整个正排索引，doc value，就会将doc value的数据写入磁盘文件中
③性能问题：给jvm更少的内存，给os cache更大的内存
④如果的确不需要doc value，比如聚合等操作，那么可以禁用，减少磁盘空间占用
PUT my_index
{
"mappings": {
"my_type": {
"properties": {
"my_field": {
"type": "keyword"
"doc_values": false
}
}
}
}
}⑤如果要对分词的field执行聚合操作，必须将fielddata设置为true
POST /test_index/_mapping/test_type
{
"properties": {
"test_field": {
"type": "text",
"fielddata": true
}
}
}
二、易并行聚合算法：比如max
1.近似聚合算法
：采用在每个node上进行近估计的方式，得到最终的结论
如果采取近似估计的算法：延时在100ms左右，0.5%错误
如果采取100%精准的算法：延时一般在5s~几十s，甚至几十分钟，几小时，0%错误
2.三角选择原则
：精准+实时+大数据 --> 选择2个
a.精准+实时: 没有大数据，数据量很小，那么一般就是单击跑，随便你则么玩儿就可以
b.精准+大数据：hadoop，批处理，非实时，可以处理海量数据，保证精准，可能会跑几个小时
c.
大数据+实时
：es，不精准，近似估计，可能会有百分之几的错误率
三、cardinality去重算法
cartinality metric，对每个bucket中的指定的field进行去重，取去重后的count，类似于count(distcint)
cardinality，count(distinct)，5%的错误率，性能在100ms左右
cardinality算法，会占用precision_threshold * 8 byte 内存消耗，100 * 8 = 800个字节
HyperLogLog++ (HLL)算法性能优化
例：GET /tvs/sales/_search
{
"size" : 0,
"aggs" : {
"months" : {
"date_histogram": {
"field": "sold_date",
"interval": "month"
},
"aggs": {
"distinct_colors" : {
"cardinality" : {
"field" : "brand"
}
}
}
}
}
}
四、需求实战：记录下每次请求的访问的耗时，需要统计tp50，tp90，tp99
a.percentiles百分比算法
例：比如有一个网站，记录下了每次请求的访问的耗时，需要统计tp50，tp90，tp99
GET /website/logs/_search
{
"size": 0,
"aggs": {
"group_by_province": {
"terms": {
"field": "province"
},
"aggs": {
"latency_percentiles": {
"percentiles": {
"field": "latency",
"percents": [
50,
95,
99
]
}
},
"latency_avg": {
"avg": {
"field": "latency"
}
}
}
}
}
}
b.percentile ranks和网站访问时延SLA统计
例：在200ms以内的，有百分之多少，在1000毫秒以内的有百分之多少
GET /website/logs/_search
{
"size": 0,
"aggs": {
"group_by_province": {
"terms": {
"field": "province"
},
"aggs": {
"latency_percentile_ranks": {
"percentile_ranks": {
"field": "latency",
"values": [
200,
1000
]
}
}
}
}
}
}
c.percentile的优化：
TDigest算法:用很多节点来执行百分比的计算，近似估计，有误差，节点越多，越精准
compression:默认100，限制节点数量最多 compression * 20 = 2000个node去计算,越大，占用内存越多，越精准，性能越差，一个节点占用32字节，100 * 20 * 32 = 64KB，如果你想要percentile算法越精准，compression可以设置的越大
五、海量bucket优化机制：从深度优先到广度优先
例：对于评论数量排名前10的演员，每个演员的电影取到评论数量排名前5的电影
{
"aggs" : {
"actors" : {
"terms" : {
"field" : "actors",
"size" : 10,
"collect_mode" : "breadth_first"
},
"aggs" : {
"costars" : {
"terms" : {
"field" : "films",
"size" : 5
}
}
}
}
}
}
深度优先的方式，构建了一整颗完整的树出来了，10万个actor，每个actor平均有10部电影，10万 + 100万 --> 110万的数据量的一颗树。构建了大量的数据，然后裁剪掉了99.99%的数据。
广度优先的方式，构建出film，裁剪出其中的5个film即可，10万 -> 50个
