當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

【微服务】DSL查询文档

發布時間：2024/1/1 编程问答 36 豆豆

生活随笔收集整理的這篇文章主要介紹了【微服务】DSL查询文档小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

elasticsearch的查詢依然是基于JSON風格的DSL來實現的。

1 DSL查詢分類

Elasticsearch提供了基于JSON的DSL（Domain Specific Language）來定義查詢。常見的查詢類型包括：

查詢所有：查詢出所有數據，一般測試用。例如：match_all
全文檢索（full text）查詢：利用分詞器對用戶輸入內容分詞，然后去倒排索引庫中匹配。例如：
- match_query
- multi_match_query
精確查詢：根據精確詞條值查找數據，一般是查找keyword、數值、日期、boolean等類型字段。例如：
- ids
- range
- term
地理（geo）查詢：根據經緯度查詢。例如：
- geo_distance
- geo_bounding_box
復合（compound）查詢：復合查詢可以將上述各種查詢條件組合起來，合并查詢條件。例如：
- bool
- function_score

查詢的語法基本一致：

GET /indexName/_search {"query": {"查詢類型": {"查詢條件": "條件值"}} }

2 查詢所有

我們以查詢所有為例，其中：

查詢類型為match_all
沒有查詢條件

// 查詢所有 GET /indexName/_search {"query": {"match_all": {}} }

其它查詢無非就是查詢類型、查詢條件的變化。

2.1 示例

3 全文檢索查詢

3.1 使用場景

全文檢索查詢的基本流程如下：

對用戶搜索的內容做分詞，得到詞條
根據詞條去倒排索引庫中匹配，得到文檔id
根據文檔id找到文檔，返回給用戶

比較常用的場景包括：

商城的輸入框搜索
百度輸入框搜索

例如京東：

因為是拿著詞條去匹配，因此參與搜索的字段也必須是可分詞的text類型的字段。

3.2 基本語法

常見的全文檢索查詢包括：

match查詢：單字段查詢
multi_match查詢：多字段查詢，任意一個字段符合條件就算符合查詢條件

match查詢語法如下：

GET /indexName/_search {"query": {"match": {"FIELD": "TEXT"}} }

mulit_match語法如下：

GET /indexName/_search {"query": {"multi_match": {"query": "TEXT","fields": ["FIELD1", " FIELD2"]}} }

3.3 示例

match查詢示例：

multi_match查詢示例：

可以看到，兩種查詢結果是一樣的，為什么？

因為我們將brand、name值都利用copy_to復制到了all字段中。因此你根據這兩個字段搜索，和根據all字段搜索效果當然一樣了。

但是，搜索字段越多，對查詢性能影響越大，因此建議采用copy_to，然后單字段（match）查詢的方式。

3.4 總結

match和multi_match的區別是什么？

match：根據一個字段查詢
multi_match：根據多個字段查詢，參與查詢字段越多，查詢性能越差

4 精準查詢

精確查詢一般是查找keyword、數值、日期、boolean等類型字段。所以不會對搜索條件分詞。常見的有：

ids：根據id查詢
term：根據詞條精確值查詢
range：根據值的范圍查詢

4.1 ids查詢

根據 ID 返回文檔。此查詢使用存儲在 _id 字段中的文檔ID

基本語法：

// ids查詢 GET /indexName/_search {"query": {"ids" : {"values" : ["1", "4", "100"]}} }

values (必填, 字符串數組) 文檔的_id的數組

4.2 term查詢

因為精確查詢的字段搜是不分詞的字段，因此查詢的條件也必須是不分詞的詞條。查詢時，用戶輸入的內容跟自動值完全匹配時才認為符合條件。如果用戶輸入的內容過多，反而搜索不到數據。

語法說明：

// term查詢 GET /indexName/_search {"query": {"term": {"FIELD": {"value": "VALUE"}}} }

示例：

當我搜索的是精確詞條時，能正確查詢出結果：

但是，當我搜索的內容不是詞條，而是多個詞語形成的短語時，反而搜索不到：

4.3 range查詢

范圍查詢，一般應用在對數值類型做范圍過濾的時候。比如做價格范圍過濾。

基本語法：

// range查詢 GET /indexName/_search {"query": {"range": {"FIELD": {"gte": 10, // 這里的gte代表大于等于，gt則代表大于"lte": 20 // lte代表小于等于，lt則代表小于}}} }

示例：

4.4 總結

