搜尋介面概述

節點

說明對應資料庫

_index

文件儲存的地方

資料庫_type

文件代表的物件的類

資料表_id

文件的唯一標識

表中每一列資料

get /_index/_type/_id

響應：

get /_index/_type/_search

應內容的hits陣列中包含了我們所有的三個文件。預設情況下搜尋會返回前10個結果。

,
"hits": 
},...]}
}

hits：

響應中最重要的部分是hits，它包含了total欄位來表示匹配到的文件總數，hits陣列還包含了匹配到的前10條資料。

hits陣列中的每個結果都包含_index、_type和文件的_id欄位，被加入到_source欄位中這意味著在搜尋結果中我們將可以直接使用全部文件。這不像其他搜尋引擎只返回文件id，需要你單獨去獲取文件。

每個節點都有乙個_score欄位，這是相關性得分(relevance score)，它衡量了文件與查詢的匹配程度。預設的，返回的結果中關聯性最大的文件排在首位；這意味著，它是按照_score降序排列的。這種情況下，我們沒有指定任何查詢，所以所有文件的相關性是一樣的，因此所有結果的_score都是取得乙個中間值1

max_score指的是所有文件匹配查詢中_score的最大值。

took：

took告訴我們整個搜尋請求花費的毫秒數。

shards：timeout：

time_out值告訴我們查詢超時與否。一般的，搜尋請求不會超時。如果響應速度比完整的結果更重要，你可以定義timeout引數為10或者10ms（10毫秒），或者1s（1秒）

get /_search?timeout=10ms

get /_index/_type/_search?q=field:value

我們在請求中依舊使用_search關鍵字，然後將查詢語句傳遞給引數q=。

},}
]}
}

dsl(domain specific language特定領域語言)以json請求體的形式出現。

get /_index/_type/_search
}}

這會返回與之前查詢相同的結果。你可以看到有些東西改變了，我們不再使用查詢字串(query string)做為引數，而是使用請求體代替。這個請求體使用json表示，其中使用了match語句（查詢型別之一）。

我們讓搜尋稍微再變的複雜一些。我們想要找到姓名為「test」，但是我們只想得到年齡大於30歲。我們的語句將新增過濾器(filter),它使得我們高效率的執行乙個結構化搜尋：

get /megacorp/employee/_search
<1>}},
"query" : }}
}}

到目前為止搜尋都很簡單：搜尋特定的名字，通過年齡篩選。讓我們嘗試一種更高階的搜尋，全文搜尋——一種傳統資料庫很難實現的功能。

get /_index/_type/_search
}}

你可以看到我們使用了之前的match查詢，從key欄位中搜尋」value」

},}
]}
}

預設情況下，elasticsearch根據結果相關性評分來對結果集進行排序，所謂的「結果相關性評分」就是文件與查詢條件的匹配程度。

目前我們可以在字段中搜尋單獨的乙個詞，這挺好的，但是有時候你想要確切的匹配若干個單詞或者短語(phrases)。例如我們想要查詢同時包含」value1」和」value2」（並且是相鄰的）的記錄。

要做到這個，我們只要將match查詢變更為match_phrase查詢即可:

get /_index/_type/_search
}}

讓我們在之前的語句上增加highlight引數：

get /_index/_type/_search
},"highlight": }}
}

當我們執行這個語句時，會命中與之前相同的結果，但是在返回結果中會有乙個新的部分叫做highlight，這裡包含了來自field欄位中的文字，並且用來標識匹配到的單詞。

,
"highlight": }]
}}

搜尋介面概述

C 介面介面概述

介面的概述

介面測試概述

搜尋介面概述

C 介面 介面概述

介面的概述

介面測試概述

相關推薦

C 介面介面概述