码迷,mamicode.com
首页 > 其他好文 > 详细

Elasticsearch入门教程(五):Elasticsearch查询(一)

时间:2019-11-15 14:20:10      阅读:79      评论:0      收藏:0      [点我收藏+]

标签:nested   pen   效率   metadata   elastics   uil   期望   username   you   

原文:Elasticsearch入门教程(五):Elasticsearch查询(一)

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/vbirdbest/article/details/79228852
// 准备数据
PUT /shop/goods/1
{
 "name": "2017新款女装冬季外套ulzzang棉袄中长款棉衣韩版百搭棉服面包服",
 "desc": "",
 "price": 268,
 "quantity": 9267,
 "colors": [
   "绿色",
   "黑色"
 ],
 "is_discount": true,
 "create_date": "2018-01-31 12:10:30",
 "ip_addr": "192.168.10.1",
 "location": "39.92733,116.39507",
 "merchant": {
   "id": 999,
   "shop_name": "阿依莉旗舰店"
 },
 "params": [
   {
     "id": 1,
     "label": "型号",
     "value": "A30566"
   },
   {
     "id": 2,
     "label": "品牌",
     "value": "阿依莉"
   }
 ],
 "activity": "买一送一"
}

PUT /shop/goods/2
{
  "name": "2018春季长袖t恤女加绒加厚圆领宽松套头毛衣女装韩版学生毛线衣",
  "price": 108,
  "quantity": 268,
  "colors": [
    "白蓝红",
    "红白黑"
  ],
  "is_discount": false,
  "create_date": "2017-01-31 12:10:30",
  "ip_addr": "192.168.10.1",
  "location": "39.92733,116.39507",
  "merchant": {
    "id": 6666,
    "shop_name": "美特斯邦威旗舰店"
  },
  "params": [
    {
      "id": 1,
      "label": "型号",
      "value": "HWT8030"
    },
    {
      "id": 2,
      "label": "品牌",
      "value": "美特斯邦威"
    }
  ]
}

PUT /account/users/1
{
   "username": "xiaoming",
   "nickname": "小明的老师",
   "age": 6,
   "height": 1.68,
   "birthday": "2017-01-31",
   "hobbies": ["吃", "喝", "嫖", "赌"]
}

PUT /accounts/users/1
{
   "username": "teacher",
   "nickname": "谁能求姐",
   "age": 6,
   "height": 1.68,
   "birthday": "2017-01-31",
   "hobbies": ["批评小明"]
}
  • 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
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84

注意:_search即支持GET也支持POST

GET /_search  // 空查询:查询所有索引下的所有文档
GET /{index}/_search       // 查询某个索引下的前10条文档
GET /{index}/{type}/_search  // 查询某个索引下某个类型的前10条文档
  • 1
  • 2
  • 3
  • 4

// 返回结果
took字段表示该操作的耗时(单位为毫秒),
timed_out字段表示是否超时,
_shards:在查询中参与分片的总数,以及这些分片成功了多少个失败了多少个
total:返回记录数,本例是2条。
max_score:最高的匹配程度,本例是1.0。
hits:返回的记录组成的数组。
返回的记录中,每条记录都有一个_score字段,表示匹配的程序,默认是按照这个字段降序排列。

多索引,多类型
GET /{index1},{index2}/_search  // 查询多个索引下的文档
GET /{index*}/_search           // 索引支持*号通配符
GET /{index*},{index*}/_search
GET /_all/_search  // 和GET /_search效果一样,_all:表示所有索引

GET /{index}/{type1},{type2}/_search
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
// 示例
GET /_search
GET /shop/_search
GET /shop/goods/_search
POST /shop/goods/_search
GET /shop,account/_search
GET /account*/_search
GET /account*,sho*/_search
GET /_all/_search
GET /shop/goods,products/_search
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

查询字符串

查询字符串:就是在_search上使用GET参数的形式对search进行查询过滤,即将参数追加到路径上,此种方式有局限性,不够灵活

  • q: 通过加号+来指定查询中的某个字段必须包含某个值,默认是加号,通过减号-来指定文档中不能包含某个值,使用冒号将字段和值分隔,如 q=last_name:Smith,类似于关系型数据库中的where中的 like和not like 操作,
  • _source:用于指定要查询的字段,默认会返回文档中的所有字段,多个字段用逗号分隔
  • size: 设置search是返回的消息的条数,默认是10
  • from: 设置跳过的页数,默认是0,可以通过from和size来达到分页的目的
  • sort: 指定对那个字段进行什么排序,默认是按照相关性评分来降续排序的_score, 例如sort=date:desc&sort=_score
  • version: 版本号,用于更新和删除操作,当文档的版本等于指定的版本号时才能正常执行,否则会返回409 版本冲突 (乐观并发控制)
  • ersion_type=external 用于创建、修改、删除操作 外部版本号:当使用外部版本号是es会检查版本号是否比_version值小,如果小的话就正常执行,并将_version的值更改为外部的版本号, 例如version=5&version_type=external
  • timeout=10ms 指定超时时间,默认单位是毫秒ms,也可以指定秒s,例如1s
  • retry_on_conflict=n 参数来设置自动完成这项请求的次数,它的默认值是0,失败前重新尝试n次
  • scroll=1m 游标查询,保持游标查询窗口一分钟
// q好像对中文查询不出啦???可以通过其他方式进行查询
// 查询字段包含的字符串q=filed:value, 类似于SQL中的where last_name like ‘%Smith%‘
GET /{index}/{type}/_search?q=last_name:Smith                     

