1.DSL查詢文檔
elasticsearch的查詢依然是基于JSON風(fēng)格的DSL來實(shí)現(xiàn)的。
1.1.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
-
復(fù)合（compound）查詢：復(fù)合查詢可以將上述各種查詢條件組合起來，合并查詢條件。例如：
- bool
- function_score
查詢的語法基本一致：
GET /indexName/_search
{
"query": {
"查詢類型": {
"查詢條件": "條件值"
}
}
}
我們以查詢所有為例，其中：
- 查詢類型為match_all
- 沒有查詢條件
// 查詢所有
GET /indexName/_search
{
"query": {
"match_all": {
}
}
}
其它查詢無非就是查詢類型、查詢條件的變化。
1.2.全文檢索查詢
1.2.1.使用場景
全文檢索查詢的基本流程如下：
- 對用戶搜索的內(nèi)容做分詞，得到詞條
- 根據(jù)詞條去倒排索引庫中匹配，得到文檔id
- 根據(jù)文檔id找到文檔，返回給用戶
比較常用的場景包括：
- 百度輸入框搜索
- 商城的輸入框搜索
例如百度搜索：
因?yàn)槭悄弥~條去匹配，因此參與搜索的字段也必須是可分詞的text類型的字段。
1.2.2.基本語法
常見的全文檢索查詢包括：
- match查詢：單字段查詢
- multi_match查詢：多字段查詢，任意一個(gè)字段符合條件就算符合查詢條件
match查詢語法如下：
GET /indexName/_search
{
"query": {
"match": {
"FIELD": "TEXT"
}
}
}
mulit_match語法如下：
GET /indexName/_search
{
"query": {
"multi_match": {
"query": "TEXT",
"fields": ["FIELD1", " FIELD12"]
}
}
}
1.2.3.示例
match查詢示例：
multi_match查詢示例：
可以看到，兩種查詢結(jié)果是一樣的，為什么？
因?yàn)槲覀儗ame、remark值都利用copy_to復(fù)制到了all字段中。因此你根據(jù)三個(gè)字段搜索，和根據(jù)all字段搜索效果當(dāng)然一樣了。
但是，搜索字段越多，對查詢性能影響越大，因此建議采用copy_to，然后單字段查詢的方式。
1.2.4.總結(jié)
match和multi_match的區(qū)別是什么？
- match：根據(jù)一個(gè)字段查詢
- multi_match：根據(jù)多個(gè)字段查詢，參與查詢字段越多，查詢性能越差
1.3.精準(zhǔn)查詢
精確查詢一般是查找keyword、數(shù)值、日期、boolean等類型字段。所以不會(huì)對搜索條件分詞。常見的有：
- term：根據(jù)詞條精確值查詢
- range：根據(jù)值的范圍查詢
1.3.1.term查詢
因?yàn)榫_查詢的字段搜是不分詞的字段，因此查詢的條件也必須是不分詞的詞條。查詢時(shí)，用戶輸入的內(nèi)容跟自動(dòng)值完全匹配時(shí)才認(rèn)為符合條件。如果用戶輸入的內(nèi)容過多，反而搜索不到數(shù)據(jù)。
語法說明：
// term查詢
GET /indexName/_search
{
"query": {
"term": {
"FIELD": {
"value": "VALUE"
}
}
}
}
示例：
當(dāng)我搜索的是精確詞條時(shí)，能正確查詢出結(jié)果：
但是，當(dāng)我搜索的內(nèi)容不是詞條，而是多個(gè)詞語形成的短語時(shí)，反而搜索不到：
1.3.2.range查詢
范圍查詢，一般應(yīng)用在對數(shù)值類型做范圍過濾的時(shí)候。比如做價(jià)格范圍過濾。
基本語法：
// range查詢
GET /indexName/_search
{
"query": {
"range": {
"FIELD": {
"gte": 10, // 這里的gte代表大于等于，gt則代表大于
"lte": 20 // lte代表小于等于，lt則代表小于
}
}
}
}
示例：
1.3.3.總結(jié)
精確查詢常見的有哪些？
- term查詢：根據(jù)詞條精確匹配，一般搜索keyword類型、數(shù)值類型、布爾類型、日期類型字段
- range查詢：根據(jù)數(shù)值范圍查詢，可以是數(shù)值、日期的范圍
1.4.地理坐標(biāo)查詢
所謂的地理坐標(biāo)查詢，其實(shí)就是根據(jù)經(jīng)緯度查詢，官方文檔進(jìn)入
常見的使用場景包括：
- 微信：發(fā)現(xiàn)選項(xiàng)里的附近
- 滴滴：搜索我附近的出租車
- 攜程：搜索我附近的酒店
1.4.1.矩形范圍查詢
矩形范圍查詢，也就是geo_bounding_box查詢，查詢坐標(biāo)落在某個(gè)矩形范圍的所有文檔：
查詢時(shí)，需要指定矩形的左上、右下兩個(gè)點(diǎn)的坐標(biāo)，然后畫出一個(gè)矩形，落在該矩形內(nèi)的都是符合條件的點(diǎn)。
語法如下：
// geo_bounding_box查詢
GET /indexName/_search
{
"query": {
"geo_bounding_box": {
"FIELD": {
"top_left": { // 左上點(diǎn)
"lat": 31.1,
"lon": 121.5
},
"bottom_right": { // 右下點(diǎn)
"lat": 30.9,
"lon": 121.7
}
}
}
}
}
這種并不符合“附近的人”這樣的需求，所以我們就不做了。
1.4.2.附近查詢
附近查詢，也叫做距離查詢（geo_distance）：查詢到指定中心點(diǎn)小于某個(gè)距離值的所有文檔。
換句話來說，在地圖上找一個(gè)點(diǎn)作為圓心，以指定距離為半徑，畫一個(gè)圓，落在圓內(nèi)的坐標(biāo)都算符合條件：
語法說明：
// geo_distance 查詢
GET /indexName/_search
{
"query": {
"geo_distance": {
"distance": "15km", // 半徑
"FIELD": "31.21,121.5" // 圓心
}
}
}
1.5.復(fù)合查詢
復(fù)合（compound）查詢：復(fù)合查詢可以將其它簡單查詢組合起來，實(shí)現(xiàn)更復(fù)雜的搜索邏輯。常見的有兩種：
- fuction score：算分函數(shù)查詢，可以控制文檔相關(guān)性算分，控制文檔排名
- bool query：布爾查詢，利用邏輯關(guān)系組合多個(gè)其它的查詢，實(shí)現(xiàn)復(fù)雜搜索
1.5.1.布爾查詢
布爾查詢是一個(gè)或多個(gè)查詢子句的組合，每一個(gè)子句就是一個(gè)子查詢。子查詢的組合方式有：
- must：必須匹配每個(gè)子查詢，類似“與”
- should：選擇性匹配子查詢，類似“或”
- must_not：必須不匹配，不參與算分，類似“非”
- filter：必須匹配，不參與算分
每一個(gè)不同的字段，其查詢的條件、方式都不一樣，必須是多個(gè)不同的查詢，而要組合這些查詢，就必須用bool查詢了。
需要注意的是，搜索時(shí)，參與打分的字段越多，查詢的性能也越差。因此這種多條件查詢時(shí)，建議這樣做：
- 搜索框的關(guān)鍵字搜索，是全文檢索查詢，使用must查詢，參與算分
- 其它過濾條件，采用filter查詢。不參與算分
1）語法示例：
GET /haohong/_search
{
"query": {
"bool": {
"must": [
{"term": {"name": "leiyang" }}
],
"should": [
{"term": {"isMarriott": false}}
],
"must_not": [
{ "range": { "age": { "lte": 18} }}
],
"filter": [
{ "range": {"score": { "gte": 45 } }}
]
}
}
}
2）小結(jié)
bool查詢有幾種邏輯關(guān)系？
- must：必須匹配的條件，可以理解為“與”
- should：選擇性匹配的條件，可以理解為“或”
- must_not：必須不匹配的條件，不參與打分
- filter：必須匹配的條件，不參與打分
2.搜索結(jié)果處理
搜索的結(jié)果可以按照用戶指定的方式去處理或展示。
2.1.排序
elasticsearch默認(rèn)是根據(jù)相關(guān)度算分（_score）來排序，但是也支持自定義方式對搜索結(jié)果排序。可以排序字段類型有：keyword類型、數(shù)值類型、地理坐標(biāo)類型、日期類型等。
2.1.1.普通字段排序
keyword、數(shù)值、日期類型排序的語法基本一致。
語法：
GET /indexName/_search
{
"query": {
"match_all": {}
},
"sort": [
{
"FIELD": "desc" // 排序字段、排序方式ASC、DESC
}
]
}
排序條件是一個(gè)數(shù)組，也就是可以寫多個(gè)排序條件。按照聲明的順序，當(dāng)?shù)谝粋€(gè)條件相等時(shí)，再按照第二個(gè)條件排序，以此類推
2.2.分頁
elasticsearch 默認(rèn)情況下只返回top10的數(shù)據(jù)。而如果要查詢更多數(shù)據(jù)就需要修改分頁參數(shù)了。elasticsearch中通過修改from、size參數(shù)來控制要返回的分頁結(jié)果：
- from：從第幾個(gè)文檔開始
- size：總共查詢幾個(gè)文檔
類似于mysql中的limit ?, ?
2.2.1.基本的分頁
分頁的基本語法如下：
GET /hotel/_search
{
"query": {
"match_all": {}
},
"from": 0, // 分頁開始的位置，默認(rèn)為0
"size": 10, // 期望獲取的文檔總數(shù)
"sort": [
{"price": "asc"}
]
}
2.2.2.深度分頁問題
現(xiàn)在，我要查詢990~1000的數(shù)據(jù)，查詢邏輯要這么寫：
GET /hotel/_search
{
"query": {
"match_all": {}
},
"from": 990, // 分頁開始的位置，默認(rèn)為0
"size": 10, // 期望獲取的文檔總數(shù)
"sort": [
{"price": "asc"}
]
}
這里是查詢990開始的數(shù)據(jù)，也就是 第990~第1000條 數(shù)據(jù)。
不過，elasticsearch內(nèi)部分頁時(shí)，必須先查詢 0~1000條，然后截取其中的990 ~ 1000的這10條：
查詢TOP1000，如果es是單點(diǎn)模式，這并無太大影響。
但是elasticsearch將來一定是集群，例如我集群有5個(gè)節(jié)點(diǎn)，我要查詢TOP1000的數(shù)據(jù)，并不是每個(gè)節(jié)點(diǎn)查詢200條就可以了。
因?yàn)楣?jié)點(diǎn)A的TOP200，在另一個(gè)節(jié)點(diǎn)可能排到10000名以外了。
因此要想獲取整個(gè)集群的TOP1000，必須先查詢出每個(gè)節(jié)點(diǎn)的TOP1000，匯總結(jié)果后，重新排名，重新截取TOP1000。
那如果我要查詢9900~10000的數(shù)據(jù)呢？是不是要先查詢TOP10000呢？那每個(gè)節(jié)點(diǎn)都要查詢10000條？匯總到內(nèi)存中？
當(dāng)查詢分頁深度較大時(shí)，匯總數(shù)據(jù)過多，對內(nèi)存和CPU會(huì)產(chǎn)生非常大的壓力，因此elasticsearch會(huì)禁止from+ size 超過10000的請求。
針對深度分頁，ES提供了兩種解決方案，官方文檔：
- search after：分頁時(shí)需要排序，原理是從上一次的排序值開始，查詢下一頁數(shù)據(jù)。官方推薦使用的方式。
- scroll：原理將排序后的文檔id形成快照，保存在內(nèi)存。官方已經(jīng)不推薦使用。
2.2.3.小結(jié)
分頁查詢的常見實(shí)現(xiàn)方案以及優(yōu)缺點(diǎn)：
-
from + size：- 優(yōu)點(diǎn)：支持隨機(jī)翻頁
- 缺點(diǎn)：深度分頁問題，默認(rèn)查詢上限（from + size）是10000
- 場景：百度、京東、谷歌、淘寶這樣的隨機(jī)翻頁搜索
-
after search：- 優(yōu)點(diǎn)：沒有查詢上限（單次查詢的size不超過10000）
- 缺點(diǎn)：只能向后逐頁查詢，不支持隨機(jī)翻頁
- 場景：沒有隨機(jī)翻頁需求的搜索，例如手機(jī)向下滾動(dòng)翻頁
-
scroll：- 優(yōu)點(diǎn)：沒有查詢上限（單次查詢的size不超過10000）
- 缺點(diǎn)：會(huì)有額外內(nèi)存消耗，并且搜索結(jié)果是非實(shí)時(shí)的
- 場景：海量數(shù)據(jù)的獲取和遷移。從ES7.1開始不推薦，建議用 after search方案。
2.3.高亮
2.3.1.高亮原理
什么是高亮顯示呢？
我們在百度，京東搜索時(shí)，關(guān)鍵字會(huì)變成紅色，比較醒目，這叫高亮顯示：
高亮顯示的實(shí)現(xiàn)分為兩步：
- 1）給文檔中的所有關(guān)鍵字都添加一個(gè)標(biāo)簽，例如
<em>標(biāo)簽 - 2）頁面給
<em>標(biāo)簽編寫CSS樣式
2.3.2.實(shí)現(xiàn)高亮
高亮的語法：
GET /hotel/_search
{
"query": {
"match": {
"FIELD": "TEXT" // 查詢條件，高亮一定要使用全文檢索查詢
}
},
"highlight": {
"fields": { // 指定要高亮的字段
"FIELD": {
"pre_tags": "<em>", // 用來標(biāo)記高亮字段的前置標(biāo)簽
"post_tags": "</em>" // 用來標(biāo)記高亮字段的后置標(biāo)簽
}
}
}
}
注意：
- 高亮是對關(guān)鍵字高亮，因此搜索條件必須帶有關(guān)鍵字，而不能是范圍這樣的查詢。
- 默認(rèn)情況下，高亮的字段，必須與搜索指定的字段一致，否則無法高亮
- 如果要對非搜索字段高亮，則需要添加一個(gè)屬性：required_field_match=false
2.4.總結(jié)
查詢的DSL是一個(gè)大的JSON對象，包含下列屬性：
- query：查詢條件
- from和size：分頁條件
- sort：排序條件
- highlight：高亮條件
