es7.x的版本下,怎么插入timestamp类型的数据
mobikarl 回复了问题 • 2 人关注 • 2 个回复 • 3142 次浏览 • 2019-11-18 15:10
多条件过滤,查询时间段内,满足分数范围的数据
mobikarl 回复了问题 • 3 人关注 • 2 个回复 • 1672 次浏览 • 2019-11-18 15:09
Solutions:如何运用Elastic App Search快速建立出色的React搜索体验
回复liuxg 发起了问题 • 1 人关注 • 0 个回复 • 1770 次浏览 • 2019-11-16 21:10
function_score搜索是发生在协调结点查询的哪个流程?rescore呢
回复liuyeye 发起了问题 • 1 人关注 • 0 个回复 • 1313 次浏览 • 2019-11-16 18:20
請問已經定義好的 routing 值有辦法更改嗎
medcl 回复了问题 • 2 人关注 • 1 个回复 • 1161 次浏览 • 2019-11-15 17:56
小白疑问 所有文档更新一个字段,大部分值和当前值一样 极少数不一样。segment会增加很多吗
huangmingzhi 回复了问题 • 3 人关注 • 1 个回复 • 1100 次浏览 • 2019-11-19 12:04
esrally 在压测 query 过程中使用默认 clients 为 1 target-throughput:50,跑 1000 次. 他是怎么发起测试的. 工具是如果关注 es 性能的??
envy666 回复了问题 • 2 人关注 • 2 个回复 • 1408 次浏览 • 2019-11-18 16:19
关于ES7.X移除Transport Client 性能疑惑
Charele 回复了问题 • 4 人关注 • 4 个回复 • 4928 次浏览 • 2019-12-08 00:39
索引数据历史备份,要求可查
匿名用户 回复了问题 • 2 人关注 • 2 个回复 • 1294 次浏览 • 2019-11-18 15:08
es是构建在lucene之上,中国目前有lucene的社区吗?国外的也行
medcl 回复了问题 • 2 人关注 • 1 个回复 • 2588 次浏览 • 2019-11-15 09:18
关于xpack和license的问题?
liuxg 回复了问题 • 4 人关注 • 3 个回复 • 3969 次浏览 • 2019-11-18 14:53
elasticsearch 单独分离协调节点意义在哪
匿名用户 回复了问题 • 3 人关注 • 3 个回复 • 6321 次浏览 • 2019-11-18 14:51
es5.6.10 主分片unassigned
匿名用户 回复了问题 • 2 人关注 • 2 个回复 • 1863 次浏览 • 2019-11-18 14:50
ES脚本性能优化一例
hufuman 发表了文章 • 0 个评论 • 6194 次浏览 • 2019-11-13 19:48
使用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 />
性能即可得到极大改善。