[TOC]
## 1\. query string search查询
> * 结构化查询，需要传递query参数，{}表示查询子句匹配所有的,所以叫query string search
基本命令模板
```
GET /索引库名/_search
{
"query":{
"查询类型":{
"查询条件":"查询条件值"
}
}
}
```
### 1.1 match\_all
> 使用match\_all查询所有文档，是没有查询条件下的默认语句
~~~
GET _search
{
"query": {
"match_all" : {}
}
}
~~~
### 1.2 match
1. 匹配年龄是32的文档
~~~
GET _search
{
"query": {
"match": {
"age" : 32
}
}
}
~~~
### 1.3 match\_phrase
> 精准匹配: 不会对搜索语句不会分词，短语匹配
> 像匹配查询一样，但用于匹配确切的短语或单词接近度匹配。
> match\_phrase查询会分析文本，并从被分析的文本中创建短语查询
> 例如hello world，只能匹配包含hello world的文本
* 返回Java spark短语的文档
~~~
GET /forum/article/_search
{
"query": {
"match_phrase": {
"content": "java spark"
}
}
}
~~~
* slop 参数（proximity match）
通过slop参数，控制短语的间隔，近似匹配
~~~
GET /forum/article/_search
{
"query": {
"match_phrase": {
"content": {
"query": "java spark",
"slop":10 # java和spark的最大距离，单词的个数
}
}
}
}
~~~
### 1.4 match\_phrase\_prefix
> match\_phrase\_prefix与match\_phrase相同，但它允许在文本中的最后一个术语上使用前缀匹配。
> 它接受与短语类型相同的参数。 此外，它还接受一个max\_expansions参数（默认值50），可以控制最后一个术语将扩展多少个后缀。 强烈建议将其设置为可接受的值来控制查询的执行时间。 例如：
~~~
GET /_search
{
"query": {
"match_phrase_prefix" : {
"message" : {
"query" : "quick brown f",
"max_expansions" : 50
}
}
}
}
~~~
> * 这个查询会构建成 "quick brown" +f 开头的全文索引， "max\_expansions" : 50表示它查看排序的词典字典，以查找以f开头的前50个术语，并将这些术语添加到短语查询中。这样可能导致以f开头的单词，在词典顺序排在50以后的不会被快速的查找到，但是随着用户或者f后边的字符增多而查找到。
> 无论是全文搜索还是精准查询，都基本上使用到match
### 1.4 multi\_match
> 1. 使用math的基础上，加入多个字段匹配
~~~
GET _search
{
"query": {
"multi_match": {
"query": "like", # 查询语句
"fields": ["interests","about"] # 字段
}
}
}
~~~
> 2. 可以使用通配符指定字段
~~~
GET _search
{
"query": {
"multi_match": {
"query": "like",
"fields": ["interests","*t"] # 匹配以t结尾的字段
}
}
}
~~~
> 3. 通过^n来增加字段的权重
~~~
GET _search
{
"query": {
"multi_match": {
"query": "music",
"fields": ["interests","about^3"]
}
}
}
~~~
> * 这里会增加about在匹配结果时的权重，也就是说about字段中如果包含music，这个文档在查询的得到的结果中会比较靠前
> 4. multi查询的类别
> 4.1 best\_fields（multi\_match默认类型）
> 查找与任何字段匹配的文档，但使用最佳字段中的\_score，当搜索在同一字段中去寻找的多个单词时，best\_fields类型最为有用。 例如，一个领域的“brown fox”在一个领域比“brown”更有意义，而另一个领域的“fox”更有意义。
> best\_fields类型为每个字段生成匹配查询，并将其包装在dis\_max查询中，以找到单个最佳匹配字段。 例如，这个查询：
~~~
GET /_search
{
"query": {
"multi_match" : {
"query": "brown fox",
"type": "best_fields",
"fields": [ "subject", "message" ],
"tie_breaker": 0.3
}
}
}
~~~
会被转换成dis\_max,包含两个math查询
~~~
GET /_search
{
"query": {
"dis_max": {
"queries": [
{ "match": { "subject": "brown fox" }},
{ "match": { "message": "brown fox" }}
],
"tie_breaker": 0.3 # 给其他不太精准的匹配一个权值
}
}
}
~~~
通常，best\_fields类型使用单个最佳匹配字段的分数，但是如果指定了tie\_breaker，则它计算得分如下：
1. 来自于匹配最精准的字段的得分
2. 加上所有其他匹配字段的tie\_breaker \* \_score
* best\_fields和most\_fields类型是以字段为中心的 - 它们会为每个字段生成匹配查询。 这意味着操作符和minimum\_should\_match参数将单独应用于每个字段，这可能不是您想要的。
~~~
GET /_search
{
"query": {
"multi_match" : {
"query": "Will Smith",
"type": "best_fields",
"fields": [ "first_name", "last_name" ],
"operator": "and"
}
}
}
~~~
会类似这样的为每个字段产生查询，并且将参数分别用到两个字段,will smith 被拆分，并且运用了and,会查找first\_name和last\_name 中含有 will Smith的文档，并且是精准匹配（表示两个都得有）
~~~
(+first_name:will +first_name:smith) # 大写都转小写了
| (+last_name:will +last_name:smith) # 大写都转小写了
~~~
把and换成or
~~~
GET /_search
{
"query": {
"multi_match" : {
"query": "Will smith",
"type": "best_fields",
"fields": [ "first_name", "last_name" ],
"operator": "or"
}
}
}
~~~
转换成
~~~
(first_name:will or first_name:smith) # 大写都转小写了
| (last_name:will or last_name:smith) # 大写都转小写了
~~~
所有Word都必须存在于一个文档匹配的单个字段中。
> 4.2 most\_fields
> 当查询包含以不同方式分析的相同文本的多个字段时，most\_fields类型最为有用。 例如，主要领域可能包含同义词，词干和术语，而没有变音符号。 第二个字段可能包含原始术语，第三个字段可能包含带状键。 通过组合来自所有三个字段的分数，我们可以在主域中匹配尽可能多的文档，但是使用第二和第三个字段将最相似的结果推送到列表的顶部。
~~~
GET /_search
{
"query": {
"multi_match" : {
"query": "quick brown fox",
"type": "most_fields",
"fields": [ "title", "title.original", "title.shingles" ]
}
}
}
~~~
会被这样执行
~~~
GET /_search
{
"query": {
"bool": {
"should": [
{ "match": { "title": "quick brown fox" }},
{ "match": { "title.original": "quick brown fox" }},
{ "match": { "title.shingles": "quick brown fox" }}
]
}
}
}
~~~
来自每个match子句的得分加在一起，然后除以match子句的数量
> 4.3 cross\_fields
> cross\_fields类型对于多个字段应匹配的结构化文档特别有用。 例如，当查询“Will Smith”的first\_name和last\_name字段时，最佳匹配在一个字段中可能具有“Will”，而在另一个字段中可能具有“Smith”。
~~~
GET /_search
{
"query": {
"multi_match" : {
"query": "Will Smith",
"type": "cross_fields",
"fields": [ "first_name", "last_name" ],
"operator": "and"
}
}
}
~~~
转成，和best\_field不同的是，他会把 will Smith且分给两个域
~~~
+(first_name:will last_name:will)
+(first_name:smith last_name:smith)
~~~
### 1.5 bool
> bool 查询与bool过滤类似，不同的是， bool过滤可以直接给出是否匹配成功，而bool 查询要计算每一个查询子句的\_score（相关性分值）
> 以下查询将会找到 title 字段中包含"how to make millions"，并且"tag" 字段没有被标为 spam. 如果有标为"starred"或者发布日期为2014年之前，那么这些匹配的文档将比同类网站等级高：
~~~
GET _search
{
"bool": {
"must": {"match": {"title":"how to make millions"}},
"must_not": { "match": {"tag": "spam" }},
"should": [
{"match": {"tag": "starred"}},
{"range":{"date": {"gte":"2014-01-01"}}}
]
}
}
~~~
* 查询about字段中含有basketball和年龄在35-40之间的文档
~~~
GET /megacorp/_search
{
"query": {
"bool": {
"must": [
{"match": {"about": "basketball"}},
{"range": {"age": {"gte": 35, "lte": 40}}}
]
}
}
}
~~~
### 1.6 Common Terms 查询
> * 查询中的每个术语都性能消耗。 搜索“The brown fox”需要三个查询，每个查询“一个”，“brown”和“fox”，所有这些都针对索引中的所有文档执行。“The”会查询出很多文档，所以查询的效果不如前面的两个查询。
> * 以前的做法是把the去掉，这样有很大的问题，例如我们无法区分“happy”和“not happy”
> * common term 是把查询词分为两类，一类是重要词（查询与文档相关性较大的词）和非重要词（例如无用词）
>
> 1. common term会先查找重要词，这些词会出现在较少的文档中（效率），且有很好的相关性
> 2. 接着执行次要词查询，在计算相关性评分时，不会计算所有匹配的文档，而是计算第一步中的得到文档的评分，以这种方式，高频率可以改善相关性计算，而无需支付性能差的成本。
> 3. 如果查询仅由高频项组成，则单个查询将作为AND（连接）查询执行，换句话说，所有术语都是必需的。 即使每一个术语都符合许多文件，术语的组合将结果集缩小到最相关。 单个查询也可以作为具有特定minimum\_should\_match的OR执行，在这种情况下，应该使用足够高的值。
* 在这个例子中，文档频率大于0.1％的单词（例如“this”和“is”）将被视为通用术语。
~~~
GET /_search
{
"query": {
"common": {
"body": {
"query": "this is bonsai cool",
"cutoff_frequency": 0.001
}
}
}
}
~~~
可以使用minimum\_should\_match（high\_freq，low\_freq），low\_freq\_operator（默认“或”）和high\_freq\_operator（默认“或”）参数来控制应该匹配的术语数量。
对于低频条件，将low\_freq\_operator设置为“and”以使所有条件都需要：
~~~
GET /_search
{
"query": {
"common": {
"body": {
"query": "nelly the elephant as a cartoon",
"cutoff_frequency": 0.001,
"low_freq_operator": "and"
}
}
}
}
~~~
可以粗略的等于
~~~
GET /_search
{
"query": {
"bool": {
"must": [
{ "term": { "body": "nelly"}},
{ "term": { "body": "elephant"}},
{ "term": { "body": "cartoon"}}
],
"should": [
{ "term": { "body": "the"}},
{ "term": { "body": "as"}},
{ "term": { "body": "a"}}
]
}
}
}
~~~
### 1.7 Query String 查询
一个使用查询解析器解析其内容的查询。
~~~
GET /_search
{
"query": {
"query_string" : {
"default_field" : "content",
"query" : "this AND that OR thus"
}
}
}
~~~
### 1.8 批量查询
1、批量查询的好处
就是一条一条的查询，比如说要查询100条数据，那么就要发送100次网络请求，这个开销还是很大的
如果进行批量查询的话，查询100条数据，就只要发送1次网络请求，网络请求的性能开销缩减100倍
2、mget的语法
（1）一条一条的查询
~~~
GET /test_index/test_type/1
GET /test_index/test_type/2
~~~
~~~
（2）mget批量查询
GET /_mget
{
"docs" : [
{
"_index" : "test_index",
"_type" : "test_type",
"_id" : 1
},
{
"_index" : "test_index",
"_type" : "test_type",
"_id" : 2
}
]
}
{
"docs": [
{
"_index": "test_index",
"_type": "test_type",
"_id": "1",
"_version": 2,
"found": true,
"_source": {
"test_field1": "test field1",
"test_field2": "test field2"
}
},
{
"_index": "test_index",
"_type": "test_type",
"_id": "2",
"_version": 1,
"found": true,
"_source": {
"test_content": "my test"
}
}
]
}
~~~
（3）如果查询的document是一个index下的不同type种的话
~~~
GET /test_index/_mget
{
"docs" : [
{
"_type" : "test_type",
"_id" : 1
},
{
"_type" : "test_type",
"_id" : 2
}
]
}
~~~
（4）如果查询的数据都在同一个index下的同一个type下，最简单了
~~~
GET /test_index/test_type/_mget
{
"ids": [1, 2]
}
~~~
3、mget的重要性
可以说mget是很重要的，一般来说，在进行查询的时候，如果一次性要查询多条数据的话，那么一定要用batch批量操作的api
尽可能减少网络开销次数，可能可以将性能提升数倍，甚至数十倍，非常非常之重要
### 1.9 prefix query( 前缀查询)
* 查出title以C3开头的文档，prefix不计算分数，不建立倒排索引，性能较差
~~~
GET my_index/_search
{
"query": {
"prefix": {
"title": {
"value": "C3"
}
}
}
}
~~~
得到
~~~
"hits": {
"total": 2,
"max_score": 1,
"hits": [
{
"_index": "my_index",
"_type": "my_type",
"_id": "2",
"_score": 1,
"_source": {
"title": "C3-K5-DFG65"
}
},
{
"_index": "my_index",
"_type": "my_type",
"_id": "1",
"_score": 1,
"_source": {
"title": "C3-D0-KD345"
}
}
]
}
~~~
### 1.1.0 wildcard（模糊搜索）
* 查询title以C开头，5结尾的文档
~~~
GET my_index/_search
{
"query": {
"wildcard": {
"title": {
"value": "C*5"
}
}
}
}
~~~
得到
~~~
"hits": {
"total": 3,
"max_score": 1,
"hits": [
{
"_index": "my_index",
"_type": "my_type",
"_id": "2",
"_score": 1,
"_source": {
"title": "C3-K5-DFG65"
}
},
{
"_index": "my_index",
"_type": "my_type",
"_id": "1",
"_score": 1,
"_source": {
"title": "C3-D0-KD345"
}
},
{
"_index": "my_index",
"_type": "my_type",
"_id": "3",
"_score": 1,
"_source": {
"title": "C4-I8-UI365"
}
}
]
~~~
### 1.11 搜索推荐
1、ngram和index-time搜索推荐原理
什么是ngram
例如quick，5种长度下的ngram
~~~
ngram length=1，q u i c k
ngram length=2，qu ui ic ck
ngram length=3，qui uic ick
ngram length=4，quic uick
ngram length=5，quick
~~~
什么是edge ngram
quick，anchor首字母后进行ngram
~~~
q
qu
qui
quic
quick
~~~
使用edge ngram将每个单词都进行进一步的分词切分，用切分后的ngram来实现前缀搜索推荐功能
~~~
hello world
hello we
h
he
hel
hell
hello doc1,doc2
w doc1,doc2
wo
wor
worl
world
e doc2
helloworld
min ngram = 1
max ngram = 3
h
he
hel
hello w
hello --> hello，doc1
w --> w，doc1
~~~
> doc1，hello和w，而且position也匹配，所以，ok，doc1返回，hello world
> 搜索的时候，不用再根据一个前缀，然后扫描整个倒排索引了; 简单的拿前缀去倒排索引中匹配即可，如果匹配上了，那么就好了; match，全文检索
2、实验一下ngram
1. 自定义分词器
~~~
PUT /my_index
{
"settings": {
"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"
}
~~~
得到，quick brown被按照搜索推荐，分成 q，qu，qui，。。。
~~~
"tokens": [
{
"token": "q",
"start_offset": 0,
"end_offset": 5,
"type": "<ALPHANUM>",
"position": 0
},
{
"token": "qu",
"start_offset": 0,
"end_offset": 5,
"type": "<ALPHANUM>",
"position": 0
},
{
"token": "qui",
"start_offset": 0,
"end_offset": 5,
"type": "<ALPHANUM>",
"position": 0
},
{
"token": "quic",
"start_offset": 0,
"end_offset": 5,
"type": "<ALPHANUM>",
"position": 0
},
{
"token": "quick",
"start_offset": 0,
"end_offset": 5,
"type": "<ALPHANUM>",
"position": 0
},
{
"token": "b",
"start_offset": 6,
"end_offset": 11,
"type": "<ALPHANUM>",
"position": 1
},
{
"token": "br",
"start_offset": 6,
"end_offset": 11,
"type": "<ALPHANUM>",
"position": 1
},
{
"token": "bro",
"start_offset": 6,
"end_offset": 11,
"type": "<ALPHANUM>",
"position": 1
},
{
"token": "brow",
"start_offset": 6,
"end_offset": 11,
"type": "<ALPHANUM>",
"position": 1
},
{
"token": "brown",
"start_offset": 6,
"end_offset": 11,
"type": "<ALPHANUM>",
"position": 1
}
]
}
~~~
2. 设置映射属性
~~~
PUT /my_index/_mapping/my_type
{
"properties": {
"title": {
"type": "string",
"analyzer": "autocomplete", # 倒排索引，使用自定义分词器
"search_analyzer": "standard" # 搜索正常分词
}
}
}
~~~
3. 插入测试数据
~~~
PUT my_index/my_type/1
{
"title": "hello world"
}
PUT my_index/my_type/2
{
"title": "hello win"
}
PUT my_index/my_type/3
{
"title": "hello dog"
}
~~~
4. 测试
~~~
GET my_index/_search
{
"query": {
"match_phrase": {
"title": "hello w"
}
}
}
~~~
5. 得出所有可能以hello w 开头的文档，并求推荐给用户
"min\_gram": 1, # 切分单词最小长度
"max\_gram": 4 # 切分单词最大长度，hello被分成h，he，hel，hell。
~~~
hello world
h
he
hel
hell
hello
w
wo
wor
worl
world
hello w
h
he
hel
hell
hello
w
hello w --> hello --> w
GET /my_index/my_type/_search
{
"query": {
"match_phrase": {
"title": "hello w"
}
}
}
~~~
如果用match，只有hello的也会出来，全文检索，只是分数比较低
推荐使用match\_phrase，要求每个term都有，而且position刚好靠着1位，符合我们的期望的
### 1.12 纠错查询
数据
~~~
POST /my_index/my_type/_bulk
{ "index": { "_id": 1 }}
{ "text": "Surprise me!"}
{ "index": { "_id": 2 }}
{ "text": "That was surprising."}
{ "index": { "_id": 3 }}
{ "text": "I wasn't surprised."}
~~~
查询
~~~
GET /my_index/my_type/_search
{
"query": {
"fuzzy": {
"text": {
"value": "surprize",
"fuzziness": 2 # 最多纠正错误次数
}
}
}
}
~~~
得到
~~~
"hits": [
{
"_index": "my_index",
"_type": "my_type",
"_id": "1",
"_score": 0.22585157,
"_source": {
"text": "Surprise me!"
}
},
{
"_index": "my_index",
"_type": "my_type",
"_id": "3",
"_score": 0.1898702,
"_source": {
"text": "I wasn't surprised."
}
}
]
}
}
~~~
* 自动纠错
~~~
GET /my_index/my_type/_search
{
"query": {
"match": {
"text": { # field
"query": "SURPIZE ME",
"fuzziness": "AUTO",
"operator": "and"
}
}
}
}
~~~
得到
~~~
"hits": {
"total": 1,
"max_score": 0.44248468,
"hits": [
{
"_index": "my_index",
"_type": "my_type",
"_id": "1",
"_score": 0.44248468,
"_source": {
"text": "Surprise me!"
}
}
]
}
}
~~~
### 1.13 histogram数值区间分组
> histogram对于某个数值field，按照一定的区间间隔分组， "interval": 2000指的是按照步长为2000进行分组
1. 按照价格，每2000是一组
~~~
GET /tvs/_search
{
"size": 0,
"aggs": {
"group_by_price": {
"histogram": {
"field": "price",
"interval": 2000
}
}
}
}
~~~
得到
~~~
"buckets": [
{
"key": 0,
"doc_count": 3 # 0-2000有3个
},
{
"key": 2000,
"doc_count": 4 # 2000-4000有4个
},
{
"key": 4000,
"doc_count": 0
},
{
"key": 6000,
"doc_count": 0
},
{
"key": 8000,
"doc_count": 1
}
]
}
}
}
~~~
### 1.14 date\_histogram 时间区间聚合
1. 求每个月销售总量
> min\_doc\_count：0
> 即使某个日期interval，2017-01-01~2017-01-31中，一条数据都没有，那么这个区间也是要返回的，不然默认是会过滤掉这个区间的
> "interval": "month" ：以月为单位聚合
> "extended\_bounds":{ "min":"2016-01-01", "max":"2017-12-12" }：指定时间边界
~~~
GET tvs/_search
{
"size": 0,
"aggs": {
"sales": {
"date_histogram": {
"field": "sold_date",
"interval": "month",
"format": "yyyy-MM-dd",
"min_doc_count": 0,
"extended_bounds":{
"min":"2016-01-01",
"max":"2017-12-12"
}
},
"aggs": {
"sum_price_month": {
"sum": {
"field": "price"
}
}
}
}
}
}
~~~
### 1.15 单聚与整聚
1. 求出长虹电视销售平均价格和所有电视销售平均价的对比
~~~
GET tvs/_search
{
"size": 0,
"query": {
"term": {
"brand": {
"value": "长虹"
}
}
},
"aggs": { # 根据查询聚合
"single_avg_price": {
"avg": {
"field": "price"
}
},
"globle":{ # 名称
"global": {}, 构造一个整体桶
"aggs": {
"globle_avg_price": {
"avg": {
"field": "price"
}
}
}
}
}
}
~~~
得到
~~~
},
"aggregations": {
"globle": {
"doc_count": 8,
"globle_avg_price": {
"value": 2650
}
},
"single_avg_price": {
"value": 1666.6666666666667
}
}
}
~~~
### 1.15 聚合去重
1. 查看每个季度，都有哪些品牌销售
~~~
GET /tvs/_search
{
"size": 0,
"aggs": {
"groupby_mounth": {
"date_histogram": {
"field": "sold_date",
"format": "yyyy-MM-dd",
"interval": "quarter",
"extended_bounds":{
"min":"2016-01-01",
"max":"2017-08-08"
}
},
"aggs": {
"distinct_brand": {
"cardinality": {
"field": "brand" # 在桶内，对品牌去重
}
}
}
}
}
}
~~~
得到
~~~
"hits": []
},
"aggregations": {
"groupby_mounth": {
"buckets": [
{
"key_as_string": "2016-01-01",
"key": 1451606400000,
"doc_count": 0,
"distinct_brand": {
"value": 0
}
},
{
"key_as_string": "2016-04-01",
"key": 1459468800000,
"doc_count": 1,
"distinct_brand": {
"value": 1
}
},
{
"key_as_string": "2016-07-01",
"key": 1467331200000,
"doc_count": 2,
"distinct_brand": {
"value": 1
}
},
{
"key_as_string": "2016-10-01",
"key": 1475280000000,
"doc_count": 3,
"distinct_brand": {
"value": 1
}
},
{
"key_as_string": "2017-01-01",
"key": 1483228800000,
"doc_count": 2,
"distinct_brand": {
"value": 2
}
~~~
2. 控制去重精准度
> 1. cardinality，count(distinct)，5%的错误率，性能在100ms左右
> 2. "precision\_threshold": 100：表示brand去重，如果brand的unique value，在100个以内，小米，长虹，三星，TCL，HTL。。。，几乎保证去重100%准确
> 3. 为了保证去重的准确性，可以根据需要调大precision\_threshold的值
> 4. 小缺点：
> cardinality算法，会占用precision\_threshold \* 8 byte 内存消耗，100 \* 8 = 800个字节占用内存很小。。。而且unique value如果的确在值以内，那么可以确保100%准确100，数百万的unique value，错误率在5%以内
~~~
GET /tvs/_search
{
"size": 0,
"aggs": {
"groupby_mounth": {
"date_histogram": {
"field": "sold_date",
"format": "yyyy-MM-dd",
"interval": "quarter",
"extended_bounds":{
"min":"2016-01-01",
"max":"2017-08-08"
}
},
"aggs": {
"distinct_brand": {
"cardinality": {
"field": "brand",
"precision_threshold": 100 # 保证不同的值在100以内的话，去重精准性
}
}
}
}
}
}
~~~
## 2\. 过滤
### 2.1 bool过滤
> * 对于精准值，使用过滤。合并多个过滤条件查询结果的布尔逻辑，包含以下操作符：
>
> 1. must：多个查询条件必须满足，相当于and
> 2. must\_not : 多个查询条件的相反匹配，相当于not
> 3. should ： 至少有一个查询条件匹配，相当于or
{
"bool": {
"must": { "term": { "folder":"inbox"}},
"must\_not": { "term": { "tag": "spam" }},
"should": \[
{ "term": { "starred": true }},
{ "term": { "unread": true }}
\]
}
}
~~~
匹配数量
~~~
GET /\_search
{
"query": {
"common": {
"body": {
"query": "nelly the elephant not as a cartoon",
"cutoff\_frequency": 0.001,
"minimum\_should\_match": {
"low\_freq" : 2,
"high\_freq" : 3
}
}
}
}
}
~~~
### 2.2 term:过滤
主要用于精确匹配哪些值，比如数字、日期布尔值或not_analyzed的字符串(未经分析的文本数据类型)：
### 2.3 terms：过滤
> * 与term相似，但是可以指定多个匹配条件，如果某一字段有多个值，那么文档需要一起做匹配
例如，想要查找价格是20或者30的商品
~~~
GET /my\_store/products/\_search
{
"query": {
"bool": {
"filter": {
"terms": {
"price":\[20,30\]
}
}
}
}
}
~~~
### 2.4 range ：过滤
> 过滤某一区间的数据
> 1. gt 大于
> 2. gte 大于等于
> 3. lt 小于
> 4. lte 小于等于
> * 查找价格大于等于10小于等于20的商品
~~~
GET /my\_store/\_search
{
"query": {
"bool": {
"filter": {
"range": {
"price": {
"gte": 10,
"lte": 20
}
}
}
}
}
}
~~~
> 查找最近一小时的文档
~~~
"range" : {
"timestamp" : {
"gt" : "now-1h"
}
}
~~~
### 2.5 exists过滤器
返回包含某一字段的文档
> * 查找tags字段有值的文档
~~~
GET /my\_index/\_search
{
"query": {
"bool": {
"filter": {
"exists": {
"field": "tags"
}
}
}
}
}
~~~
### 2.6 missing过滤器
与exists过滤相反，返回没有指定字段值的文档
~~~
GET /my\_index/\_search
{
"query": {
"bool": {
"filter": {
"missing": {
"field": "tags"
}
}
}
}
}
~~~
## 3. 复合查询
> 通常情况下，一条过滤语句需要过滤子句的辅助，全文搜索除外。一条查询语句可以包含过滤子句，反之亦然。search API中只能包含 query 语句，所以我们需要用 bool 来同时包含"query"和"filter"子句：
查询姓Smith的人，要求年龄是25
~~~
GET /\_search
{
"query": {
"bool": {
"must": \[
{ "match": { "last\_name":"Smith"}}
\],
"filter": \[
{ "range": { "age": { "lte" :25}}}
\]
}
}
}
# 使用term
GET /\_search
{
"query": {
"bool": {
"must": \[
{"match": {
"last\_name": "Smith"
}}
\],
"filter": \[
{"term":{"age":25}}
\]
}
}
}
~~~
## 4. 索引管理
#### 4.1 创建自定义索引
~~~
PUT /my\_index
{
"settings": { ... any settings ... },
"mappings": {
"type\_one": { ... any mappings ... },
"type\_two": { ... any mappings ... },
...
}
~~~
#### 4.2 删除索引
~~~
DELETE /index\_one,index\_two
DELETE /index\_\*
~~~
创建只有一个分片，没有副本的索引
~~~
PUT /my\_temp\_index
{
"settings": {
"number\_of\_shards" : 1,
"number\_of\_replicas" : 0
}
}
~~~
动态修改副本个数
~~~
PUT /my\_temp\_index/\_settings
{
"number\_of\_replicas": 1
}
~~~
#### 4.3 更新
> * 如果field存在就更新，不存在就创建
~~~
POST my\_store/products/1/\_update
{
"doc": {
"bookname" : "elasticsearch"
}
}
~~~
## 5. 插入文档
### 5.1 _bulk
~~~
每个操作需要两个json字符串，语法如下
{“action”：{“metadata”}}
{“data”}
~~~
> 有哪些类型的操作可以执行呢？
> （1）delete：删除一个文档，只要1个json串就可以了
> （2）create：PUT /index/type/id/_create，强制创建
> （3）index：普通的put操作，可以是创建文档，也可以是全量替换文档
> （4）update：执行的partial update操作
插入数据
~~~
POST /my\_store/products/\_bulk
{ "index": { "\_id": 1 }}
{ "price" : 10, "productID" : "XHDK-A-1293-#fJ3" }
{ "index": { "\_id": 2 }}
{ "price" : 20, "productID" : "KDKE-B-9947-#kL5" }
{ "index": { "\_id": 3 }}
{ "price" : 30, "productID" : "JODL-X-1937-#pV7" }
{ "index": { "\_id": 4 }}
{ "price" : 30, "productID" : "QQPX-R-3956-#aD8" }
~~~
查询数据
~~~
GET /my\_store/products/\_search
{
"query": {
"bool": {
"filter": {"term": {
"price": "20"
}}
}
}
}
~~~
### 5.2 批量数据导入elasticsearch
* 数据文件格式如5.1中
导入命令： 在数据文件目录下执行
~~~
curl -H 'Content-Type: application/x-ndjson' -XPUT '[http://192.168.2.88:9200/bank/account/\_bulk?pretty](http://192.168.2.88:9200/bank/account/_bulk?pretty)' --data-binary @accounts.json
~~~
## 6. mapping
> * 可以理解为为文档创建模型（scheme），规定每个字段的信息
> * 可以为字段添加index参数，指定字符串以何种方式索引
> * index
index：和_index区别开来，_index是文档的索引，而index是字段的描述，表示字段以何种方式被索引
index参数有以下值;
1. analyzed : 以全文方式索引这个字段，先分析、分词、倒排索引（全文索引）
2. not_analyzed:索引这个字段，使之可以被搜索，但是索引内容和指定值一样。不分析此字段(精准值匹配)
3. no ：不索引这个字段，这个字段不会被检索到
## 7. 聚合
### 查询聚合（多次分组）
1. 按照country分组
2. 在country组内按照join_date分组
3. 接着按照最小组内求平均年龄
country（join_date（avg））
* 元数据信息
~~~
PUT /company
{
"mappings": {
"employee": {
"properties": {
"age": {
"type": "long"
},
"country": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword",
"ignore\_above": 256
}
},
"fielddata": true # 指定country为正排索引，因为要分组，所以不能被分词,其实field不指定也行
},
"join\_date": {
"type": "date" # date类型本身就不会被分词，不用指定
},
"name": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword", # "type": "keyword",代表不分词
"ignore\_above": 256
}
}
},
"position": {
"type": "text",
"fields": {
"keyword": {
"type": "keyword",
"ignore\_above": 256
}
}
},
"salary": {
"type": "long"
}
}
}
}
}
~~~
* 查询
~~~
GET company/\_search
{"size": 0,
"aggs": {
"group\_by\_country": { # 1. 按照country第一次分组
"terms": {
"field": "country"
},
"aggs": {
"group\_by\_date": { # 2. 按照join\_date第二次分组
"terms": {
"field": "join\_date"
},
"aggs": {
"avg\_age": {
"avg": {
"field": "age"
}
}
}
}
}
}
}
}
~~~
* 结果
~~~
"group\_by\_country": {
"doc\_count\_error\_upper\_bound": 0,
"sum\_other\_doc\_count": 0,
"buckets": \[ # country组
{
"key": "china",
"doc\_count": 3,
"group\_by\_date": { # group\_by\_date"组，有两个2016-01-01和2017-01-01
"doc\_count\_error\_upper\_bound": 0,
"sum\_other\_doc\_count": 0,
"buckets": \[
{
"key": 1483228800000,
"key\_as\_string": "2017-01-01T00:00:00.000Z",
"doc\_count": 2,
"avg\_age": {
"value": 31
}
},
{
"key": 1451606400000,
"key\_as\_string": "2016-01-01T00:00:00.000Z",
"doc\_count": 1,
"avg\_age": {
"value": 32
}
}
\]
~~~
> 用state字段分组，并且计算出每组的个数，类似于mysql的分组，term用于按照指定的field分组，并给组内成员个数
`SELECT state, COUNT(*) FROM bank GROUP BY state ORDER BY COUNT(*) DESC`
~~~
GET /bank/\_search
{
"size": 0,
"aggs": {
"group\_by\_state": {
"terms": {
"field": "state.keyword"
}
}
}
}
~~~
> "size": 0 ：不显示查询的hits部分，只查看聚合的结果，terms是聚合的意思
* 在以上分完组的前提下，对每组的余额求平均数
~~~
GET /bank/\_search
{
"size": 0,
"aggs": {
"group\_by\_state": {
"terms": {
"field": "state.keyword"
},
"aggs": {
"average\_balance": {
"avg": {
"field": "balance"
}
}
}
}
}
}
~~~
返回 桶中桶（组中平均）
~~~
"aggregations": {
"group\_by\_state": { # 第一层聚合的名字
"doc\_count\_error\_upper\_bound": 20,
"sum\_other\_doc\_count": 770,
"buckets": \[
{
"key": "ID",
"doc\_count": 27,
"average\_balance": {
"value": 24368.777777777777
}
},
{
"key": "TX",
"doc\_count": 27,
"average\_balance": { # 平均值
"value": 27462.925925925927
}
},
{
~~~
* 聚合排序,aggs{group,avg}
* 按照average_balance求出的平均值排序
~~~
GET /bank/\_search
{
"size": 0,
"aggs": {
"group\_by\_state": {
"terms": {
"field": "state.keyword",
"order": {
"average\_balance": "desc"
}
},
"aggs": {
"average\_balance": {
"avg": {
"field": "balance"
}
}
}
}
}
}
~~~
* 按照价格区间分组
~~~
GET /ecommerce/product/\_search
{
"size": 0,
"aggs": {
"group\_by\_price": {
"range": {
"field": "price",
"ranges": \[
{
"from": 0,
"to": 20
},
{
"from": 20,
"to": 40
},
{
"from": 40,
"to": 50
}
\]
},
"aggs": {
"group\_by\_tags": {
"terms": {
"field": "tags"
},
"aggs": {
"average\_price": {
"avg": {
"field": "price"
}
}
}
}
}
}
}
}
~~~
## 8. geo query 地理位置查询
> 有以下几种物理位置查询方式
> 1. geo_shape查询
> 查找具有与指定的地理形状相交或与之相交的地理形状的文档。
> 2. geo_bounding_box查询
> 查找具有落入指定矩形中的地理位置的文档。
> 3. geo_distance查询
> 在中心点的指定距离内查找具有地理点的文档。
> 4. geo_distance_range查询
> 像geo_distance查询一样，但距离中心点指定的距离开始。
> 5. geo_polygon查询
> 查找指定多边形内具有地理位置的文档。
### 8.1 地理坐标点
地理坐标点 是指地球表面可以用经纬度描述的一个点。 地理坐标点可以用来计算两个坐标间的距离，还可以判断一个坐标是否在一个区域中，或在聚合中。
地理坐标点不能被动态映射 （dynamic mapping）自动检测，而是需要显式声明对应字段类型为 geo-point ：
~~~
PUT /attractions
{
"mappings": { # 映射
"restaurant": { # 类型
"properties": {
"name": { # field
"type": "string"
},
"location": {
"type": "geo\_point"
}
}
}
}
~~~
## 9. _termvectors
统计词条信息
可以对词语进行过滤，常用的过滤器参数如：
max_num_terms 最大的词条数目
min_term_freq 最小的词频，比如忽略那些在字段中出现次数小于一定值的词条。
max_term_freq 最大的词频
min_doc_freq 最小的文档频率，比如忽略那些在文档中出现次数小于一定的值的词条
max_doc_freq 最大的文档频率
min_word_length 词的最小长度
max_word_length 词的最大长度
1. 对content字段进行词频统计
~~~
GET news/new/1/\_termvectors
{
"fields": \["content"\]
}
~~~
得到
~~~
~~~
"terms": {
"30": {
"term_freq": 1,
"tokens": [
~~~
。。。。。
"与": {
"term\_freq": 1, # 词出现的次数
"tokens": \[
{
"position": 1,
"start\_offset": 2,
"end\_offset": 3
}
\]
。。。。。。
~~~
2. 对词进行过滤
~~~
GET /news/new/9/\_termvectors
{
"fields": \["content"\],
"filter": {
"min\_word\_length": 2, 词的长度大于1,这样不会出现单词字了
"min\_term\_freq": 2 # 词出现的次数最少有两次
}
}
~~~
3. java api
~~~
public List> termVectos(String index, String type, String id,String field) throws IOException {
TermVectorsRequest.FilterSettings filterSettings = new TermVectorsRequest.FilterSettings();
filterSettings.minWordLength = 2;
filterSettings.maxNumTerms = 10000; //返回最大结果数
TermVectorsResponse resp = client.prepareTermVectors(index, type, id)
.setFilterSettings(filterSettings)
.setSelectedFields(field)
.execute().actionGet();
//获取字段
Fields fields = resp.getFields();
Iteratoriterator = fields.iterator();
~~~
List<Map<String,Object>> result = new ArrayList<Map<String, Object>>();
Map<String,Object> temp = null;
while (iterator.hasNext()){
String dfield = iterator.next();
Terms terms = fields.terms(dfield); //获取字段对应的terms
TermsEnum termsEnum = terms.iterator(); //termsEnum包含词语统计信息
while (termsEnum.next() != null){
String word = termsEnum.term().utf8ToString();
int freq = termsEnum.postings(null,120).freq();
temp = new HashMap<String, Object>();
temp.put("word",word);
temp.put("freq",freq);
result.add(temp);
}
}
return result;
}
~~~
~~~
## 10.高亮
~~~
GET /ecommerce/product/\_search
{
"query" : {
"match" : {
"producer" : "producer"
}
},
"highlight": {
"fields" : {
"producer" : {}
}
}
}
~~~
得到
~~~
~~~
"_index": "ecommerce",
"_type": "product",
"_id": "1",
"_score": 0.25811607,
"_source": {
"name": "gaolujie yagao",
"desc": "gaoxiao meibai",
"price": 30,
"producer": "gaolujie producer",
"tags": [
"meibai",
"fangzhu"
]
},
"highlight": {
"producer": [
"gaolujie <em>producer</em>" # 高亮标记
]
}
},
~~~
~~~
## 11. 插入数据
### 11.1 手动指定document id
（1）根据应用情况来说，是否满足手动指定document id的前提：
> 一般来说，是从某些其他的系统中，导入一些数据到es时，会采取这种方式，就是使用系统中已有数据的唯一标识，作为es中document的id。举个例子，比如说，我们现在在开发一个电商网站，做搜索功能，或者是OA系统，做员工检索功能。这个时候，数据首先会在网站系统或者IT系统内部的数据库中，会先有一份，此时就肯定会有一个数据库的primary key（自增长，UUID，或者是业务编号）。如果将数据导入到es中，此时就比较适合采用数据在数据库中已有的primary key。
> 如果说，我们是在做一个系统，这个系统主要的数据存储就是es一种，也就是说，数据产生出来以后，可能就没有id，直接就放es一个存储，那么这个时候，可能就不太适合说手动指定document id的形式了，因为你也不知道id应该是什么，此时可以采取下面要讲解的让es自动生成id的方式。
（2）put /index/type/id put指定ID
~~~
PUT /test\_index/test\_type/2
{
"test\_content": "my test"
}
~~~
### 11.2 自动生成document id
（1）post /index/type
~~~
POST /test\_index/test\_type
{
"test\_content": "my test"
}
{
"\_index": "test\_index",
"\_type": "test\_type",
"\_id": "AVp4RN0bhjxldOOnBxaE",
"\_version": 1,
"result": "created",
"\_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"created": true
}
~~~
（2）自动生成的id，长度为20个字符，URL安全，base64编码，GUID，分布式系统并行生成时不可能会发生冲突
## 12. document修改
### 12.1 全量替换（put）
> 1. 全量替换
> 如果document不存在，则创建document，version为1，如果存在，则用新put的数据替换原来的document，version加1，旧的文档不会被马上删除，但是也不会被访问了。不会立即物理删除，只会将其标记为deleted，当数据越来越多的时候，es在后台自动删除
> 2. document的强制创建
> 创建文档与全量替换的语法是一样的，有时我们只是想新建文档，不想替换文档，如果强制进行创建呢？
> PUT /index/type/id?op_type=create，PUT /index/type/id/_create
## 13. partial update
1、什么是partial update？
> PUT /index/type/id，创建文档&替换文档，就是一样的语法
> 一般对应到应用程序中，每次的执行流程基本是这样的：
> （1）应用程序先发起一个get请求，获取到document，展示到前台界面，供用户查看和修改
> （2）用户在前台界面修改数据，发送到后台
> （3）后台代码，会将用户修改的数据在内存中进行执行，然后封装好修改后的全量数据
> （4）然后发送PUT请求，到es中，进行全量替换
> （5）es将老的document标记为deleted，然后重新创建一个新的document
partial update
~~~
post /index/type/id/\_update
{
"doc": {
"要修改的少数几个field即可，不需要全量的数据"
}
}
~~~
看起来，好像就比较方便了，每次就传递少数几个发生修改的field即可，不需要将全量的document数据发送过去
partial update，看起来很方便的操作，实际内部的原理是什么样子的，然后它的优点是什么
3、上机动手实战演练partial update
~~~
PUT /test\_index/test\_type/10
{
"test\_field1": "test1",
"test\_field2": "test2"
}
POST /test\_index/test\_type/10/\_update
{
"doc": {
"test\_field2": "updated test2"
}
}
~~~
## 14. 控制查询精度
> 全文搜索：
> 1. 全文搜索有两种办法，match query和should
> 2. 控制搜索精度and operator（和），minimum_should_match（最少匹配数量）
准备数据
~~~
POST /forum/article/\_bulk
{ "update": { "\_id": "1"} }
{ "doc" : {"title" : "this is java and elasticsearch blog"} }
{ "update": { "\_id": "2"} }
{ "doc" : {"title" : "this is java blog"} }
{ "update": { "\_id": "3"} }
{ "doc" : {"title" : "this is elasticsearch blog"} }
{ "update": { "\_id": "4"} }
{ "doc" : {"title" : "this is java, elasticsearch, hadoop blog"} }
{ "update": { "\_id": "5"} }
{ "doc" : {"title" : "this is spark blog"} }
~~~
### 1. match query
1. 查询包含 Java 或者elasticsearch，得到四个文档
~~~
"title": "this is java, elasticsearch, hadoop blog" # elasticsearch java
"title": "this is java and elasticsearch blog" # elasticsearch java
"title": "this is elasticsearch blog" # elasticsearch
"title": "this is java blog" # java
~~~
2. 更精准一些，and 关键字
还有or关键字，不过没啥意义了，match本身就有or的作用,和1.是一样的作用，为什么要多写
查询包含Java和elasticsearch的文档
~~~
GET /forum/\_search
{
"query": {
"match": {
"title": {
"query": "java elasticsearch",
"operator": "and"
}
}
}
}
~~~
得到两条，将上一次的结果过滤掉了两条
~~~
"title": "this is java, elasticsearch, hadoop blog"
"title": "this is java and elasticsearch blog"
~~~
3. 最小匹配"minimum_should_match": "75%"
java elasticsearch spark hadoop 中至少有3个（75%）关键字出现
~~~
GET forum/\_search
{
"query": {
"match": {
"title": {
"query": "java elasticsearch spark hadoop",
"minimum\_should\_match": "75%" # 上边的查询条件至少满足75%
}
}
}
}
~~~
得到
~~~
"title": "this is java, elasticsearch, hadoop blog"
~~~
* java elasticsearch spark hadoop 中至少有三个关键字2个（50%）
~~~
GET forum/\_search
{
"query": {
"match": {
"title": {
"query": "java elasticsearch spark hadoop",
"minimum\_should\_match": "50%"
}
}
}
}
~~~
搜索条件放宽了，多搜索出一条数据
~~~
"title": "this is java, elasticsearch, hadoop blog"
"title": "this is java and elasticsearch blog"
~~~
### 2. should
~~~
GET /forum/\_search
{
"query": {
"bool": {
"should": \[
{"match": {"title": "java"}},
{"match": {"title": "elasticsearch"}},
{"match": {"title": "spark"}},
{"match": {"title": "hadoop"}}
\],
"minimum\_should\_match": 3
}
}
}
~~~
和3.作用相同
> 默认情况下，should是可以不匹配任何一个的，比如上面的搜索中，this is java blog，就不匹配任何一个should条件
> 但是有个例外的情况，如果没有must的话，那么should中必须至少匹配一个才可以
> 比如下面的搜索，should中有4个条件，默认情况下，只要满足其中一个条件，就可以匹配作为结果返回
~~~
- springcloud
- springcloud的作用
- springboot服务提供者和消费者
- Eureka
- ribbon
- Feign
- feign在微服务中的使用
- feign充当http请求工具
- Hystrix 熔断器
- Zuul 路由网关
- Spring Cloud Config 分布式配置中心
- config介绍与配置
- Spring Cloud Config 配置实战
- Spring Cloud Bus
- gateway
- 概念讲解
- 实例
- GateWay
- 统一日志追踪
- 分布式锁
- 1.redis
- springcloud Alibaba
- 1. Nacos
- 1.1 安装
- 1.2 特性
- 1.3 实例
- 1. 整合nacos服务发现
- 2. 整合nacos配置功能
- 1.4 生产部署方案
- 环境隔离
- 原理讲解
- 1. 服务发现
- 2. sentinel
- 3. Seata事务
- CAP理论
- 3.1 安装
- 分布式协议
- 4.熔断和降级
- springcloud与alibba
- oauth
- 1. abstract
- 2. oauth2 in micro-service
- 微服务框架付费
- SkyWalking
- 介绍与相关资料
- APM系统简单对比(zipkin,pinpoint和skywalking)
- server安装部署
- agent安装
- 日志清理
- 统一日志中心
- docker安装部署
- 安装部署
- elasticsearch 7.x
- logstash 7.x
- kibana 7.x
- ES索引管理
- 定时清理数据
- index Lifecycle Management
- 没数据排查思路
- ELK自身组件监控
- 多租户方案
- 慢查询sql
- 日志审计
- 开发
- 登录认证
- 链路追踪
- elk
- Filebeat
- Filebeat基础
- Filebeat安装部署
- 多行消息Multiline
- how Filebeat works
- Logstash
- 安装
- rpm安装
- docker安装Logstash
- grok调试
- Grok语法调试
- Grok常用表达式
- 配置中常见判断
- filter提取器
- elasticsearch
- 安装
- rpm安装
- docker安装es
- 使用
- 概念
- 基础
- 中文分词
- 统计
- 排序
- 倒排与正排索引
- 自定义dynamic
- 练习
- nested object
- 父子关系模型
- 高亮
- 搜索提示
- kibana
- 安装
- docker安装
- rpm安装
- 整合
- 收集日志
- 慢sql
- 日志审计s
- 云
- 分布式架构
- 分布式锁
- Redis实现
- redisson
- 熔断和降级