// 加号+:表示必须存在,每部分都是包含的意思, 类似于SQL中的where fist_name like ‘%join%‘ and like ‘%Smith%‘
// + 前缀表示必须与查询条件匹配。类似地, - 前缀表示一定不与查询条件匹配。
// 没有 + 或者 - 的所有其他条件都是可选的,类似于or——匹配的越多,文档就越相关
GET /{index}/{type}/_search?q=fist_name:join+last_name:Smith‘    

// -号代表不包含, 类似于SQL中的 where name not like ‘%join%‘   
GET /{index}/{type}/_search?q=-name:join   

// name包含join但tweet不包含jmary的, 类似于SQL中的 where name like ‘%join%‘ and tweet not like ‘%mary%‘                     
GET /{index}/{type}/_search?q=name:join+-tweet:mary     

// 查询所有索引所有类型所有字段中包含mary关键字的文档, _all:可以代表所有索引或者所有类型或者所有字段,     
// 每个文档都有一个隐形的_all字段,它的数据类型是文本型,它的值是以空格的形式将文档的所有字段的值拼接起来, 例如一个文档有三个值 age: 15, name:zhangsan, birthday:2018-09-15, 那么_all的值为“15 zhangsan 2018-09-15”
// _all会被分词,如果字段中包含日期,例如2018-09-15会被分析成2018,09, 15 三个词条(token)  
GET /{index}/{type}/_search?q=_all:mary  

// 如果不指定字段则默认是_all字段, _all字段是String类型                       
GET /{index}/{type}/_search?q=mary   

POST /shop/goods/_search?_source=name,price

POST /shop/goods/_search?timeout=10ms   

POST /shop/goods/_search?from=0&size=5    

POST /shop/goods/_search?sort=create_date:desc&sort=_score                    
  • 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

查询表达式DSL

使用查询领域特定语言(Query Domain Specific Language) 简称为DSL, 需要使用JSON作为主体,请求体查询

  • query

    • match:模糊匹配,类似于SQL中的like,示例{ “match” : { “field” : “keyword” }},
    • match_all:简单的匹配所有文档 {“match_all”: {}}
    • match_phrase: 对于短语或者段落进行精确匹配
    • match_phrase_prefix
    • multi_match: 在多个字段上反复执行相同查询
    • bool 用于表示复合语句,用于组合多个查询语句;将多查询组合成单一查询
      • must 必须匹配这些条件才能被包含进来,表示并且的关系
      • must_not 必须不 匹配这些条件才能被包含进来
      • should 如果满足这些语句中的任意语句,将增加 _score ,否则无任何影响。它们主要用于修正每个文档的相关性得分。
      • minimum_should_match:控制需要匹配的 should 语句的数量, 它既可以是一个绝对的数字,又可以是个百分比, 如 minimum_should_match: 2 或者 “minimum_should_match”: “75%”
      • filter 必须匹配,但它以不评分、过滤模式来进行。这些语句对评分没有贡献,只是根据过滤标准来排除或包含文档, filter只是简单的数据过滤,并不影响评分,因filter不计算评分,所以性能更好,请尽可能多的使用过滤式查询
        • exists 查找包含某个字段的文档
    • range 范围,可以使用大于gt、大于等于gte、小于lt、小于等于lte作为查询条件,可用于数字、日期类型、字符串
    • term 精确查询,对数值,日期,布尔,not_analyzed确切值字符串
    • terms 指定多个匹配值,如果字段包含其中的任何一个,都会返回文档,类似于SQL中的IN 操作
    • constant_score: 恒定分数,它将一个不变的常量评分应用于所有匹配的文档
    • wildcard: 通配符, ? 匹配任意字符, * 匹配 0 或多个字符
    • fuzzy: 模糊查询
    • dis_max:分离 最大化查询(Disjunction Max Query)
    • nested : 用于操作嵌套类型
  • highlight 高亮,匹配的结果会被 HTML字符包裹住,需要指定匹配的字段

  • aggs 聚合操作,类似SQL中的Group By
  • sort 排序
  • from 偏移量,类似于SQL中limit中的offset
  • size 返回数量,类似于SQL中limit中的count,可以通过from,size来达到分页的效果
// 使用DSL查询肯能条件很多,比较复杂,可以通过使用验证API来检查一个查询是否有效
GET /{index}/{type}/_validate/query?explain 
{  
   "query": {  
      ... 
    }  
} 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7

数据准备

DELETE /shop/goods/_all 删除所有文档

match 匹配查询

全文检索方式查询,类似于关系型数据库中的like操作,使用match时需要指定对那个字段进行全文检索,以及对应的关键字, 关键字可以指定一个也可以指定多个,指定多个时表示或者的关系 类似于SQL中的or的功能。语法:
{ "match" : { "field" : "keyword" }} 类似于SQL中的where filed like ‘%keyword%’
{ "match" : { "field" : "keyword1 keyword2" }} 类似于SQL中的where field like ‘%keyword1%’ or field like ‘%keyword2%’

示例:

// 查询name中包含“女装”的文档

GET /shop/goods/_search 
{
  "query": {
    "match": {
      "name": "女装"
    }
  }
}

// 多词查询 :使用空格隔离多个单词
// 查询name中包含“外套” 或者or 包含 “休闲” 的文档,多个关键字使用空格分隔,如果不指定operator默认是or
GET /shop/goods/_search 
{
  "query": {
    "match": {
      "name": "外套 休闲"
    }
  }
}

