使用painless脚本为文档自定义打分是很常见的场景，对新人来说也是最容易造成性能问题的地方。本文中使用两个例子简单谈一下脚本性能优化。

目标

ES本身是基于倒排等数据结构实现的查询，因此在做类似Term、Match等可以利用底层数据结构的场景进行查询时，性能是很好的。

脚本和term等查询不一样，无法利用现有的各种数据结构，可以简单理解成循环：

<br /> docs = getDocs(xxx); // 获取满足条件的文档列表<br /> for(Doc doc : docs) {<br /> score = getScoreByScript(doc);<br /> }<br />



因此脚本的性能取决于两个地方：脚本的复杂度和满足条件的文档数。

例子1

我们有个场景是查询指定坐标指定范围内的POI列表，例如5公里内的景点列表。

由于我们的距离公式和ES默认的都不一致，如下：

/**

• 计算距离，返回单位：米
  /
  public static Double getDistance(Double lat1, Double lng1, Double lat2, Double lng2) {
  double diffLon = Math.abs(lng1 - lng2);
  if (diffLon > 180)
  diffLon -= 360;
  return Math.sqrt(Math.pow(diffLon, 2) + Math.pow(lat1 - lat2, 2)) 110.0 * 1000;
  }
  
  所以该同学把这段Java代码转成了Painless，在sort里使用这个该方法计算出距离。上线以后发现ES有了很多慢查询，对应的服务也95线、99线也比较高。
  
  原因是其他脚本没有有效地缩小数据量，导致有几百万的数据需要使用该脚本做距离计算，给ES的CPU造成很大压力，查询性能也比较差。
  
  该例子优化起来很简单，即使用ES自带的distance做较大范围的限制，例如需要5公里的数据，可以用ES的plain距离做限制，再加上之前的自定义脚本逻辑。由于ES的plain距离计算性能好很多，因此经过该过滤以后，自定义脚本的文档量少了很多，因此整体性能有了很大提升。
  
  
  
  

  例子2
  

  有个场景是对文章进行搜索，如果文章关联的城市是指定的几个城市，则给额外的加分。例如：
  
  <br /> {<br /> "query": {xxx},<br /> "sort": [<br /> {<br /> "_script": {<br /> "script": {<br /> "source": "def score = 0;def cityIds = doc['cityIds']; def paramCityIds = params.cityIds; for (int i=0; i<cityIds.size(); i++){if (paramCityIds.contains(cityIds[i])){score += 100;}} return score;",<br /> "lang": "painless",<br /> "params": {<br /> "cityIds": [2,1,3]<br /> }<br /> },<br /> "type": "number",<br /> "order": "desc"<br /> }<br /> }<br /> ]<br /> }<br />
  
  
  
  问题和例子1一样，该功能的性能比较差。虽然脚本简单，但是满足的文档量比较大，带来的计算量也比较多，因此性能上不去。
  
  这是一个比较常见的场景，问题的根源还是对ES的机制不够了解，优化起来也很简单，想办法利用到倒排就可以了。
  
  ES里有个专门针对改场景的查询：[constant_score](https://www.elastic.co/guide/e ... y.html)，因此以上查询可以修改为：
  
  <br /> {<br /> "query": {<br /> "should": [<br /> {<br /> "constant_score": {<br /> "filter": {<br /> "term": {<br /> "cityIds": 2<br /> }<br /> },<br /> "boost": 5<br /> }<br /> },<br /> {<br /> "constant_score": {<br /> "filter": {<br /> "term": {<br /> "cityIds": 1<br /> }<br /> },<br /> "boost": 5<br /> }<br /> },<br /> {<br /> "constant_score": {<br /> "filter": {<br /> "term": {<br /> "cityIds": 3<br /> }<br /> },<br /> "boost": 5<br /> }<br /> }<br /> ]<br /> },<br /> "sort": [<br /> {<br /> "_score": "desc"<br /> ]<br /> }<br />
  
  
  
  性能即可得到极大改善。

1、日志文件转运工具Filebeat笔记
http://t.cn/Airah1qx
2、 海量日志分析平台在 58 集团的实践
http://t.cn/Aira7yLu
3、Elasticsearch实战 磁盘IO被打满
http://t.cn/AiraqfUb

 
编辑：江水
归档：https://ela.st/cn-daily-all
订阅：https://ela.st/cn-daily-sub
沙龙：https://ela.st/cn-meetup

11月16日 Elastic 中文社区深圳 Meetup 上，黄杨锋将为大家分享基于K8S的ES服务平台在头条的实践。借此机会，我们邀请到他聊聊从0到1构建ES服务平台遇到的痛点、解决方案以及未来的规划。


分享嘉宾 黄杨锋 高级工程师 @字节跳动

目前在头条深圳负责ES服务平台相关的研发工作；此前曾就职于华为、YY、腾讯等企业，在腾讯基于ES做微信支付数据的检索。


Q1、从0到1构建 ES 服务平台的过程中有哪些痛点？分别是如何解决的？

A：（1）需要隔离，远离大集群，是通过 k8s来解决。

      （2）性能分析方面相对还比较薄弱 ，打算增加metric和trace日志来看看具体耗时。


Q2、在 ES 服务平台方面未来还有什么样的规划？

A：相关规划详见下图




Q3、结合您的实践经历，对 ES 目前的生态发展、应用以及未来有什么样的看法？

A： ES 发展很快，周边生态也越来越丰富，希望 ES 在快速发展的过程中，更加注重查询性能的优化提升，以及集群的稳定性。


Q4、您对本次技术沙龙活动的主题分享有什么期待？

A：期望看到性能优化、机器学习相关的最新进展。


Q5、您对 Elastic 中文社区发展有什么意见或建议呢？

A：（1）ES 在中国程序员中的影响力感觉可以加强，希望可以做到像 Google/Amazon 在中国程序员群体上那样有很大的影响力；

      （2）希望官方出一些内核相关的书籍或文章；

      （3）希望价钱可以再调低点。



11月16日 Elastic 中文社区深圳 Meetup 火热报名中

主题分享：《基于K8S的ES服务平台在头条的实践介绍》黄杨锋

主题摘要：ES 服务平台自上线以来，已经接入了头条、抖音等众多业务。本次分享将介绍 ES 服务平台从 0 到 1 的创建过程中所做的一些工作，包括 K8S 碰到的一些难点、ES 功能的增强、跨机房容灾、全栈监控告警、自动化部署等功能。