elasticsearch聚合：script agg 和 filter agg 的实际使用
需要对索引中的做聚合，但是聚合的条件会比较复杂，并非从单一字段进行聚合。参考如下数据结构
要做的事：我们有 1 2 3 …… 等id，需要统计索引里面，a和b字段分别含有1 2 3对应的数量。文字难以表述的需求我们转化成数据结构来看
如果只有上面那一条数据的话，那么应该得出下面这个统计结果。
从表面剖析这个需求的话，似乎是个多字段的聚合。相对于单字段聚合来说问题还是比较棘手的。并不能简单的通过单字段的聚合来解决问题，我们先从最简单的情况开始处理问题。以统计1 2 3这3个id来举例子。
假设只需要对一个字段聚合，比如b字段，b字段是keyword类型，需要考虑的情况最为简单，当要对b字段聚合时语句很好写，如下即可
这是完整的query，后面的查询会省略掉query部分。query部分的用处也很明显：只把需要做聚合的部分过滤出来做聚合，我们需要统计的数据就在这部分中，而不是整个索引库。这样有两个好处：
1.提高效率，减少需要聚合的数据的数量
2.剔除需要考虑的意外情况，降低语句的复杂度
而聚合部分就非常简单了，仅仅对field_b聚合即可，但是很遗憾，离我们最终目标很远，这样只能统计出b字段的数据分布情况。
相对于上面的那种，接下来把另外一个字段也考虑进来看看。所以我们写下了这样的请求语句：
勉强的可以看到确实也是“统计了两个字段的情况”，但是是分开的，意味着要自己去解析返回结果并做计算来得到最终的返回结果。这确实是很令人恶心的事，那还有没有其他办法呢。但是观察语句的结构发现，似乎并没有过多可以更改的余地，所以需要寻求其他灵活的解决办法。
简单的单聚合无法表达出多字段聚合的需求，在谷歌过后我寻找到了这样一种解决方案：使用script，即脚本来描述我的需求。下面这段agg就是为了表达我想要根据我的需求灵活处理的一个方式：
这一段脚本的作用很明显，就是告诉es：当a字段或者b字段包括1的时候，扔到桶1；当a字段或者b字段包括2的时候，扔到桶2；……以此类推。看上去确实似乎完全解决了开头提出来的问题，验证后效率还能接受，不是特别慢。但是正当我沾沾自喜以为解决了问题的时候，随手验证了另外一个case，就直接冷水泼头了：
a字段和b字段是可能包含同一个id比如2，但是对于统计结果来说要求算作一条。
用上面这个脚本并无法体现出这个区别，而且还会有一个问题：
请求123和请求321时会返回不同统计结果
因为ifelse语句的关系，和||的性质，在满足条件1后便会扔到桶1，而无法在去后续条件中判断。这个脚本有很明显的bug存在。但是painless毕竟是脚本，可以使用的API和关键字都非常有限，写的复杂了还会很严重影响效率，无奈这个方案也只能pass，即使它看上去差点解决了我的问题。
在重新看了官方文档后，我发现了agg中的一个用法，filter agg。
filter agg的用法其实很简单，但是全意外的和我的需求很契合。之前忽视掉这个用法的主要原因是看到的示例都是对单字段做聚合。那如何同时聚合多个字段呢？从API入手验证是否可以使用比较灵活的写法
这是es提供的javaapi中filter agg的构造函数，key就是过滤名称，filter就是过滤条件。而且很友好的是，filter类型为QueryBuilder，也就是说，可以做成比较复杂的过滤方式。
这就是最后成型的agg块
agg模块的开发是比较麻烦的，首先性能问题比较困扰，其次语句编写远没有query模块的灵活。这次顺利解决需求，记录。
绛旓細鏍稿績瑕佺偣锛 1銆鑱氬悎鍒嗘瀽绠浠 2銆佹寚鏍囪仛鍚 2.1銆丮ax Aggregation 2.2銆丮in Aggregation 2.3銆丄vg Aggregation 2.4銆丼um Aggregation &...
绛旓細aggregations - 浠ｈ〃鑱氬悎鏌ヨ璇彞锛屽彲浠ョ畝鍐欎负aggs <aggregation_name> - 浠ｈ〃涓涓仛鍚堣绠楃殑鍚嶅瓧锛屽彲浠ラ殢鎰忓懡鍚嶏紝鍥犱负ES鏀寔涓娆¤繘琛屽娆＄粺璁″垎鏋愭煡璇紝鍚庨潰闇瑕侀氳繃杩欎釜鍚嶅瓧鍦ㄦ煡璇㈢粨鏋滀腑鎵惧埌鎴戜滑鎯宠鐨勮绠楃粨鏋溿 <aggregation_type> - 鑱氬悎绫诲瀷锛屼唬琛ㄦ垜浠兂瑕佹庝箞缁熻鏁版嵁锛屼富瑕佹湁涓ゅぇ绫昏仛鍚堢被鍨嬶紝妗惰仛...
绛旓細result3涓璽ermsCount灏辨槸鎴戜滑鎯宠寰楀埌鐨則otal銆 浠ヤ笂灏辨槸鎴戝terms鑱氬悎鍚庡啀瀵瑰叾鑱氬悎缁撴灉杩涜鍒嗛〉鐨勮В鍐冲姙娉曪紝濡傛灉澶у鏈夊叾浠栨洿濂界殑鍔炴硶锛屼篃璇峰垎浜嚭鏉ャ 濡傛灉瑙夊緱鏈枃鏈夊府鍔╁埌浣狅紝璇风粰鎴戠偣涓禐鍚э紒 PS:濡傛灉闇瑕佸湪姝ゅ熀纭涓婃敮鎸佹悳绱㈠姛鑳斤紝璇风Щ姝 Elasticsearch鑱氬悎缁撴灉鍒嗛〉骞舵敮鎸佷箣妯＄硦鏌ヨ ...
绛旓細Elasticsearch鏄綅浜嶦lasticStack鏍稿績鐨勫垎甯冨紡鎼滅储鍜屽垎鏋愬紩鎿庛侺ogstash鍜孊eats鏈夊姪浜庢敹闆嗐鑱氬悎鍜屼赴瀵屾偍鐨勬暟鎹苟灏嗗叾瀛樺偍鍦‥lasticsearch涓侹ibana浣挎偍鑳藉浠ヤ氦浜掓柟寮忔帰绱佸彲瑙嗗寲鍜屽垎浜鏁版嵁鐨勮瑙ｏ紝骞剁鐞嗐侲lasticsearch鏄储寮曘佹悳绱㈠拰鍒嗘瀽榄旀硶鍙戠敓鐨勫湴鏂广侲lasticsearch涓烘墍鏈夌被鍨嬬殑鏁版嵁鎻愪緵杩戜箮瀹炴椂鐨勬悳绱㈠拰鍒嗘瀽銆
绛旓細query閮ㄥ垎鐨勭敤澶勪篃寰堟槑鏄撅細鍙妸闇瑕佸仛鑱氬悎鐨勯儴鍒嗚繃婊ゅ嚭鏉ュ仛鑱氬悎锛屾垜浠渶瑕佺粺璁＄殑鏁版嵁灏卞湪杩欓儴鍒嗕腑锛岃屼笉鏄暣涓储寮曞簱銆傝繖鏍锋湁涓や釜濂藉锛 1.鎻愰珮鏁堢巼锛屽噺灏戦渶瑕佽仛鍚堢殑鏁版嵁鐨勬暟閲 2.鍓旈櫎闇瑕佽冭檻鐨勬剰澶栨儏鍐碉紝闄嶄綆璇彞鐨勫鏉傚害 鑰岃仛鍚堥儴鍒嗗氨闈炲父绠鍗曚簡锛屼粎浠呭field_b鑱氬悎鍗冲彲锛屼絾鏄緢閬楁喚锛岀鎴戜滑...
绛旓細濡傛灉鎯崇煡閬撳綋鍓峉QL鏄浣曞皢SQL瑙ｉ噴涓Elasticsearch 鐨凲uery DSL,鍙互杩欐牱閫氳繃鍏抽敭瀛梕xplain銆俬ttp://localhost:9200/_sql/_explain?sql=select * from indexName limit 10鑱氬悎绫诲嚱鏁版煡璇elect COUNT(*),SUM(age),MIN(age) as m, MAX(age),AVG(age) FROM bank GROUP BY gender ORDER BY SUM(age), m DESC...
绛旓細Elasticsearch鏄綅浜嶦lasticStack鏍稿績鐨勫垎甯冨紡鎼滅储鍜屽垎鏋愬紩鎿庛侺ogstash鍜孊eats鏈夊姪浜庢敹闆嗐鑱氬悎鍜屼赴瀵屾偍鐨勬暟鎹苟灏嗗叾瀛樺偍鍦‥lasticsearch涓ElasticSearch鏄竴涓熀浜嶭ucene鐨勬悳绱㈡湇鍔″櫒銆傚畠鎻愪緵浜嗕竴涓垎甯冨紡澶氱敤鎴疯兘鍔涚殑鍏ㄦ枃鎼滅储寮曟搸锛屽熀浜嶳ESTfulweb鎺ュ彛銆侲lasticsearch鏄敤Java寮鍙戠殑锛屽苟浣滀负Apache璁稿彲鏉℃涓嬬殑寮鏀...
绛旓細Elasticsearch涓鑸儏鍐典笅濡傛灉es鏈嶅姟姝ｅ父鍚姩锛屽彲浠ラ氳繃鎺ュ彛鐨勬柟寮忚幏鍙elasticsearch鐗堟湰淇℃伅锛歝urlhttp锛//10.1锛9200涓婅堪鍛戒护鍙互寰楀埌elasticsearch鐨勬湇鍔＄姸鎬佸拰鍏朵粬淇℃伅鍖呮嫭鐗堟湰鍙枫侲lasticsearch鏄綅浜嶦lasticStack鏍稿績鐨勫垎甯冨紡鎼滅储鍜屽垎鏋愬紩鎿庛侺ogstash鍜孊eats鏈夊姪浜庢敹闆嗐鑱氬悎鍜屼赴瀵屾偍鐨勬暟鎹苟灏嗗叾瀛樺偍鍦‥lasticsearch...
绛旓細Elasticsearch鑱氬悎浣挎偍鑳藉鏋勫缓澶嶆潅鐨勬暟鎹荤粨锛屽苟娲炲療鍏抽敭鎸囨爣銆佹ā寮忓拰瓒嬪娍銆備笉鍙槸瀵绘壘浼楁墍鍛ㄧ煡鐨勨滃ぇ娴锋崬閽堚濓紝鑱氬悎浣挎偍鑳藉鍥炵瓟杩欐牱鐨勯棶棰:鎮ㄨ繕鍙互浣跨敤鑱氬悎鏉ュ洖绛旀洿寰鐨勯棶棰橈紝渚嬪 鍥犱负鑱氬悎鍒╃敤浜嗙敤浜庢悳绱㈢殑鐩稿悓鏁版嵁缁撴瀯锛屾墍浠ュ畠浠篃闈炲父蹇傝繖浣挎偍鑳藉瀹炴椂鍒嗘瀽鍜屽彲瑙嗗寲鏁版嵁銆傛偍鐨勬姤鍛婂拰浠〃鏉夸細闅忕潃鏁版嵁...
绛旓細杩欑鍦ElasticSearch涓О涓簈uery_then_fetch锛屽彟涓绉嶅氨鏄竴闃舵鏌ヨ鐨勬椂鍊欏氨杩斿洖瀹屾暣Doc锛屽湪ElasticSearch涓彨query_and_fetch锛屼竴鑸浜岀閫傜敤浜庡彧闇瑕佹煡璇竴涓猄hard鐨勮姹傘傚洜涓鸿繖绉嶄竴娆¤姹傚氨鑳藉皢鏁版嵁璇锋眰鍒帮紝鍑忓皯浜や簰娆℃暟锛屼簩闃舵鐨勫師鍥犳槸闇瑕佸涓垎鐗鑱氬悎姹囨伙紝濡傛灉鏁版嵁閲忓お澶ч偅涔堜細褰卞搷缃戠粶浼犺緭鏁堢巼锛屾墍浠...