// "name": "外套 休闲" or 等价于bool中的should
GET /shop/goods/_search 
{
  "query": {
    "bool": {
      "should": [
        "match": { "name": "外套" },
        "match": { "name": "休闲" },
        ]
    }
  }
}

// 查询name中包含“外套” 并且 包含 “休闲” 的文档,多个关键字使用空格分隔
GET /shop/goods/_search 
{
  "query": {
    "match": {
      "name": "外套 休闲""operator": "and"
    }
  }
}

// "name": "外套 休闲" and 等价于bool中的must
GET /shop/goods/_search 
{
  "query": {
    "bool": {
      "must": [
        "match": { "name": "外套" },
        "match": { "name": "休闲" },
        ]
    }
  }
}

// 多词查询中使用or只需要满足一个即可,要求太低,使用and又必须所有词项都必须满足,要求又太高,
// 使用minimum_should_match折中一下,最小匹配:可以指定一个百分比,
// 例如指定4个词项,一个是词项是25%,设置成50%就是至少要满足2个词项
GET /shop/goods/_search
{
  "query": {
    "match": {
      "name": {
        "query": "春季 长袖 圆领 学生",
        "minimum_should_match": "50%"
      }
    }
  }
}

// 效果和上面一样,等价的
GET /shop/goods/_search
{
   "query" : {
      "bool": {
        "filter": {
          "bool" : {
              "should" : [
                 { "term" : {"name" : "春季"}}, 
                 { "term" : {"name" : "长袖"}}, 
                 { "term" : {"name" : "圆领"}}, 
                 { "term" : {"name" : "学生"}}
              ],
              "minimum_should_match": 2
           }
        }
      }
   }
}

// 查询日期
GET /shop/goods/_search 
{
  "query": {
    "match": {
      "create_date": "2018-01-31"
    }
  }
}
  • 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
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81
  • 82
  • 83
  • 84
  • 85
  • 86
  • 87
  • 88
  • 89
  • 90
  • 91
  • 92
  • 93
  • 94
  • 95
  • 96
  • 97
  • 98
  • 99
  • 100
  • 101
  • 102

match一般用于用引号括起来的值,如文本,日期,如果将match用于布尔或者数字等数据类型就变成精确匹配了,而不是全文检索或者模糊匹配了
如果在一个精确值的字段上使用match,例如数字、日期、布尔或者一个 not_analyzed 字符串字段,那么它将会精确匹配给定的值:

match_all

简单的匹配所有文档

GET /shop/goods/_search 
{
  "query": {
    "match_all": {}
  }
}

// 上面简写成这样,效果是一样的 
GET /shop/goods/_search 
{}

// 同样也可以去掉{},更加简洁
GET /shop/goods/_search 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13

match_phrase

对于短语或者段落进行精确匹配,

// match如果对一小段文本进行查询,match首先对字段值进行分词,然后对分词进行匹配,相当于SQL中的name like ‘%女装%‘ or name like ‘%冬季%‘ or name like ‘%外套%‘
GET /shop/goods/_search 
{
  "query": {
    "match": {
      "name": "女装冬季外套"
    }
  }
}


GET /shop/goods/_search 
{
  "query": {
    "match_phrase": {
      "name": "女装冬季外套"
    }
  }
}

// slop:让相对词序位置不那么严格
// 注意上面使用的是“女装冬季外套”,而现在使用的是“套女装冬季”, slop:允许每个词放宽的间隔
// 尽管词语的顺序不正确,查询仍然能匹配,因为我们为它设置了足够高的slop值使匹配时的词序有更大的灵活性。
GET /shop/goods/_search 
{
  "query": {
    "match_phrase": {
      "name": {
            "query": "外套女装冬季",
            "slop":  10
        }
    }
  }
}
  • 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

match_phrase_prefix

match_phrase_prefix与match_phrase是一样的,只是它允许在文本的最后一项中使用前缀匹配。

可以用于即时搜索(instant search) 或 输入即搜索(search-as-you-type),例如,如果用户输入 johnnie walker bl ,我们希望在它们完成输入搜索条件前就能得到:Johnnie Walker Black Label 和 Johnnie Walker Blue Label 。

GET /shop/goods/_search 
{
  "query": {
    "match_phrase_prefix": {
      "name": "女装冬季外套"
    }
  }
}


// slop:让相对词序位置不那么严格
// 注意上面使用的是“女装冬季外套”,而现在使用的是“套女装冬季”, slop:允许每个词放宽的间隔
// 尽管词语的顺序不正确,查询仍然能匹配,因为我们为它设置了足够高的slop值使匹配时的词序有更大的灵活性。
GET /shop/goods/_search 
{
  "query": {
    "match_phrase_prefix": {
      "name": {
            "query": "外套女装冬季",
            "slop":  10
      }
    }
  }
}

  • 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

prefix 查询存在严重的资源消耗问题,短语查询的这种方式也同样如此。前缀 a 可能会匹配成千上万的词,这不仅会消耗很多系统资源,而且结果的用处也不大。

索引时输入即搜索

## edge_ngram 自定义过滤器、分词器
PUT /my_index
{
    "settings": {
        "number_of_shards": 1, 
        "analysis": {
            "filter": {
                "autocomplete_filter": { 
                    "type":     "edge_ngram",
                    "min_gram": 1,
                    "max_gram": 20
                }
            },
            "analyzer": {
                "autocomplete": {
                    "type":      "custom",
                    "tokenizer": "standard",
                    "filter": [
                        "lowercase",
                        "autocomplete_filter" 
                    ]
                }
            }
        }
    }
}