精確查詢常見的有哪些？

ids查詢：根據 ID 返回文檔。此查詢使用存儲在 _id 字段中的文檔ID
term查詢：根據詞條精確匹配，一般搜索keyword類型、數值類型、布爾類型、日期類型字段
range查詢：根據數值范圍查詢，可以是數值、日期的范圍

5 地理坐標查詢

所謂的地理坐標查詢，其實就是根據經緯度查詢，官方文檔：https://www.elastic.co/guide/en/elasticsearch/reference/current/geo-queries.html

常見的使用場景包括：

攜程：搜索我附近的酒店
滴滴：搜索我附近的出租車
微信：搜索我附近的人

5.1 矩形范圍查詢

矩形范圍查詢，也就是geo_bounding_box查詢，查詢坐標落在某個矩形范圍的所有文檔：

查詢時，需要指定矩形的左上、右下兩個點的坐標，然后畫出一個矩形，落在該矩形內的都是符合條件的點。

語法如下：

// 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}}}} }

這種并不符合“附近的人”這樣的需求，所以我們就不做了。

5.2 附近查詢

附近查詢，也叫做距離查詢（geo_distance）：查詢到指定中心點小于某個距離值的所有文檔。

換句話來說，在地圖上找一個點作為圓心，以指定距離為半徑，畫一個圓，落在圓內的坐標都算符合條件：

語法說明：

// geo_distance 查詢 GET /indexName/_search {"query": {"geo_distance": {"distance": "15km", // 半徑"FIELD": "31.21,121.5" // 圓心}} }

示例：

我們先搜索陸家嘴附近15km的酒店：

發現共有47家酒店。

然后把半徑縮短到3公里：

可以發現，搜索到的酒店數量減少到了5家。

6 復合查詢

復合（compound）查詢：復合查詢可以將其它簡單查詢組合起來，實現更復雜的搜索邏輯。常見的有兩種：

fuction score：算分函數查詢，可以控制文檔相關性算分，控制文檔排名
bool query：布爾查詢，利用邏輯關系組合多個其它的查詢，實現復雜搜索

6.1 相關性算分

當我們利用match查詢時，文檔結果會根據與搜索詞條的關聯度打分（_score），返回結果時按照分值降序排列。

例如，我們搜索 “虹橋如家”，結果如下：

