要不要也来分享分享一下啊

ES服务稳定请教

Elasticsearch | 作者 ridethewind | 发布于2019年06月14日 | 阅读数:2033

如何能让ES服务处于稳定的状态,不会被业务给压挂
业务中经常会一些不当的操作,比如模糊匹配长度较长,深度分页等不当的用法。有哪些防护措施,能够保护一下ES,目前ES服务前没有挂别的服务。
现在已经参考7.0的熔断机制将indices.breaker.fielddata.limit设置为了40%,大佬们还有什么建议?
已邀请:

cyberdak

赞同来自:

indices.breaker.fielddata.limit 这个参数,设置的范围很大,看你jvm多大,比如31G的jvm,设置到4%都可以满足大多数的搜索。40%还是比较冒险。

王庆焕 - https://discuss.elastic.co/u/wangqinghuan/

赞同来自:

模糊匹配(wildcard query)如果设置的不当(例如将*放在首位,会扫描所有的词典)只是影响查询效率,不会影响稳定性。

深度分页默认最多深度查询到第1w条记录(es window size默认限制,可以根据你的实际情况修改),相当于es限制了深度分页。
es默认所有的字段都设置了doc values,fielddata默认禁用,如果排序聚合,必须设置doc values。所以排序聚合也基本不会影响稳定性。
5.0版本以后的es已经把之前容易出现问题的设置(用过1.x版本的用户基本都遇到过这些问题)都做了禁用或者限制。但是在使用api或者某个功能时,仍然要去官网仔细阅读文档,如果有影响效率和稳定性的风险,文档都会给出提示。

hapjin

赞同来自:

根据实际需求,有些搜索其实并不需要搜出所有的文档,terminate_after 和 timeout 这2个参数就很有用了。
 
terminate_after


The maximum number of documents to collect for each shard, upon reaching which the query execution will terminate early


timeout


A search timeout, bounding the search request to be executed within the specified time value and bail with the hits accumulated up to that point when expired. Search requests are canceled after the timeout is reached using the Search Cancellationedit mechanism.

要回复问题请先登录注册