## 测试分词
GET /my_index/_analyze
{
  "analyzer": "autocomplete",
  "text": "quick brown"
}

PUT /my_index/_mapping/my_type
{
    "my_type": {
        "properties": {
            "name": {
                "type":     "text",
                "analyzer": "autocomplete",  ## 使用自定义的分词器
                "search_analyzer": "standard" ## 配置查询对应的分词器
            }
        }
    }
}

POST /my_index/my_type/_bulk
{ "index": { "_id": 1            }}
{ "name": "Brown foxes"    }
{ "index": { "_id": 2            }}
{ "name": "Yellow furballs" }

## 搜索
GET /my_index/my_type/_search
{
    "query": {
        "match": {
            "name": {
                "query":    "brown fo"
            }
        }
    }
}
  • 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
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64

multi_match

多个字段上使用相同的值作为查询条件

GET /shop/goods/_search
{
  "query": {
    "multi_match": {
      "query": 268,
      "fields": ["price", "quantity"]
    }
  }
}

// 两者效果相同
GET /shop/goods/_search
{
  "query": {
    "bool": {
      "should": [
        { "term": { "price": { "value": 268 } } },
        { "term": { "quantity": { "value": 268 } } }
      ]
    }
  }
}

// 查询字段名称的模糊匹配
// 字段名称可以用模糊匹配的方式给出:任何与模糊模式正则匹配的字段都会被包括在搜索条件中,
例如可以使用以下方式同时匹配 book_title 、 chapter_title 和 section_title (书名、章名、节名)这三个字段:

{
    "multi_match": {
        "query":  "Quick brown fox",
        "fields": "*_title"
    }
}

// 提升单个字段的权重
// 可以使用 ^ 字符语法为单个字段提升权重,在字段名称的末尾添加 ^boost ,其中 boost 是一个浮点数:
// chapter_title 这个字段的 boost 值为 2 ,而*_title 字段的默认 boost 值为 1
{
    "multi_match": {
        "query":  "Quick brown fox",
        "fields": [ "*_title", "chapter_title^2" ] (1)
    }
}

  • 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

constant_score 常量分数

通常当查找一个精确值的时候,我们不希望对查询进行评分计算。只希望对文档进行包括或排除的计算,所以我们会使用 constant_score 查询以非评分模式来执行 term 查询并以一作为统一评分。

它将一个不变的常量评分应用于所有匹配的文档。它被经常用于你只需要执行一个 filter 而没有其它查询(例如,评分查询)的情况下。可以使用它来取代只有 filter 语句的 bool 查询。在性能上是完全相同的,但对于提高查询简洁性和清晰度有很大帮助. 这种方式可以用来取代只有 filter 语句的 bool 查询