[{"_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會根據詞條和文檔的相關度做打分，算法由兩種：

TF-IDF算法：在elasticsearch5.0之前，會隨著詞頻增加而越來越大
BM25算法：在elasticsearch5.0之后，會隨著詞頻增加而增大，但增長曲線會趨于水平

6.2 算分函數查詢

根據相關度打分是比較合理的需求，但合理的不一定是產品經理需要的。

以百度為例，你搜索的結果中，并不是相關度越高排名越靠前，而是誰掏的錢多排名就越靠前。如圖：

要想認為控制相關性算分，就需要利用elasticsearch中的function score 查詢了。

6.2.1 語法說明

function score 查詢中包含四部分內容：

原始查詢條件：query部分，基于這個條件搜索文檔，并且基于BM25算法給文檔打分，原始算分（query score)
過濾條件：filter部分，符合該條件的文檔才會重新算分
算分函數：符合filter條件的文檔要根據這個函數做運算，得到的函數算分（function score），有四種函數
- weight：函數結果是常量
- field_value_factor：以文檔中的某個字段值作為函數結果
- random_score：以隨機數作為函數結果
- script_score：自定義算分函數算法
運算模式：算分函數的結果、原始查詢的相關性算分，兩者之間的運算方式，包括：
- multiply：相乘
- replace：用function score替換query score
- 其它，例如：sum、avg、max、min

function score的運行流程如下：

1）根據原始條件查詢搜索文檔，并且計算相關性算分，稱為原始算分（query score）
2）根據過濾條件，過濾文檔
3）符合過濾條件的文檔，基于算分函數運算，得到函數算分（function score）
4）將原始算分（query score）和函數算分（function score）基于運算模式做運算，得到最終結果，作為相關性算分。

因此，其中的關鍵點是：

過濾條件：決定哪些文檔的算分被修改
算分函數：決定函數算分的算法
運算模式：決定最終算分結果

6.2.2 示例

需求：給“如家”這個品牌的酒店排名靠前一些

翻譯一下這個需求，轉換為之前說的四個要點：

原始條件：不確定，可以任意變化
過濾條件：brand = “如家”
算分函數：可以簡單粗暴，直接給固定的算分結果，weight
運算模式：比如求和

因此最終的DSL語句如下：

GET /hotel/_search {"query": {"function_score": {"query": { .... }, // 原始查詢，可以是任意條件"functions": [ // 算分函數{"filter": { // 滿足的條件，品牌必須是如家"term": {"brand": "如家"}},"weight": 2 // 算分權重為2}],"boost_mode": "sum" // 加權模式，求和}} }

測試，在未添加算分函數時，如家得分如下：

添加了算分函數后，如家得分就提升了：

6.2.3 小結

function score query定義的三要素是什么？

過濾條件：哪些文檔要加分
算分函數：如何計算function score
加權方式：function score 與 query score如何運算

6.3 布爾查詢

布爾查詢是一個或多個查詢子句的組合，每一個子句就是一個子查詢。子查詢的組合方式有：

must：必須匹配每個子查詢，類似“與”，參與算分
should：選擇性匹配子查詢，類似“或”，參與算分
must_not：必須不匹配，不參與算分，類似“非”
filter：必須匹配，不參與算分

比如在搜索酒店時，除了關鍵字搜索外，我們還可能根據品牌、價格、城市等字段做過濾：

每一個不同的字段，其查詢的條件、方式都不一樣，必須是多個不同的查詢，而要組合這些查詢，就必須用bool查詢了。

需要注意的是，搜索時，參與打分的字段越多，查詢的性能也越差。因此這種多條件查詢時，建議這樣做：

搜索框的關鍵字搜索，是全文檢索查詢，使用must查詢，參與算分
其它過濾條件，采用filter查詢。不參與算分

6.3.1 語法示例

GET /hotel/_search {"query": {"bool": {"must": [{"term": {"city": "上海" }}],"should": [{"term": {"brand": "皇冠假日" }},{"term": {"brand": "華美達" }}],"must_not": [{ "range": { "price": { "lte": 500 } }}],"filter": [{ "range": {"score": { "gte": 45 } }}]}} }

6.3.2 示例

需求：搜索名字包含“如家”，價格不高于400，在坐標31.21,121.5周圍10km范圍內的酒店。

分析：

名稱搜索，屬于全文檢索查詢，應該參與算分。放到must中
價格不高于400，用range查詢，屬于過濾條件，不參與算分。放到must_not中
周圍10km范圍內，用geo_distance查詢，屬于過濾條件，不參與算分。放到filter中

6.3.3 小結

bool查詢有幾種邏輯關系？

must：必須匹配的條件，可以理解為“與”，參與打分
should：選擇性匹配的條件，可以理解為“或”，參與打分
must_not：必須不匹配的條件，不參與打分
filter：必須匹配的條件，不參與打分

7 排序

elasticsearch默認是根據相關度算分（_score）來排序，但是也支持自定義方式對搜索結果排序。可以排序字段類型有：keyword類型、數值類型、地理坐標類型、日期類型等。

7.1 普通字段排序

keyword、數值、日期類型排序的語法基本一致。

語法：

GET /indexName/_search {"query": {"match_all": {}},"sort": [{"FIELD": "desc" // 排序字段、排序方式ASC、DESC}] }

排序條件是一個數組，也就是可以寫多個排序條件。按照聲明的順序，當第一個條件相等時，再按照第二個條件排序，以此類推

示例：

需求描述：酒店數據按照用戶評價（score)降序排序，評價相同的按照價格(price)升序排序

7.2 地理坐標排序

地理坐標排序略有不同。

語法說明：

GET /indexName/_search {"query": {"match_all": {}},"sort": [{"_geo_distance" : {"FIELD" : "緯度，經度", // 文檔中geo_point類型的字段名、目標坐標點"order" : "asc", // 排序方式"unit" : "km" // 排序的距離單位}}] }

這個查詢的含義是：

指定一個坐標，作為目標點
計算每一個文檔中，指定字段（必須是geo_point類型）的坐標到目標點的距離是多少
根據距離排序

示例：

需求描述：實現對酒店數據按照到你的位置坐標的距離升序排序

提示：獲取你的位置的經緯度的方式：https://lbs.amap.com/demo/jsapi-v2/example/map/click-to-get-lnglat/

假設我的位置是：31.034661，121.612282，尋找我周圍距離最近的酒店。

"location":{"lat": 31.034661,"lon": 121.612282 }

和

"location": "31.034661, 121.612282"

等價

8 分頁

elasticsearch 默認情況下只返回top10的數據。而如果要查詢更多數據就需要修改分頁參數了。elasticsearch中通過修改from、size參數來控制要返回的分頁結果：

from：從第幾個文檔開始
size：總共查詢幾個文檔

類似于mysql中的limit ?, ?

8.1 基本的分頁

分頁的基本語法如下：

GET /hotel/_search {"query": {"match_all": {}},"from": 0, // 分頁開始的位置，默認為0"size": 10, // 期望獲取的文檔總數"sort": [{"price": "asc"}] }

8.2 深度分頁問題

現在，我要查詢990~1000的數據，查詢邏輯要這么寫：

GET /hotel/_search {"query": {"match_all": {}},"from": 990, // 分頁開始的位置，默認為0"size": 10, // 期望獲取的文檔總數"sort": [{"price": "asc"}] }

這里是查詢990開始的數據，也就是第990~第1000條數據。

不過，elasticsearch內部分頁時，必須先查詢 0~1000條，然后截取其中的990 ~ 1000的這10條：

查詢TOP1000，如果es是單點模式，這并無太大影響。

但是elasticsearch將來一定是集群，例如我集群有5個節點，我要查詢TOP1000的數據，并不是每個節點查詢200條就可以了。

因為節點A的TOP200，在另一個節點可能排到10000名以外了。

因此要想獲取整個集群的TOP1000，必須先查詢出每個節點的TOP1000，匯總結果后，重新排名，重新截取TOP1000。

那如果我要查詢9900~10000的數據呢？是不是要先查詢TOP10000呢？那每個節點都要查詢10000條？匯總到內存中？

當查詢分頁深度較大時，匯總數據過多，對內存和CPU會產生非常大的壓力，因此elasticsearch會禁止from+ size 超過10000的請求。

針對深度分頁，ES提供了兩種解決方案，官方文檔：

search after：分頁時需要排序，原理是從上一次的排序值開始，查詢下一頁數據。官方推薦使用的方式。
scroll：原理將排序后的文檔id形成快照，保存在內存。官方已經不推薦使用。

8.3 小結

分頁查詢的常見實現方案以及優缺點：

from + size：
- 優點：支持隨機翻頁
- 缺點：深度分頁問題，默認查詢上限（from + size）是10000
- 場景：百度、京東、谷歌、淘寶這樣的隨機翻頁搜索
after search：
- 優點：沒有查詢上限（單次查詢的size不超過10000）
- 缺點：只能向后逐頁查詢，不支持隨機翻頁
- 場景：沒有隨機翻頁需求的搜索，例如手機向下滾動翻頁
scroll：
- 優點：沒有查詢上限（單次查詢的size不超過10000）
- 缺點：會有額外內存消耗，并且搜索結果是非實時的
- 場景：海量數據的獲取和遷移。從ES7.1開始不推薦，建議用 after search方案。

9 高亮

9.1 高亮原理

什么是高亮顯示呢？我們在百度，京東搜索時，關鍵字會變成紅色，比較醒目，這叫高亮顯示：

高亮顯示的實現分為兩步：

1）給文檔中的所有關鍵字都添加一個標簽，例如<em>標簽
2）頁面給<em>標簽編寫CSS樣式

9.2 實現高亮

高亮的語法：

GET /hotel/_search {"query": {"match": {"FIELD": "TEXT" // 查詢條件，高亮一定要使用全文檢索查詢}},"highlight": {"fields": { // 指定要高亮的字段"FIELD": {"pre_tags": "<em>", // 用來標記高亮字段的前置標簽"post_tags": "</em>" // 用來標記高亮字段的后置標簽}}} }

注意：

高亮是對關鍵字高亮，因此搜索條件必須帶有關鍵字，而不能是范圍這樣的查詢。
默認情況下，高亮的字段，必須與搜索指定的字段一致，否則無法高亮
如果要對非搜索字段高亮，則需要添加一個屬性：required_field_match=false

示例：

默認就是加標簽

10 總結

查詢的DSL是一個大的JSON對象，包含下列屬性：

query：查詢條件
from和size：分頁條件
sort：排序條件
highlight：高亮條件

示例：

總結

以上是生活随笔為你收集整理的【微服务】DSL查询文档的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

文档
dsl

上一篇： Java代码实现SMS短信发送功能
下一篇： CDH6.2.1 hive2.1导入or