现在开始在业务上使用ES,记录一些踩坑经历,做点笔记.
2018-11-13
source不返回问题
使用了角色校验,客户端插入成功之后获取数据没有source,和查询参数无关.
检查mapping,发现获取mapping也是空…
如下:
1 | {'test_index': {'mappings': {'test_doc': {'properties': {}}}}} |
排查了一会儿..找不出原因.
后来要到了一个高权限的账号去kibana看了眼…发现
能获取的fields为空… …
emmmmm….
设置为*
后解决
参考链接:
https://www.elastic.co/guide/en/elastic-stack-overview/6.4/field-level-security.html
2018-11-16
termQuery不返回结果
emmmmm 一个id是用了dynamic mapping插入,默认使用的是standard分词器.
一些id有中划线,分词结果:
1 | GET /_analyze |
1 | { |
然后在代码里使用的是termQuery:
1 | SearchRequest searchRequest = new SearchRequest(INDEX_NAME); |
termQuery是不对搜索词分词的…
于是就什么都查不出来..
解决方式是用dynamic mapping自动生成的keyword field.
参考:
https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-analyzers.html
2018-12-14
处理深分页
默认的from
+size
限制是10000,大于这个会报错:
1 | { |
深分页的操作对coordinator会造成很大的影响,会占用大量heap存放数据并进行排序操作.
业务上没有注意,结果就超了… …
可以设定index.max_result_window
来提高上限.
但如果真的要有这么深,还是使用search after比较可靠.又因为是实时业务查询,所以用scroll是不合适的.
参考:
https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules.html
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-search-after.html