ES踩坑笔记

现在开始在业务上使用ES,记录一些踩坑经历,做点笔记.


2018-11-13

source不返回问题

使用了角色校验,客户端插入成功之后获取数据没有source,和查询参数无关.
检查mapping,发现获取mapping也是空...
如下:

{'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有中划线,分词结果:

GET /_analyze
{
  "analyzer": "standard",
  "text": "1111-2222-4444-3333-55555"
}
{
  "tokens": [
    {
      "token": "1111",
      "start_offset": 0,
      "end_offset": 4,
      "type": "<NUM>",
      "position": 0
    },
    {
      "token": "2222",
      "start_offset": 5,
      "end_offset": 9,
      "type": "<NUM>",
      "position": 1
    },
    {
      "token": "4444",
      "start_offset": 10,
      "end_offset": 14,
      "type": "<NUM>",
      "position": 2
    },
    {
      "token": "3333",
      "start_offset": 15,
      "end_offset": 19,
      "type": "<NUM>",
      "position": 3
    },
    {
      "token": "55555",
      "start_offset": 20,
      "end_offset": 25,
      "type": "<NUM>",
      "position": 4
    }
  ]
}

然后在代码里使用的是termQuery:

SearchRequest searchRequest = new SearchRequest(INDEX_NAME);
searchRequest.types(TYPE_NAME);
SearchSourceBuilder sourceBuilder = new SearchSourceBuilder();
sourceBuilder.query(QueryBuilders.termQuery(ID, id));

termQuery是不对搜索词分词的...
于是就什么都查不出来..
解决方式是用dynamic mapping自动生成的keyword field.

参考:
https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-analyzers.html


2018-12-14

处理深分页

默认的from+size限制是10000,大于这个会报错:

{
  "error": {
    "root_cause": [
      {
        "type": "query_phase_execution_exception",
        "reason": "Result window is too large, from + size must be less than or equal to: [1000000] but was [1000001]. See the scroll api for a more efficient way to request large data sets. This limit can be set by changing the [index.max_result_window] index level setting."
      }
    ],

深分页的操作对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

posted @   fairjm  阅读(731)  评论(0编辑  收藏  举报
编辑推荐:
· Linux系列:如何用heaptrack跟踪.NET程序的非托管内存泄露
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
阅读排行:
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY
· 无需6万激活码!GitHub神秘组织3小时极速复刻Manus,手把手教你使用OpenManus搭建本
· C#/.NET/.NET Core优秀项目和框架2025年2月简报
点击右上角即可分享
微信分享提示