广度优先的话,是我们先处理电影数,而不管电影的评论数的聚合情况,先从10万演员中干掉99990条数据,剩下10个演员再聚合
"aggs":{ "target_actors":{ "terms":{ "field":"actors", "size":10, "collect_mode":"breadth_first" # 广度优先 } } } global aggregation全局聚合,下面先使用query进行全文检索,然后进行聚合, 下面的聚合实际上是针对两个不同的结果进行聚合,第一个聚合添加了global关键字,意思是ES中存在的所有doc进行聚合计算得出t-shirt的平均价格
第二个聚合针对全文检索的结果进行聚合
POST /sales/_search?size=0 { "query" : { "match" : { "type" : "t-shirt" } }, "aggs" : { "all_products" : { "global" : {}, "aggs" : { "avg_price" : { "avg" : { "field" : "price" } } } }, "t_shirts": { "avg" : { "field" : "price" } } } } Cardinality Aggregate 基数聚合作用类似于count(distcint),会对每一个bucket中指定的field进行去重,然后取去重后的count
虽然她会存在5%左右的错误率,但是性能特别好
POST /sales/_search?size=0 { "aggs" : { "type_count" : { "cardinality" : { # 关键字 "field" : "type" } } } }对Cardinality Aggregate的性能优化, 添加 precision_threshold 优化准确率和内存的开销
下面的示例中将precision_threshold的值调整到100意思是当 type的类型小于100时,去重的精准度为100%, 此时内存的占用情况为 100*8=800字节
加入我们将这个值调整为1000,意思是当type的种类在1000个以内时,去重的精准度100%,内存的占用率为1000*8=80KB
官方给出的指标是, 当将precision_threshold设置为5时,错误率会被控制在5%以内
POST /sales/_search?size=0 { "aggs" : { "type_count" : { "cardinality" : { # 关键字 "field" : "type", "precision_threshold":100 } } } }进一步优化,Cardinality底层使用的算法是 HyperLogLog++, 可以针对这个算法的特性进行进一步的优化,因为这个算法的底层会对所有的 unique value取hash值,利用这个hash值去近似的求distcint count, 因此我们可以在创建mapping时,将这个hash的求法设置好,添加doc时,一并计算出这个hash值,这样 HyperLogLog++ 就无需再计算hash值,而是直接使用
PUT /index/ { "mappings":{ "my_type":{ "properties":{ "my_field":{ "type":"text", "fields":{ "hash":{ "type":"murmu3" } } } } } } } 控制聚合的升降序先按照颜色聚合,在聚合的结果上,再根据价格进行聚合, 最终的结果中,按照价格聚合的分组中升序排序, 这算是个在下转分析时的排序技巧
GET /index/type/_search { "size":0, "aggs":{ "group_by_color":{ "term":{ "field":"color", "order":{ # "avg_price":"asc" } } }, "aggs":{ "avg_price":{ "avg":{ "field":"price" } } } } } Percentiles Aggregation计算百分比, 常用它计算如,在200ms内成功访问网站的比率,在500ms内成功访问网站的比例,在1000ms内成功访问网站的比例, 或者是销售价为1000元的商品,占总销售量的比例, 销售价为2000元的商品占总销售量的比例等等
示例: 针对doc中的 load_time字段, 计算出在不同百分比下面的 load_time_outliner情况
GET latency/_search { "size": 0, "aggs" : { "load_time_outlier" : { "percentiles" : { "field" : "load_time" } } } }响应 : 解读: 在百分之50的加载请求中,平均load_time的时间是在445.0, 在99%的请求中,平均加载时间980.1
{ ... "aggregations": { "load_time_outlier": { "values" : { "1.0": 9.9, "5.0": 29.500000000000004, "25.0": 167.5, "50.0": 445.0, "75.0": 722.5, "95.0": 940.5, "99.0": 980.1000000000001 } } } }还可以自己指定百分比跨度间隔
GET latency/_search { "size": 0, "aggs" : { "load_time_outlier" : { "percentiles" : { "field" : "load_time", "percents" : [95, 99, 99.9] } } } }优化: percentile底层使用的是 TDigest算法,用很多个节点执行百分比计算,近似估计,有误差,节点越多,越精准
可以设置compression的值, 默认是100 , ES限制节点的最多是 compression*20 =2000个node去计算 , 因为节点越多,性能就越差
一个节点占用 32字节, 1002032 = 64KB
GET latency/_search { "size": 0, "aggs" : { "load_time_outlier" : { "percentiles" : { "field" : "load_time", "percents" : [95, 99, 99.9], "compression":100 # 默认值100 } } } } 优化相关性得分第一种方式:
在content字段中全文检索 java elasticsearch时,给title中同时出现java elasticsearch的doc的权重加倍
"query": { "bool" : {# 前缀匹配 "match":{ "content":{ "query":"java elasticsearch" } }, "should":[ "match":{ "title":{ "query":"java elasticsearch", "boost":2 } } ] } }第二种: 更换写法,改变占用的权重比例
GET my_index/_doc/_search { "query":{ "should":[ { "match":{"title":"this is"}}, # 1/3 { "match":{"title":"this is"}}, # 1/3 { "bool":{ "should":[ {"match":{"title":"this is"}}, # 1/6 {"match":{"title":"this is"}} # 1/6 ] } } ] } }