GET /shop/goods/_search 
{
  "query": {
    "constant_score": {
      "filter": {
        "term": {
          "price": 268.00
        }
      }
    }
  }
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13

查询置于 filter 语句内不进行评分或相关度的计算,所以所有的结果都会返回一个默认评分 1

prefix 前缀查询

前缀查询:要查询的字段必须没有分词

默认状态下, prefix 查询不做相关度评分计算,它只是将所有匹配的文档返回,并为每条结果赋予评分值 1 。它的行为更像是过滤器而不是查询。 prefix 查询和 prefix 过滤器这两者实际的区别就是过滤器是可以被缓存的,而查询不行。

prefix 查询或过滤对于一些特定的匹配是有效的,但使用方式还是应当注意。当字段中词的集合很小时,可以放心使用,但是它的伸缩性并不好,会对我们的集群带来很多压力。可以使用较长的前缀来限制这种影响,减少需要访问的量。

PUT /my_index
{
    "mappings": {
        "address": {
            "properties": {
                "postcode": {
                    "type":  "keyword"
                }
            }
        }
    }
}

PUT /my_index/address/1
{ "postcode": "W1V 3DG" }

PUT /my_index/address/2
{ "postcode": "W2F 8HW" }

PUT /my_index/address/3
{ "postcode": "W1F 7HW" }

PUT /my_index/address/4
{ "postcode": "WC1N 1LZ" }

PUT /my_index/address/5
{ "postcode": "SW5 0BE" }

// prefix 查询
GET /my_index/address/_search
{
  "query": {
    "prefix": {
      "postcode": {
        "value": "W1"
      }
    }
  }
}
  • 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

wildcard 和 regexp

与 prefix 前缀查询的特性类似, wildcard 通配符查询也是一种底层基于词的查询,与前缀查询不同的是它允许指定匹配的正则式。它使用标准的 shell 通配符查询: ? 匹配任意字符, * 匹配 0 或多个字符。

GET /my_index/address/_search
{
    "query": {
        "wildcard": {
            "postcode": "W?F*HW" 
        }
    }
}

// 词必须以 W 开头,紧跟 0 至 9 之间的任何一个数字,然后接一或多个其他字符
GET /my_index/address/_search
{
    "query": {
        "regexp": {
            "postcode": "W[0-9].+" 
        }
    }
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18

wildcard 和 regexp 查询的工作方式与 prefix 查询完全一样,它们也需要扫描倒排索引中的词列表才能找到所有匹配的词,然后依次获取每个词相关的文档 ID ,与 prefix 查询的唯一不同是:它们能支持更为复杂的匹配模式。

这也意味着需要同样注意前缀查询存在性能问题,对有很多唯一词的字段执行这些查询可能会消耗非常多的资源,所以要避免使用左通配这样的模式匹配(如: *foo 或 .*foo 这样的正则式)。

数据在索引时的预处理有助于提高前缀匹配的效率,而通配符和正则表达式查询只能在查询时完成,尽管这些查询有其应用场景,但使用仍需谨慎。

prefix 、 wildcard 和 regexp 查询是基于词操作的,如果用它们来查询 analyzed 字段,它们会检查字段里面的每个词,而不是将字段作为整体来处理。


range

用于查询一个区间,一般用于日期和数值,支持 gt、gte、lt、lte, 示例{“range”: { “age”: { “gte”: 20, “lt”:30 }}} 类似于SQL中的 wher age >= 20 and age < 30

GET /shop/goods/_search
{
  "query": {
    "range": {
      "price": {
        "gt": 200,
        "lte": 500
      }
    }
  }
}

// 日期类型
GET /shop/goods/_search
{
  "query": {
    "range": {
      "create_date": {
        "gt" : "2014-01-01 00:00:00",
        "lt" : "2014-01-07 00:00:00"
      }
    }
  }
}

// 日期计算:过去一小时
GET /shop/goods/_search
{
  "query": {
    "range": {
      "create_date": {
        "gt" : "now-1h"
      }
    }
  }
}

// 日期计算:早于 2014 年 1 月 1 日加 1 月(2014 年 2 月 1 日 零时)
GET /shop/goods/_search
{
  "query": {
    "range": {
      "create_date": {
        "gt" : "2014-01-01 00:00:00",
        "lt" : "2014-01-01 00:00:00||+1M"
      }
    }
  }
}

// 作用于字符串,性能相对较慢
"range" : {
    "title" : {
        "gte" : "a",
        "lt" :  "b"
    }
}
  • 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
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57

term

精确查询:用于精确值匹配,对数值,日期,布尔,not_analyzed确切值字符串, term 查询对于输入的文本不 分析 ,所以它将给定的值进行精确查询。

GET /shop/goods/_search
{
  "query": {
    "term": {
      "is_discount": {
        "value": true
      }
    }
  }
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10

terms

同term查询,但是它允许指定多个匹配值,一般用于数组,如果字段包含其中的任何一个,都会返回文档, 类似于where tag IN (‘value1’, ‘value2’, ‘value3’) 例如:{ “terms”: { “tag”: [ “search”, “full_text”, “nosql” ] }}

GET /shop/goods/_search
{
  "query": {
    "terms": {
      "colors": [
        "白蓝红",
        "绿色"
      ]
    }
  }
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11

exists

对于相同类型的文档,可能有的文档有某个字段,有的文档没有某个字段,查找包含或者不包含某个字段的文档, 例如: {“exists”: { “field”: “title” }} ,exists 用于查找那些指定字段中是否有值 , 相当于SQL中的IS NOT NULL

null, [] (空数组)和 [null] 所有这些都是等价的,它们无法存于倒排索引中

这些查询经常用于某个字段有值的情况和某个字段缺值的情况。

// 存在某个字段
GET /shop/goods/_search
{
  "query": {
    "bool": {
      "filter": {
        "exists": {
          "field": "activity"
        }
      }
    }
  }
}

// 不存在某个字段
GET /shop/goods/_search
{
  "query": {
    "bool": {
      "must_not": {
        "exists": {
          "field": "activity"
        }
      }
    }
  }
}

POST /my_index/posts/_bulk
{ "index": { "_id": "1"              }}
{ "tags" : ["search"]                }  
{ "index": { "_id": "2"              }}
{ "tags" : ["search", "open_source"] }  
{ "index": { "_id": "3"              }}
{ "other_field" : "some data"        }  
{ "index": { "_id": "4"              }}
{ "tags" : null                      }  
{ "index": { "_id": "5"              }}
{ "tags" : ["search", null]          }

以上文档集合中 tags 字段对应的倒排索引如下:
Token DocIDs
open_source 2
search 1,2,5

1. tags 字段有 1 个值。
2. tags 字段有 2 个值。
3. tags 字段缺失。
4. tags 字段被置为 null5. tags 字段有 1 个值和 1null// 1,2,5 满足条件
GET /my_index/posts/_search
{
    "query" : {
        "constant_score" : {
            "filter" : {
                "exists" : { "field" : "tags" }
            }
        }
    }
}
  • 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
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64

highlight:高亮

匹配的结果会被 HTML字符包裹住,需要指定匹配的字段,”highlight”: {“fields” : {“about” : {}}}

// 高亮: 匹配的结果会被 <em></em> HTML字符包裹住:
curl -i -H ‘Content-Type: application/json‘  -XGET ‘http://localhost:9200/megacorp/employee/_search‘ -d ‘
{
    "query" : {
        "match_phrase" : {
            "about" : "rock climbing"
        }
    },
    "highlight": {
        "pre_tags" : ["<font color=‘red‘>"],
        "post_tags" : ["</font>"],
        "fields" : {
            "about" : {}
        }
    }
}‘
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16

sort

排序,可以指定一个或者多个字段排序,多个字段使用数组包围,例如:”sort”: { “date”: { “order”: “desc” }}

// 排序,默认情况下是按照相关性评分排序的,最相关的文档排在最前, 默认按_score排序的
// 多级排序,使用date, _score排序
GET /_search  
{  
    "query" : {  
        "bool" : {  
            "must":   { "match": { "tweet": "manage text search" }},  
            "filter" : { "term" : { "user_id" : 2 }}  
        }  
    },  
    "sort": [  
        { "date":   { "order": "desc" }},  
        { "_score": { "order": "desc" }},
        { "ids" : { "order": "asc", "mode":  "min"}}  
    ]  
}  

mode:一般用于数组,可以使用minmaxavg 或是 sum,统计计算数组的指定值排序
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18

对字符串排序,sort对字符串排序需要使用到原始值raw,正常情况下文本可能会使用分词器进行分词,而分词器会影响正常的排序,这时可以对同一个字段设置两种类型,对文本设置成text类型,并设置分词器,如果要搜索的话使用text类型字段,然后再为该字段设置一个原始值,该原始值raw字段的fields的数据类型设置为keyword,关键字数据类型是不分词的,不分词的字段可以作为字符串的排序

// fields 多字段:相当于对同一个字段值起不同的名字,赋予这个字段不同的属性(如类型不同,分词器不同等)
PUT /school
{
  "mappings": {
    "students": {
      "properties": {
        "name": {
          "type": "text",
          "analyzer": "ik_max_word",
          "fields": {
            "raw": {
              "type": "keyword"
            }  
          }
        }
      }
    }
  }
}

// _score 和 max_score 字段都是 null 。计算 _score 的花销巨大,通常仅用于排序; 我们并不根据相关性排序,所以记录 _score 是没有意义的。如果无论如何你都要计算 _score , 你可以将 track_scores 参数设置为 true
GET /school/students/_search 
{
  "query": { "match": { "name": "abc" } }, 
  "sort": [ { "name.raw": { "order": "desc" } } ]
}

// 强制计算评分
GET /school/students/_search 
{
  "track_scores": true,
  "query": { "match": { "name": "abc" } }, 
  "sort": [ { "name.raw": { "order": "desc"} } ]
}
  • 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

from

偏移量,类似于SQL中limit中的offset

size

返回数量,类似于SQL中limit中的count,可以通过from,size来达到分页的效果

GET /shop/goods/_search
{
  "from": 0,
  "size": 20
}
  • 1
  • 2
  • 3
  • 4
  • 5

游标查询Scroll

使用from, size做分页不能分页太深,太深对性能营销较大,一般获取前1000条数据就算深了,游标查询用于解决深度分页带来的性能问题。

scroll 查询可以用来对Elasticsearch有效地执行大批量的文档查询,而又不用付出深度分页那种代价。游标查询允许我们 先做查询初始化,然后再批量地拉取结果。 这有点儿像传统数据库中的 cursor 。游标查询会取某个时间点的快照数据,查询初始化之后索引上的任何变化会被它忽略。 它通过保存旧的数据文件来实现这个特性,结果就像保留初始化时的索引 ‘视图’ 一样。

深度分页的代价根源是结果集全局排序,如果去掉全局排序的特性的话查询结果的成本就会很低。 游标查询用字段_doc来排序。 这个指令让 Elasticsearch 仅仅从还有结果的分片返回下一批结果。启用游标查询可以通过在查询的时候设置参数 scroll 的值为我们期望的游标查询的过期时间,游标查询的过期时间会在每次做查询的时候刷新,所以这个时间只需要足够处理当前批的结果就可以了,而不是处理查询结果的所有文档的所需时间。 这个过期时间的参数很重要,因为保持这个游标查询窗口需要消耗资源,所以我们期望如果不再需要维护这种资源就该早点儿释放掉。 设置这个超时能够让 Elasticsearch 在稍后空闲的时候自动释放这部分资源。

// 保持游标查询窗口一分钟
// 关键字 _doc 是最有效的排序顺序。
GET /shop/goods/_search?scroll=1m
{
  "query": {"match_all": {}},
  "sort": ["_doc"],
  "size": 1000
}

// 这个查询的返回结果包括一个字段 _scroll_id, 它是一个base64编码的长字符串 。 现在我们能传递字段 _scroll_id 到 _search/scroll 
{
  "_scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAAMoFmQ0clZDNEg4UWYtYTBzVTg0QWRFdmcAAAAAAAADKRZkNHJWQzRIOFFmLWEwc1U4NEFkRXZnAAAAAAAAAyoWZDRyVkM0SDhRZi1hMHNVODRBZEV2ZwAAAAAAAAMrFmQ0clZDNEg4UWYtYTBzVTg0QWRFdmcAAAAAAAADLBZkNHJWQzRIOFFmLWEwc1U4NEFkRXZn",
  "took": 1,
  "timed_out": false,
  ...
}

// 查询接口获取下一批结果:
GET /_search/scroll
{
  "scroll": "1m",
  "scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAAKbFmQ0clZDNEg4UWYtYTBzVTg0QWRFdmcAAAAAAAACnBZkNHJWQzRIOFFmLWEwc1U4NEFkRXZnAAAAAAAAAp0WZDRyVkM0SDhRZi1hMHNVODRBZEV2ZwAAAAAAAAKeFmQ0clZDNEg4UWYtYTBzVTg0QWRFdmcAAAAAAAACnxZkNHJWQzRIOFFmLWEwc1U4NEFkRXZn"
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • 16
  • 17
  • 18
  • 19
  • 20
  • 21
  • 22
  • 23
  • 24

这个游标查询返回的下一批结果。 尽管我们指定字段 size 的值为1000,我们有可能取到超过这个值数量的文档。 当查询的时候, 字段 size 作用于单个分片,所以每个批次实际返回的文档数量最大为 size * number_of_primary_shards.

注意游标查询每次返回一个新字段 _scroll_id。每次我们做下一次游标查询, 我们必须把前一次查询返回的字段 _scroll_id 传递进去。 当没有更多的结果返回的时候,我们就处理完所有匹配的文档了。

bool

布尔查询,这是一个很重要的查询,它可以将其它多种查询封装成一个大的查询,可以使用逻辑操作符(类似于sql中的and、not、or)来组装各个条件, 这是个复合过滤器(compound filter) ,它可以接受多个其他过滤器作为参数,并将这些过滤器结合成各式各样的布尔(逻辑)组合

用于表示复合语句,用于组合多个查询语句;将多查询组合成单一查询,bool可以放到query下面,也可以嵌套在某个子条件(must、should、must_not)里, 通过嵌套可以构造出更加复杂的过滤条件。

  • must: 必须匹配这些条件才能被包含进来。 表示并且的关系,与 SQL中的AND 等价,例如{"must": [{"match": {"desc": "xxx"}}, {"term": { "quantity": 999}}]},类似于SQL中的where desc like ‘%xxx%‘ and quantity = 999
  • must_not: 必须不匹配这些条件才能被包含进来, 是对must的取反操作,与SQL中的 != 或者<> 等价, where status != 0
  • should 至少有一个语句要匹配, 与 SQL中的 OR 等价,是一个数组,可以有多个值,如果满足这些语句中的任意语句,将增加_score的值, should的作用:or逻辑,如果满足条件评分_score更高
  • filter:必须匹配,以过滤模式来进行。这些语句对评分没有贡献,只是根据过滤标准来排除或包含文档, filter只是简单的数据过滤,并不影响评分
  • minimum_should_match

bool 查询会为每个文档计算相关度评分 _score ,再将所有匹配的 must 和 should 语句的分数 _score 求和,最后除以 must 和 should 语句的总数。

must_not 语句不会影响评分;它的作用只是将不相关的文档排除。

所有must语句必须匹配,所有must_not语句都必须不匹配,经测试至少有一个should需要匹配的(在should中写两个条件,每天条件都不满足条件,结果没有任何文档满足),当没有 must 语句的时候,至少有一个 should 语句必须匹配。

GET /shop/goods/_search 
{
  "query": {
    "bool": {
      "must": [
        {"term": {
          "quantity": {
            "value": 999
          }
        }}
      ], 
      "must_not": [
        {
          "term": {
            "quantity": {
              "value": 9267
            }
          }
        }
      ],
      "should": [
        {
          "term": {
            "is_discount": {
              "value": true
            }
          }
        }
      ],
      "filter": {
        "range": {
          "price": {
            "gte": 7777,
            "lte": 9999
          }
        }
      }
    }
  }
}
  • 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
// filter中也可以嵌套bool查询,这样内部的bool查询就不参与评分了
// bool中的must must_not should 等会计算评分的,如果不希望计算评分,可将bool放入到filter中,这样既不计算评分又可以使用bool中的逻辑
// 直接使用bool中的filter和将bool再次嵌入到filter中都不计算评分
GET /shop/goods/_search 
{
    "query": {
        "bool": {
              "must":     { "match": { "title": "how to make millions" }},
              "must_not": { "match": { "tag":   "spam" }},
              "should": [
                  { "match": { "tag": "starred" }}
              ],
              "filter": {
                "bool": { 
                    "must": [
                        { "range": { "date": { "gte": "2014-01-01" }}},
                        { "range": { "price": { "lte": 29.99 }}}
                    ],
                    "must_not": [
                        { "term": { "category": "ebooks" }}
                    ]
                }
              }
          }
    }
}


// 就像我们能控制 match 查询的精度 一样,我们可以通过 minimum_should_match 参数控制需要匹配的
// should 语句的数量, 它既可以是一个绝对的数字,又可以是个百分比:
// 这个查询结果会将所有满足以下条件的文档返回: 
// title 字段包含 "brown" AND "fox" 、 "brown" AND "dog" 或 "fox" AND "dog" 。
// 如果有文档包含所有三个条件,它会比只包含两个的文档更相关。
GET /my_index/my_type/_search
{
  "query": {
    "bool": {
      "should": [
        { "match": { "title": "brown" }},
        { "match": { "title": "fox"   }},
        { "match": { "title": "dog"   }}
      ],
      "minimum_should_match": 2 
    }
  }
}

// boost 参数被用来提升一个语句的相对权重( boost 值大于 1 )或降低相对权重( boost 值处于 0 到 1 之间),
// 但是这种提升或降低并不是线性的,换句话说,如果一个 boost 值为 2 ,并不能获得两倍的评分 _score 。
// 通过指定 boost 来控制任何查询语句的相对的权重, boost 的默认值为 1 ,大于 1 会提升一个语句的相对权重。
// 更高的 boost 值为我们带来更高的评分 _score
GET /_search
{
    "query": {
        "bool": {
            "must": {
                "match": {  
                    "content": {
                        "query":    "full text search",
                        "operator": "and"
                    }
                }
            },
            "should": [
                { "match": {
                    "content": {
                        "query": "Elasticsearch",
                        "boost": 3 
                    }
                }},
                { "match": {
                    "content": {
                        "query": "Lucene",
                        "boost": 2 
                    }
                }}
            ]
        }
    }
}
  • 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
  • 48
  • 49
  • 50
  • 51
  • 52
  • 53
  • 54
  • 55
  • 56
  • 57
  • 58
  • 59
  • 60
  • 61
  • 62
  • 63
  • 64
  • 65
  • 66
  • 67
  • 68
  • 69
  • 70
  • 71
  • 72
  • 73
  • 74
  • 75
  • 76
  • 77
  • 78
  • 79
  • 80
  • 81

过滤查询:不需要评分,性能更好,对结果进行缓存
评分查询:需要评分,评分比较费力,不对结果进行缓存
如何选择查询与过滤? 通常的规则是,使用查询(query)语句来进行 全文搜索或者其它任何需要影响相关性得分的搜索。除此以外的情况都使用过滤(filters)。

aggs

聚合操作,类似SQL中的Group By, 支持的聚合类型有avg, min, max, sum, rang 等,也可以对地理位置进行聚合

如果要对一个字段进行聚合,要保证这个字段的fielddata设置为true

PUT /{index}/_mapping/{type}
{
  "properties": {
    "FILED": {
      "type": "text",
      "fielddata": true
    }
  }
}
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8
  • 9
// 统计数组中每个元素出现的次数,中文有问题,现在中文分词是按单个字分词的,估计需要指定对该字段不分词
GET /shop/goods/_search
{
  "aggs": {
    "xxx": {
      "terms": {
        "field": "colors",
        "size": 10
      }
    }
  }
}

// aggs可以嵌套在aggs中使用
// 嵌套聚合,分级汇总,在聚合中可以进行再聚合,意思是对分组的文档进行其他聚合,而不是对聚合结果进行处理
GET /shop/goods/_search
{
  "aggs": {
    "xxx": {
      "terms": {
        "field": "colors",
        "size": 10
      },
      "aggs": {
        "yyy": {
          "avg": {
            "field": "price"
          }
        }
      }
    }
  }
}
  • 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

_mget

multi-get,通过docs数组作为参数指定多个doc来获取多个文档,每个doc可以分别指定索引、类型、id,文档或者api中必须包含index/type/id

// 路径中不包含index、type、id
GET /_mget 
{
   "docs" : [
      {
         "_index" : "shop",
         "_type" :  "goods",
         "_id" :    2
      },
      {
         "_index" : "account",
         "_type" :  "users",
         "_id" :    1,
         "_source": "nickname"
      }
   ]
}

// 路径中包含index、type, 如果参数中没有指定index、type就使用路径中的,如果参数中明确指定了,就使用参数中的索引和类型
GET /{index}/{type}/_mget
{
   "docs" : [
      { "_id" : 2 },
      { "_type" : "account", "_id" : 1 }
   ]
}

// 路径中指定了索引和类型,通过ids数组指定多个id值
GET /{index}/{type}/_mget‘
{
   "ids" : [ "2", "1" ]
}
  • 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

_bulk

批量操作:将多个操作封装成一个操作,一次执行多个动作(create,index, update以及delete),并返回每个执行结果.
可以通过_bulk来执行批量插入、批量更新等操作

POST _bulk的请求主体的格式稍微有些不同:

{ action: { metadata }}\n
{ request body        }\n
{ action: { metadata }}\n
{ request body        }\n
...
  • 1
  • 2
  • 3
  • 4
  • 5

它通过换行符(\n)连接到一起,最后一行也要有\n,每行一定要以换行符(\n)结尾, 包括最后一行 。这些换行符被用作一个标记,可以有效分隔行,这些行不能包含未转义的换行符,因为他们将会对解析造成干扰

  • action 必须是以下选项之一:
    • create:如果文档不存在,那么就创建它, 相当于 PUT /{index}/{type}/{id}/_create
    • index:创建一个新文档或者替换一个现有的文档, 相当于 PUT /{index}/{type}/{id}
    • update:部分更新一个文档, 即局部更新文档中的个别字段,相当于 /{index}/{type}/{id}/_update
    • delete:删除一个文档,删除操作不需要指定请求体,delete操作没有请求体,它紧接着另一个行为;记得最后一个换行符
  • metadata 每个动作需要的参数,json格式的,应该指定被索引、创建、更新或者删除的文档的_index,_type和 _id

每个子请求都是独立执行,因此某个子请求的失败不会对其他子请求的成功与否造成影响。 如果其中任何子请求失败,最顶层的 error 标志被设置为 true ,并且在相应的请求报告出错误明细
这也意味着 bulk 请求不是原子的: 不能用它来实现事务控制。每个请求是单独处理的,因此一个请求的成功或失败不会影响其他的请求

POST /_bulk
{ "create": { "_index": "shop", "_type": "goods", "_id": 123 }}
{ "name":    "My first blog post" }
{ "index":  { "_index": "shop", "_type": "goods" }}
{ "name":    "My second blog post" }
{ "update": { "_index": "shop", "_type": "goods", "_id": 123, "retry_on_conflict" : 3} }
{ "doc" : {"title" : "My updated blog post"} }
{ "delete": { "_index": "shop", "_type": "goods", "_id": 1234 }} 
  • 1
  • 2
  • 3
  • 4
  • 5
  • 6
  • 7
  • 8

我的微信公众号:

技术图片

Elasticsearch入门教程(五):Elasticsearch查询(一)

标签:nested   pen   效率   metadata   elastics   uil   期望   username   you   

原文地址:https://www.cnblogs.com/lonelyxmas/p/11865863.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!