11月16日 Elastic 中文社区深圳 Meetup 上，欧阳楚才将为大家分享 阿里云Elasticsearch内核优化与应用实践。借此机会，我们邀请到他聊聊选ES在阿里云实践过程中遇到的最大业务挑战和解决方案，以及他在高并发架构设计方面的心得。

分享嘉宾 欧阳楚才 搜索技术专家 @阿里巴巴

在阿里巴巴负责Elasticsearch云服务研发工作，有比较丰富的搜索引擎研发经验，熟悉Lucene、Elasticsearch等开源技术，擅长高并发系统架构设计。


Q1、ES 在阿里云实践中遇到最大的业务挑战是什么？如何解决的？

A：阿里云Elasticsearch最大的业务挑战是保障线上服务稳定。通过支持多可用区部署，避免单机房异常导致服务不可用。通过ECS本地盘、ESSD云盘提供高IOPS的存储，避免IO瓶颈导致查询响应慢，使用ECS本地盘也可以降低存储成本。通过ElasticFlow离线构建索引，避免写入和查询争抢资源导致查询响应变慢。通过智能诊断服务Eyou定期检查Elasticsearch服务健康状况，及时发现系统存在的隐患。


Q2、您在高并发系统架构设计方面有哪些心得为大家分享？

A：结合业务场景做容量规划，评估系统需要支撑的写入TPS、查询QPS、最大响应延迟时间。对于Elasticsearch而言，通常最大的瓶颈在磁盘IO，尽量使用SSD盘高性能存储设备。为了系统稳定，单个节点Elasticsearch的JVM内存尽量不要超过32G，单节点存储数据量尽量不要超过5TB，高并发搜索场景推荐单节点配置16核CPU、64G内存、2TB SSD盘。Elasticsearch集群节点数不要超过300个，数据量大的集群根据业务拆分多个集群，配置跨集群搜索。系统上线前做全链路压测，找到系统瓶颈。生产环境开启慢查询日志，分析bad case。


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

A：Elasticsearch是开源的分布式搜索和分析引擎，开箱即用、弹性扩展方便。从早期的ELK到现在的Elastic技术栈，版本迭代持续加速，Elasticsearch的性能、扩展性、相关性不断优化。Elasticsearch最开始设计用于搜索引擎，后来不断被应用到日志分析、数据库加速、安全风控等领域，通过插件扩展机制可以用于图像、视频等非结构化数据分析。


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

A：期待能看到更多Elasticsearch应用案例，跟大家一起交流最佳实践。


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

A：Elastic中文社区之前组织过翻译《Elasticsearch权威指南》中文文档，当时的Elasticsearch版本为2.x，现在的Elasticsearch7.x版本在API、功能方面已经有很大变化，建议组织志愿者更新文档。




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

主题分享：《阿里云Elasticsearch内核优化与应用实践》欧阳楚才
 
主题摘要：Elasticsearch在阿里云上服务了大量的客户，同时也面临着巨大的业务挑战。阿里云ES在内核引擎、中文分词、向量检索、容器化部署等方面做了一系列开发工作，应用于文档、日志、图像、视频的检索与分析。


 

使用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