term查詢
term查詢數字
我們首先來看最為常用的term查詢，可以用它處理數字(numbers)，布爾值（Booleans），日志（dates）以及文本（text）
讓我們以下面的例子開始介紹，創建並索引一些表示產品的文檔，文檔里有字段 price 和 productID （ 價格 和 產品ID ）：
curl -X POST "localhost:9200/my_store/products/_bulk" -H 'Content-Type: application/json' -d'
{ "index": { "_id": 1 }}
{ "price" : 10, "productID" : "XHDK-A-1293-#fJ3" }
{ "index": { "_id": 2 }}
{ "price" : 20, "productID" : "KDKE-B-9947-#kL5" }
{ "index": { "_id": 3 }}
{ "price" : 30, "productID" : "JODL-X-1937-#pV7" }
{ "index": { "_id": 4 }}
{ "price" : 30, "productID" : "QQPX-R-3956-#aD8" }
'
1
2
3
4
5
6
7
8
9
10
我們想要做的是查找具有某個價格的所有產品，有關系數據庫背景的人肯定熟悉 SQL，如果我們將其用 SQL 形式表達，會是下面這樣：
SELECT document FROM products WHERE price = 20
1
在 Elasticsearch 的查詢表達式（query DSL）中，我們可以使用 term 查詢達到相同的目的。 term 查詢會查找我們指定的精確值。作為其本身， term 查詢是簡單的。它接受一個字段名以及我們希望查找的數值：
{
"query":{
"term" : {
"price" : 20
}
}
}
1
2
3
4
5
6
7
通常當查找一個精確值的時候，我們不希望對查詢進行評分計算。只希望對文檔進行包括或排除的計算，所以我們會使用 constant_score 查詢以非評分模式來執行 term 查詢並以一作為統一評分。
最終組合的結果是一個 constant_score 查詢，它包含一個 term 查詢：
GET /my_store/products/_search
{
"query":{
"constant_score":{ //我們用constant_score將term查詢轉化為過濾器
"filter":{
"term" : { //我們之前看到過的term查詢
"price" : 20
}
}
}
}
}
1
2
3
4
5
6
7
8
9
10
11
12
執行后，這個查詢所搜索到的結果與我們期望的一致：只有文檔 2 命中並作為結果返回（因為只有 2 的價格是 20 ）:
{
"took": 5,
"timed_out": false,
"_shards": {
"total": 5,
"successful": 5,
"skipped": 0,
"failed": 0
},
"hits": {
"total": 1,
"max_score": 1,
"hits": [
{
"_index": "my_store",
"_type": "products",
"_id": "2",
"_score": 1, //查詢置於 filter 語句內不進行評分或相關度的計算，所以所有的結果都會返回一個默認評分 1
"_source": {
"price": 20,
"productID": "KDKE-B-9947-#kL5"
}
}
]
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
term查詢文本
如本部分開始處提到過的一樣 ，使用 term 查詢匹配字符串和匹配數字一樣容易。如果我們想要查詢某個具體 UPC ID 的產品，使用 SQL 表達式會是如下這樣：
SELECT product FROM products WHERE productID = "XHDK-A-1293-#fJ3"
1
轉換成查詢表達式（query DSL），同樣使用 term 查詢，形式如下：
GET /my_store/products/_search
{
"query" : {
"constant_score" : {
"filter" : {
"term" : {
"productID" : "XHDK-A-1293-#fJ3"
}
}
}
}
}
1
2
3
4
5
6
7
8
9
10
11
12
但這里有個小問題：我們無法獲得期望的結果。為什么呢？問題不在 term 查詢，而在於索引數據的方式。
如果我們使用 analyze API (分析 API)，我們可以看到這里的 UPC 碼被拆分成多個更小的 token ：
GET /my_store/_analyze
{
"field": "productID",
"text": "XHDK-A-1293-#fJ3"
}
1
2
3
4
5
返回結果
{
"tokens" : [ {
"token" : "xhdk",
"start_offset" : 0,
"end_offset" : 4,
"type" : "<ALPHANUM>",
"position" : 1
}, {
"token" : "a",
"start_offset" : 5,
"end_offset" : 6,
"type" : "<ALPHANUM>",
"position" : 2
}, {
"token" : "1293",
"start_offset" : 7,
"end_offset" : 11,
"type" : "<NUM>",
"position" : 3
}, {
"token" : "fj3",
"start_offset" : 13,
"end_offset" : 16,
"type" : "<ALPHANUM>",
"position" : 4
} ]
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
這里有幾點需要注意：
Elasticsearch 用 4 個不同的 token 而不是單個 token 來表示這個 UPC 。
所有字母都是小寫的。
丟失了連字符和哈希符（ # ）。
所以當我們用 term 查詢查找精確值 XHDK-A-1293-#fJ3 的時候，找不到任何文檔，因為它並不在我們的倒排索引中，正如前面呈現出的分析結果，索引里有四個 token 。
顯然這種對 ID 碼或其他任何精確值的處理方式並不是我們想要的。
為了避免這種問題，我們需要告訴 Elasticsearch 該字段具有精確值，要將其設置成 not_analyzed 無需分析的。 我們可以在 自定義字段映射 中查看它的用法。為了修正搜索結果，我們需要首先刪除舊索引（因為它的映射不再正確）然后創建一個能正確映射的新索引：
刪除索引： DELETE /my_store //刪除索引是必須的，因為我們不能更新已存在的映射。
重新新建索引，自定義映射字段
PUT /my_store
{
"mappings":{
"products":{
"properties":{
"productID":{
"type":"string",
"index":"not_analyzed" //這里我們告訴 Elasticsearch ，我們不想對 productID 做任何分析
}
}
}
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
現在我們可以為文檔重建索引：
curl -X POST "localhost:9200/my_store/products/_bulk" -H 'Content-Type: application/json' -d'
{ "index": { "_id": 1 }}
{ "price" : 10, "productID" : "XHDK-A-1293-#fJ3" }
{ "index": { "_id": 2 }}
{ "price" : 20, "productID" : "KDKE-B-9947-#kL5" }
{ "index": { "_id": 3 }}
{ "price" : 30, "productID" : "JODL-X-1937-#pV7" }
{ "index": { "_id": 4 }}
{ "price" : 30, "productID" : "QQPX-R-3956-#aD8" }
'
1
2
3
4
5
6
7
8
9
10
此時， term 查詢就能搜索到我們想要的結果，讓我們再次搜索新索引過的數據（注意，查詢和過濾並沒有發生任何改變，改變的是數據映射的方式）：
GET /my_store/products/_search
{
"query" : {
"constant_score" : {
"filter" : {
"term" : {
"productID" : "XHDK-A-1293-#fJ3"
}
}
}
}
}
1
2
3
4
5
6
7
8
9
10
11
12
因為 productID 字段是未分析過的， term 查詢不會對其做任何分析，查詢會進行精確查找並返回文檔 1 。成功！
內部過濾器的操作
在內部，Elasticsearch 會在運行非評分查詢的時執行多個操作：
查找匹配文檔
term查詢在倒排索引中查找XHDK-A-1293-#fJ3 然后獲取包含改term的所有文檔。本例中只有文檔1滿足我們的需求。
創建bitset.
過濾器會創建一個bitset（一個包含0和1的數組），它描述了哪個文檔會包含該term。匹配文檔的標志位是1的數據，本例中，bitset的值為[1,0,0,0]。在內部，它表示成一個“roaring bitmap”，可以同時對稀疏或密集的集合進行高效編碼。
迭代 bitset(s)
一旦為每個查詢生成了bitsets，elasticsearch就會循環迭代bitsets，從而找滿足所有過濾條件的匹配文檔的集合。執行順序是啟發式的，但一般來說先迭代稀疏的bitset（因為它可以排除掉大量的文檔）。
增量使用計數
Elasticsearch 能夠緩存非評分查詢從而獲得更快的訪問，但是它也會不太聰明的緩存一些使用極少的東西。非評分計算因為倒排索引已經足夠快了，所以我們只想緩存那些我們知道在將來會被再次使用的查詢，以避免資源的浪費。
為了實現以上設想，Elasticsearch 會為每個索引跟蹤保留查詢使用的歷史狀態。如果查詢在最近的 256 次查詢中會被用到，那么它就會被緩存到內存中。當 bitset 被緩存后，緩存會在那些低於 10,000 個文檔（或少於 3% 的總索引數）的段（segment）中被忽略。這些小的段即將會消失，所以為它們分配緩存是一種浪費。
實際情況並非如此（執行有它的復雜性，這取決於查詢計划是如何重新規划的，有些啟發式的算法是基於查詢代價的），理論上非評分查詢 先於 評分查詢執行。非評分查詢任務旨在降低那些將對評分查詢計算帶來更高成本的文檔數量，從而達到快速搜索的目的。
從概念上記住非評分計算是首先執行的，這將有助於寫出高效又快速的搜索請求。
---------------------