elasticsearch常用api

发表于 | 更新于 | 分类于

在es的日常使用过程中，有些频繁使用的，比较重要的api在这里罗列下来，一是为了使用时方便，二是为了做笔记，将使用过程中的一些问题，一些疑惑记录下来

reindex

reindex 本身底层实现原理是借助scroll，所以在大数量的情况下，要对reindex做优化的话可以从scroll的优化入手，比如增加切片slices

1
2
3
4
5
6
7
8
9
10
11
POST _reindex?slices=5&refresh
{
  "source": {
    "index": "portal_news_201",
    "size": 2000
  },
  "dest": {
    "index": "portal_news_test"
  }
}
`

分页&深度分页

from+size

能够实现随意跳页，目前最大只能查询到10000条数据 index.max_result_window:10000，可以修改参数，但是不建议,越往后性能越差

search_after

为了解决深度分页，ES在5.0版本之前推荐使用scroll，但是scroll不适合实时场景，所以在ES5.0之后推出了search_after解决深度分页问题

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
第一次请求
POST portal_news/_search
{
  "query": {
    "range": {
      "pub_date": {
        "gte": "2020-01-01",
        "lte": "2020-04-01"
      }
    }
  },
  "size": 10,
  "sort": [
    {
      "pub_date": {
        "order": "desc"
      }
    }
  ]
}

请注意至少要带上一个排序字段

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
后续请求，带上第一次请求返回的sort值
POST portal_news/_search
{
  "query": {
    "range": {
      "pub_date": {
        "gte": "2020-01-01",
        "lte": "2020-04-01"
      }
    }
  },
  "size": 10,
  "sort": [
    {
      "pub_date": {
        "order": "desc"
      }
    }
  ],
  "search_after":[1584454145000]
}

scroll

ES5.0之前推荐的深度分页解决方案，但并不适合实时场景，在分页方面后续被search_after取代

1
2
3
4
5
6
7
8
9
10
11
12
13
第一次请求
POST  portal_news/_search?scroll=1m
{
  "query": {
    "range": {
      "pub_date": {
        "gte": "2020-01-01",
        "lte": "2020-03-20"
      }
    }
  },
  "size":100
}

1
2
3
4
5
6
7
第二次请求
POST /_search/scroll
{
  "scroll":"1m",
  "scroll_id": "DnF1ZXJ5VGhlbkZldGNoCAAAAAAA53jzFldqM3VMUGhLUWNPTVU5MVVwbkd6Z2cAAAAAAOSKdxZ5MFA1NGVhS1NDMjRRa1llOFRKMjRnAAAAAAEQobkWaDB3emVldXFTb3VnS05mci1JSnFnQQAAAAABEKG7Fmgwd3plZXVxU291Z0tOZnItSUpxZ0EAAAAAARAGWRZFM3I1eGMycVRxZTgyR2pZdG91Q2pRAAAAAADnePQWV2ozdUxQaEtRY09NVTkxVXBuR3pnZwAAAAAA5Ip2FnkwUDU0ZWFLU0MyNFFrWWU4VEoyNGcAAAAAARChuhZoMHd6ZWV1cVNvdWdLTmZyLUlKcWdB"
  
}

search_after 和scroll比较

  1. 当搜索请求返回单个“页”的结果时，scroll可以用来从单个搜索请求获取大量接口。甚至是所有结果，类似于rds中的游标， 但是维持scroll上线文代价高昂
  2. scroll的设计并不是为了实时用户请求，而是为了处理大量数据，例如索引的reindex， search_after的设计则是用于用户实时搜索的
  3. search_after则提供了一个活动的游标来避免这个问题，主要思想是使用上一页的结果帮助检索下一页
  4. search_after是无状态的

数据备份和恢复

ES数据的备份和恢复依赖于快照和仓库的机制，例如_snapshot/myback

1
2
3
4
5
6
7
8
9
10
先关闭索引
POST index_name/_close

异步调用
POST _snapshot/my_backup/snapshot_1/_restore
同步阻塞
POST _snapshot/my_backup/snapshot_1/_restore?wait_for_completion=true

最后打开索引
POST index_name/_open

1
2
监控快照状态
GET _snapshot/my_backup/snapshot_1/_status

别名

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
POST /_aliases?pretty
{
  "actions": [
    {
      "remove": {
        "index": "visitor_logs_2018",
        "alias": "visitor_logs"
      }
    },
    {
      "add": {
        "index": "visitor_logs_2018_01",
        "alias": "visitor_logs"
      }
    }
  ]
}

查询模版

查询定义

1
2
3
4
5
6
7
POST /text_basicinfo/_search/template
{
    "id":"text_basicinfo_zlcft_cyb",
    "params":{
      "company.trading_code":"300104"
    }
}

模板定义

1
2
3
4
5
6
7
8
PUT /_scripts/text_basicinfo_zlcft_cyb 
{
  "script": {
    "lang": "mustache",
    "source" : "{\"query\":{\"bool\":{\"must\":[{\"prefix\":{\"company.trading_code\":{\"value\":\"3\"}}},{\"term\":{\"company.secu_category_code_ii\":{\"value\":\"1001\"}}}{{#company.trading_code}},{\"term\":{\"company.trading_code\":\"{{company.trading_code}}\"}}{{/company.trading_code}},{\"term\":{\"company.exchange_code\":\"105\"}}],\"should\":[{\"prefix\":{\"text_category\":{\"value\":\"20\"}}},{\"prefix\":{\"text_category\":{\"value\":\"30\"}}}],\"minimum_should_match\":1}},\"sort\":[{\"pub_date\": {\"order\": \"desc\"}}]}"
  }
}
条件查询使用"{{#AA}} {{/AA}}"标识,由于{{}}条件语句的引入，原来的source变成一个非json结构，需要用""作为字符串包裹起来，并且做转义

使用内联模板调试

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
GET /text_basicinfo/_search/template
{
  "source": {
    "query": {
      "bool": {
        "must": [{
          "prefix": {
            "company.trading_code": {
              "value": "3"
            }
          }
        }, {
          "term": {
            "company.secu_category_code_ii": {
              "value": "1001"
            }
          }
        }, {
          "term": {
            "company.trading_code": "{{company.trading_code}}"
          }
        }, {
          "term": {
            "company.exchange_code": "105"
          }
        }],
        "should": [{
          "prefix": {
            "text_category": {
              "value": "20"
            }
          }
        }, {
          "prefix": {
            "text_category": {
              "value": "30"
            }
          }
        }],
        "minimum_should_match": 1
      }
    }
  },
  "params": {
    "company.trading_code": "300102"
  }
}

相似度(打分/排序)

定义了如何匹配打文档的打分方式，相似度是field级别的，这意味着在同一个mapping可以对不同的field设置不同的相似度模型，自定义相似度模型是一个高阶特性，内置的相似度模型基本可以满足大部分场景的需求
大部分内置的相似度模型或者是自定义的相似度模型通常具有以下配置项，在创建或者更新索引的时候设置，例如我们基于DFR自定义一个相似度模型：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
PUT /index
{
    "settings" : {
        "index" : {
            "similarity" : {
              "my_similarity" : {
                "type" : "DFR",
                "basic_model" : "g",
                "after_effect" : "l",
                "normalization" : "h2",
                "normalization.h2.c" : "3.0"
              }
            }
        }
    }
}
`

接下来我们可以在mapping中引用自定义相似度

1
2
3
4
5
6
PUT /index/_mapping/_doc
{
  "properties" : {
    "title" : { "type" : "text", "similarity" : "my_similarity" }
  }
}

可用的相似度模型有以下几种：

  • BM25 similarity，Type name: BM25

    1
    2
    3
    4
    基于TF/IDF模型，更适用于短字段，具有如下参数：
    k1 控制非线性词频饱和度，默认值为1.2
    b 控制了文档篇幅对于得分的影响程度,默认值为0.75
    discount_overlaps 的设置用于告诉es，在某个字段中，多少个分词出现在同一位置，是否应该影响长度的标准化，默认值是true。

  • DFR similarity Type name: DFR

  • IB similarity.
  • LM Dirichlet similarity.
  • LM Jelinek Mercer similarity.
  • Scripted similarity