空查詢將返回所有索引庫(indices)中的所有文件:
get /_search
{}
只用乙個查詢字串,你就可以在乙個、多個或者 _all 索引庫(indices)和乙個、多個或者所有types中查詢:
get /index_2014*/type1,type2/_search
{}
同時你可以使用 from 和 size 引數來分頁:
get /_search
要使用這種查詢表示式,只需將查詢語句傳遞給 query 引數:
get /_search
空查詢(empty search) —{}— 在功能上等價於使用 match_all 查詢, 正如其名字一樣,匹配所有文件:
get /_search
}}
乙個查詢語句 的典型結構:
}
如果是針對某個字段,那麼它的結構如下:
}}
舉個例子,你可以使用 match 查詢語句 來查詢 tweet 欄位中包含 elasticsearch 的 tweet:
}
完整的查詢請求如下:
get /_search
}}
}}
}}#內部它需要執行兩個term查詢,然後將它們的結果合併來得到整體的結果,它會將兩個term查詢通過乙個bool查詢組織在一起
}}
}
在all和any中選擇有種非黑即白的感覺。如果使用者指定了5個查詢詞條,而乙份文件只包含了其中的4個呢?將"operator"設定成"and"會將它排除在外。
}}}
通過must,must_not以及should引數來接受多個查詢
title欄位中含有詞條quick,且不含有詞條lazy的任何文件都會被作為結果返回。目前為止,它的工作方式和bool過濾器十分相似。
差別來自於兩個should語句,它表達了這種意思:乙份文件不被要求需要含有詞條brown或者dog,但是如果它含有了,那麼它的相關度應該更高。
},
"must_not": },
"should": [},}
]}
}}
所有的must語句都需要匹配,而所有的must_not語句都不能匹配,但是should語句需要匹配多少個呢?預設情況下,should語句乙個都不要求匹配,只有乙個特例:如果查詢中沒有must語句,那麼至少要匹配乙個should語句。
},},}
],"minimum_should_match": 2
}}}
minimum_should_match引數來控制should語句需要匹配的數量,該引數可以是乙個絕對數值或者乙個百分比
}},}]
}}
}}},}]
}}
}}},},}
],"minimum_should_match": 2
}}
}},
"should": [ },}
]}
}}
指定乙個boost值來控制每個查詢子句的相對權重
}},
"should": [
}},}}]}
}}
},}]
}}}
}, },},}
]}}]}
}}
bool查詢中包含的譯者查詢子句只佔了總分值的三分之一,如果我們將譯者查詢子句放到和標題及作者相同的層次上,就會減少標題和作者子句的權重,讓它們各自只佔四分之一。
}},
}},},}]
}}]
}}}
boost值的範圍推薦在1和10之間
bool should查詢是如何計算得到其分值的
},}]
}}
}執行should子句中的兩個查詢
相加查詢返回的分值
將相加得到的分值乘以匹配的查詢子句的數量
除以總的查詢子句的數量
dis_max查詢
返回匹配了任何查詢的文件,並且分值是產生了最佳匹配的查詢所對應的分值
},}]
}}
}
tie_breaker},}],
"tie_breaker": 0.3}}
}tie_breaker引數會讓dis_max查詢的行為更像是dis_max和bool的一種折中。
dis_max最佳字段(best fields)、bool多數字段(most fields)的折中
它會通過下面的方式改變分值計算過程:
取得最佳匹配查詢子句的_score。
將其它每個匹配的子句的分值乘以tie_breaker。
將以上得到的分值進行累加並規範化。
通過tie_breaker引數,所有匹配的子句都會起作用,只不過最佳匹配子句的作用更大。
multi_match、match、dis_max、bool 的轉換
multi_match查詢 下兩個查詢等價
}},
}},
],"tie_breaker": 0.3
}}
}
注意到以上的type屬性為best_fields。
minimum_should_match和operator引數會被傳入到生成的match查詢中
在欄位名中使用萬用字元
}
提公升個別字段
}
就像一提到全文搜尋會首先想到match查詢一樣,當你需要尋找鄰近的幾個單詞時,你會使用match_phrase查詢:
get /my_index/my_type/_search
}}
位置資訊可以被儲存在倒排索引(inverted index)中,像match_phrase這樣位置感知(position-aware)的查詢能夠使用位置資訊來匹配那些含有正確單詞出現順序的文件,在這些單詞間沒有插入別的單詞。
短語是什麼
對於匹配了短語"quick brown fox"的文件,下面的條件必須為true:
如果以上的任何條件沒有被滿足,那麼文件就不能被匹配。
精確短語(exact-phrase)匹配也許太過於嚴格了。也許我們希望含有"quick brown fox"的文件也能夠匹配"quick fox"查詢,即使位置並不是完全相等的。
我們可以在短語匹配使用slop引數來引入一些靈活性:
get /my_index/my_type/_search}}
}
slop引數告訴match_phrase查詢詞條能夠相隔多遠時仍然將文件視為匹配。相隔多遠的意思是,你需要移動乙個詞條多少次來讓查詢和文件匹配?
get /my_index/address/_search
}}
wildcard查詢和prefix查詢類似,也是乙個基於詞條的低級別查詢。但是它能夠讓你指定乙個模式(pattern),而不是乙個字首(prefix)。它使用標準的shell萬用字元:?用來匹配任意字元,*用來匹配零個或者多個字元。
以下查詢能夠匹配包含w1f 7hw和w2f 8hw的文件:
get /my_index/address/_search
}}
get /my_index/address/_search
}}
這個正規表示式的規定了詞條需要以w開頭,緊跟著乙個0到9的數字,然後是乙個或者多個其它字元。
注意
prefix,wildcard以及regexp查詢基於詞條進行操作。如果你在乙個analyzed欄位上使用了它們,它們會檢查欄位中的每個詞條,而不是整個字段。參考:
ElasticSearch 翻頁查詢
相對於ealsticsearch的search api,翻頁查詢可以將查詢結果集分頁返回,而不是將所有的結果放在乙個page返回。如果查詢的結果集包含大量的資料,就可以用到翻頁查詢 scroll api,比如有200k條資料,可以將它們分成20次請求,每次只返回10k條查詢結果.有點類似於資料庫裡面...
ElasticSearch 查詢語法
author title publish date form指定從 返回 size指定返回數量 from 1 size 1 sort group by publish date 特定字段查詢所指特定值 query context 會根據匹配程度生成不同的匹配分數 全文本查詢針對文字型別 字段級別查詢...
elasticsearch高亮查詢
pageinfo elasticsearchtemplate.queryforpage query,article.class 帶條件的分頁查詢 test public void testselectpagebyid 建立querybuilder查詢條件 querybuilder querybuil...