?引言
本文參考黑馬 分布式Elastic search
Elasticsearch是一款非常強大的開源搜索引擎，具備非常多強大功能，可以幫助我們從海量數(shù)據(jù)中快速找到需要的內(nèi)容
一、DSL查詢文檔
ElasticSearch的查詢依然是基于JSON風格的DSL來實現(xiàn)的。
?DSL 查詢分類
Elasticsearch提供了基于JSON的DSL（Domain Specific Language）來定義查詢。常見的查詢類型包括：
-
查詢所有：查詢出所有數(shù)據(jù)，一般測試用。例如：match_all
-
全文檢索（full text）查詢：利用分詞器對用戶輸入內(nèi)容分詞，然后去倒排索引庫中匹配。例如：
- match_query
- multi_match_query
-
精確查詢：根據(jù)精確詞條值查找數(shù)據(jù)，一般是查找keyword、數(shù)值、日期、boolean等類型字段。例如：
- ids
- range
- term
-
地理（geo）查詢：根據(jù)經(jīng)緯度查詢。例如：
- geo_distance
- geo_bounding_box
-
復合（compound）查詢：復合查詢可以將上述各種查詢條件組合起來，合并查詢條件。例如：
- bool
- function_score
查詢的語法基本一致：
GET /indexName/_search
{
"query": {
"查詢類型": {
"查詢條件": "條件值"
}
}
}
我們以查詢所有為例，其中：
- 查詢類型為match_all
- 沒有查詢條件
// 查詢所有
GET /indexName/_search
{
"query": {
"match_all": {
}
}
}
其它查詢無非就是查詢類型、查詢條件的變化。
二、DSL查詢實例
?全文檢索查詢
全文檢索查詢的基本流程如下：
- 對用戶搜索的內(nèi)容做分詞，得到詞條
- 根據(jù)詞條去倒排索引庫中匹配，得到文檔id
- 根據(jù)文檔id找到文檔，返回給用戶
比較常用的場景包括：
- 商城的輸入框搜索
- 百度輸入框搜索
例如京東
因為是拿著詞條去匹配，因此參與搜索的字段也必須是可分詞的text類型的字段。
基本語法
常見的全文檢索查詢包括：
- match查詢：單字段查詢
- multi_match查詢：多字段查詢，任意一個字段符合條件就算符合查詢條件
match查詢語法如下：
GET /indexName/_search
{
"query": {
"match": {
"FIELD": "TEXT"
}
}
}
mulit_match語法如下：
GET /indexName/_search
{
"query": {
"multi_match": {
"query": "TEXT",
"fields": ["FIELD1", " FIELD12"]
}
}
}
match查詢實例
mulit_match查詢實例
可以看到，兩種查詢結(jié)果是一樣的，為什么？
因為我們將brand、name、business值都利用copy_to復制到了all字段中。因此你根據(jù)三個字段搜索，和根據(jù)all字段搜索效果當然一樣了。
但是，搜索字段越多，對查詢性能影響越大，因此建議采用copy_to，然后單字段查詢的方式。
match和multi_match的區(qū)別
- match：根據(jù)一個字段查詢
- multi_match：根據(jù)多個字段查詢，參與查詢字段越多，查詢性能越差
?精確查詢
精確查詢一般是查找keyword、數(shù)值、日期、boolean等類型字段。所以不會對搜索條件分詞。常見的有：
- term：根據(jù)詞條精確值查詢
- range：根據(jù)值的范圍查詢
term查詢語法
// term查詢
GET /indexName/_search
{
"query": {
"term": {
"FIELD": {
"value": "VALUE"
}
}
}
}
term查詢實例
當我搜索的是精確詞條時，能正確查詢出結(jié)果：
但是，當我搜索的內(nèi)容不是詞條，而是多個詞語形成的短語時，反而搜索不到：
range查詢 語法
// range查詢
GET /indexName/_search
{
"query": {
"range": {
"FIELD": {
"gte": 10, // 這里的gte代表大于等于，gt則代表大于
"lte": 20 // lte代表小于等于，lt則代表小于
}
}
}
}
range實例
精確查詢常見的有哪些呢？
- term查詢：根據(jù)詞條精確匹配，一般搜索keyword類型、數(shù)值類型、布爾類型、日期類型字段
- range查詢：根據(jù)數(shù)值范圍查詢，可以是數(shù)值、日期的范圍
?地理坐標查詢
所謂的地理坐標查詢，其實就是根據(jù)經(jīng)緯度查詢，官方文檔：https://www.elastic.co/guide/en/elasticsearch/reference/current/geo-queries.html
常見的使用場景包括：
- 攜程：搜索我附近的酒店
- 滴滴：搜索我附近的出租車
- 微信：搜索我附近的人
附近的酒店：
附近的車：
矩形范圍查詢
矩形范圍查詢，也就是geo_bounding_box查詢，查詢坐標落在某個矩形范圍的所有文檔：
查詢時，需要指定矩形的左上、右下兩個點的坐標，然后畫出一個矩形，落在該矩形內(nèi)的都是符合條件的點。
語法如下：
// geo_bounding_box查詢
GET /indexName/_search
{
"query": {
"geo_bounding_box": {
"FIELD": {
"top_left": { // 左上點
"lat": 31.1,
"lon": 121.5
},
"bottom_right": { // 右下點
"lat": 30.9,
"lon": 121.7
}
}
}
}
}
這種并不符合“附近的人”這樣的需求。
附近查詢
附近查詢，也叫做距離查詢（geo_distance）：查詢到指定中心點小于某個距離值的所有文檔。
換句話來說，在地圖上找一個點作為圓心，以指定距離為半徑，畫一個圓，落在圓內(nèi)的坐標都算符合條件：
語法說明：
// geo_distance 查詢
GET /indexName/_search
{
"query": {
"geo_distance": {
"distance": "15km", // 半徑
"FIELD": "31.21,121.5" // 圓心
}
}
}
示例：
我們先搜索陸家嘴附近15km的酒店：
然后把半徑縮短到3公里：
縮小到 3 公里我們看到就剩下了5個符合條件的
?復合查詢
復合（compound）查詢：復合查詢可以將其它簡單查詢組合起來，實現(xiàn)更復雜的搜索邏輯。常見的有兩種：
- fuction score：算分函數(shù)查詢，可以控制文檔相關(guān)性算分，控制文檔排名
- bool query：布爾查詢，利用邏輯關(guān)系組合多個其它的查詢，實現(xiàn)復雜搜索
相關(guān)性算分
當我們利用match查詢時，文檔結(jié)果會根據(jù)與搜索詞條的關(guān)聯(lián)度打分（_score），返回結(jié)果時按照分值降序排列。
例如，我們搜索 “虹橋如家”，結(jié)果如下：
[
{
"_score" : 17.850193,
"_source" : {
"name" : "虹橋如家酒店真不錯",
}
},
{
"_score" : 12.259849,
"_source" : {
"name" : "外灘如家酒店真不錯",
}
},
{
"_score" : 11.91091,
"_source" : {
"name" : "迪士尼如家酒店真不錯",
}
}
]
在ElasticSearch中，早期使用的打分算法是TF-IDF算法，公式如下：
在后來的5.1版本升級中，ElasticSearch將算法改進為BM25算法，公式如下：
TF-IDF算法有一各缺陷，就是詞條頻率越高，文檔得分也會越高，單個詞條對文檔影響較大。而BM25則會讓單個詞條的算分有一個上限，曲線更加平滑：
ElasticSearch會根據(jù)詞條和文檔的相關(guān)度做打分，算法由兩種：
- TF-IDF算法
- BM25算法，ElasticSearch5.1版本后采用的算法
算分函數(shù)查詢
根據(jù)相關(guān)度打分是比較合理的需求，但合理的不一定是產(chǎn)品經(jīng)理需要的。
以百度為例，你搜索的結(jié)果中，并不是相關(guān)度越高排名越靠前，而是誰掏的錢多排名就越靠前。如圖：
要想認為控制相關(guān)性算分，就需要利用ElasticSearch中的 Function Score 查詢了。
語法說明
Function Score 查詢中包含四部分內(nèi)容：
- 原始查詢條件：query部分，基于這個條件搜索文檔，并且基于BM25算法給文檔打分，原始算分（query score)
- 過濾條件：filter部分，符合該條件的文檔才會重新算分
-
算分函數(shù)：符合filter條件的文檔要根據(jù)這個函數(shù)做運算，得到的函數(shù)算分（function score），有四種函數(shù)
- weight：函數(shù)結(jié)果是常量
- field_value_factor：以文檔中的某個字段值作為函數(shù)結(jié)果
- random_score：以隨機數(shù)作為函數(shù)結(jié)果
- script_score：自定義算分函數(shù)算法
-
運算模式：算分函數(shù)的結(jié)果、原始查詢的相關(guān)性算分，兩者之間的運算方式，包括：
- multiply：相乘
- replace：用function score替換query score
- 其它，例如：sum、avg、max、min
function score的運行流程如下：
- 1）根據(jù)原始條件查詢搜索文檔，并且計算相關(guān)性算分，稱為原始算分（query score）
- 2）根據(jù)過濾條件，過濾文檔
- 3）符合過濾條件的文檔，基于算分函數(shù)運算，得到函數(shù)算分（function score）
- 4）將原始算分（query score）和函數(shù)算分（function score）基于運算模式做運算，得到最終結(jié)果，作為相關(guān)性算分。
因此，其中的關(guān)鍵點是：
- 過濾條件：決定哪些文檔的算分被修改
- 算分函數(shù)：決定函數(shù)算分的算法
- 運算模式：決定最終算分結(jié)果
實例
需求：給“如家”這個品牌的酒店排名靠前一些
翻譯一下這個需求，轉(zhuǎn)換為之前說的四個要點：
- 原始條件：不確定，可以任意變化
- 過濾條件：brand = “如家”
- 算分函數(shù)：可以簡單粗暴，直接給固定的算分結(jié)果，weight
- 運算模式：比如求和
因此最終的DSL語句如下：
GET /hotel/_search
{
"query": {
"function_score": {
"query": { .... }, // 原始查詢，可以是任意條件
"functions": [ // 算分函數(shù)
{
"filter": { // 滿足的條件，品牌必須是如家
"term": {
"brand": "如家"
}
},
"weight": 2 // 算分權(quán)重為2
}
],
"boost_mode": "sum" // 加權(quán)模式，求和
}
}
}
測試，在未添加算分函數(shù)時，如家得分如下：
添加了算分函數(shù)后，如家得分就提升了：
Function Score Query定義的三要素是什么？
- 過濾條件：哪些文檔要加分
- 算分函數(shù)：如何計算Function Score
- 加權(quán)方式：Function Score 與 Query Score如何運算
布爾查詢
布爾查詢是一個或多個查詢子句的組合，每一個子句就是一個子查詢。子查詢的組合方式有：
- must：必須匹配每個子查詢，類似“與”
- should：選擇性匹配子查詢，類似“或”
- must_not：必須不匹配，不參與算分，類似“非”
- filter：必須匹配，不參與算分
比如在搜索酒店時，除了關(guān)鍵字搜索外，我們還可能根據(jù)品牌、價格、城市等字段做過濾：
每一個不同的字段，其查詢的條件、方式都不一樣，必須是多個不同的查詢，而要組合這些查詢，就必須用bool查詢了。
需要注意的是，搜索時，參與打分的字段越多，查詢的性能也越差。因此這種多條件查詢時，建議這樣做：
- 搜索框的關(guān)鍵字搜索，是全文檢索查詢，使用must查詢，參與算分
- 其它過濾條件，采用filter查詢。不參與算分
語法實例
GET /hotel/_search
{
"query": {
"bool": {
"must": [
{"term": {"city": "上海" }}
],
"should": [
{"term": {"brand": "皇冠假日" }},
{"term": {"brand": "華美達" }}
],
"must_not": [
{ "range": { "price": { "lte": 500 } }}
],
"filter": [
{ "range": {"score": { "gte": 45 } }}
]
}
}
}
實例
需求：搜索名字包含“如家”，價格不高于400，在坐標31.21,121.5周圍10km范圍內(nèi)的酒店。
分析：
- 名稱搜索，屬于全文檢索查詢，應(yīng)該參與算分。放到must中
- 價格不高于400，用range查詢，屬于過濾條件，不參與算分。放到must_not中
- 周圍10km范圍內(nèi)，用geo_distance查詢，屬于過濾條件，不參與算分。放到filter中
bool查詢有幾種邏輯關(guān)系？
- must：必須匹配的條件，可以理解為“與”
- should：選擇性匹配的條件，可以理解為“或”
- must_not：必須不匹配的條件，不參與打分
- filter：必須匹配的條件，不參與打分
?小結(jié)
以上就是【Bug 終結(jié)者】對 微服務(wù)分布式搜索引擎 Elastic Search RestClient 操作文檔 的簡單介紹，ES搜索引擎無疑是最優(yōu)秀的分布式搜索引擎，使用它，可大大提高項目的靈活、高效性！ 技術(shù)改變世界?。?！文章來源：http://www.zghlxwxcb.cn/news/detail-413900.html
如果這篇【文章】有幫助到你，希望可以給【Bug 終結(jié)者】點個贊??，創(chuàng)作不易，如果有對【后端技術(shù)】、【前端領(lǐng)域】感興趣的小可愛，也歡迎關(guān)注?????? 【Bug 終結(jié)者】??????，我將會給你帶來巨大的【收獲與驚喜】??????！文章來源地址http://www.zghlxwxcb.cn/news/detail-413900.html
到了這里，關(guān)于微服務(wù)分布式搜索引擎 ElasticSearch 查詢文檔的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！
