Elasticsearch不首先返回完全匹配

我有一個彈性搜索索引與一個字段的精確匹配，並以某種方式我得到了很多類似的結果（我不介意）和那些類似的結果完全匹配，（我不介意）Elasticsearch不首先返回完全匹配

有人可以解釋發生了什麼以及如何解決它嗎？

我的映射是這樣的

"exact":{ 
    "type":"string", 
    "boost":10.0, 
    "analyzer":"keyword" 
},

我的查詢，以搜索爲「AAPL P 2014年1月885,00」是這樣的：

{ 
    "size" : 21, 
    "query" : { 
    "field" : { 
     "exact" : "AAPL P JAN 2014 885,00" 
    } 
    }, 
    "explain" : true, 
    "sort" : [ { 
    "_score" : { 
     "order" : "desc" 
    } 
    } ], 
    "facets" : { 
    "category" : { 
     "terms" : { 
     "field" : "category", 
     "size" : 10 
     } 
    } 
    } 
}

而返回的文檔順序結束：

{ 「精確」：[ 「APPLE INC」，「US0378331005」，「AAPL」，「73773」]，「ID-化合物」：「AAPL」}
{「exact」：[「AAPL」，「73773」，「AAPL P JAN 2014 675,00」]，「id-compound」：「AAPL * PUT * 20140118 * 675」}
{「exact」：[ 「AAPL」，「73773」，「AAPLç2014年1月500,00」]，「ID-化合物」：「AAPL * CALL * 20140118 * 500」}

等，與完全匹配一個一線結果。

有人可以向我解釋爲什麼精確匹配不會結束？

如果搜索結果有助於理解事情，那麼以下全面說明的搜索結果如下。

"hits" : [ { 
    "_shard" : 0, 
    "_node" : "1", 
    "_index" : "instruments", 
    "_type" : "instrument", 
    "_id" : "AAPL", 
    "_score" : 1306.8339, "_source" : {"exact":["APPLE INC","US0378331005","AAPL","73773"],"id-compound":"AAPL"}, 
    "_explanation" : { 
    "value" : 1306.8339, 
    "description" : "product of:", 
    "details" : [ { 
     "value" : 6534.169, 
     "description" : "sum of:", 
     "details" : [ { 
     "value" : 6534.169, 
     "description" : "weight(exact:AAPL in 9096), product of:", 
     "details" : [ { 
      "value" : 0.25854474, 
      "description" : "queryWeight(exact:AAPL), product of:", 
      "details" : [ { 
      "value" : 6.1701355, 
      "description" : "idf(docFreq=211, maxDocs=37299)" 
      }, { 
      "value" : 0.0419026, 
      "description" : "queryNorm" 
      } ] 
     }, { 
      "value" : 25272.875, 
      "description" : "fieldWeight(exact:AAPL in 9096), product of:", 
      "details" : [ { 
      "value" : 1.0, 
      "description" : "tf(termFreq(exact:AAPL)=1)" 
      }, { 
      "value" : 6.1701355, 
      "description" : "idf(docFreq=211, maxDocs=37299)" 
      }, { 
      "value" : 4096.0, 
      "description" : "fieldNorm(field=exact, doc=9096)" 
      } ] 
     } ] 
     } ] 
    }, { 
     "value" : 0.2, 
     "description" : "coord(1/5)" 
    } ] 
    } 
}, { 
    "_shard" : 0, 
    "_node" : "1", 
    "_index" : "instruments", 
    "_type" : "instrument", 
    "_id" : "AAPL*PUT*20140118*675", 
    "_score" : 163.35423, "_source" : {"exact":["AAPL","73773","AAPL P JAN 2014 675,00"],"id-compound":"AAPL*PUT*20140118*675"}, 
    "_explanation" : { 
    "value" : 163.35423, 
    "description" : "product of:", 
    "details" : [ { 
     "value" : 816.7711, 
     "description" : "sum of:", 
     "details" : [ { 
     "value" : 816.7711, 
     "description" : "weight(exact:AAPL in 18), product of:", 
     "details" : [ { 
      "value" : 0.25854474, 
      "description" : "queryWeight(exact:AAPL), product of:", 
      "details" : [ { 
      "value" : 6.1701355, 
      "description" : "idf(docFreq=211, maxDocs=37299)" 
      }, { 
      "value" : 0.0419026, 
      "description" : "queryNorm" 
      } ] 
     }, { 
      "value" : 3159.1094, 
      "description" : "fieldWeight(exact:AAPL in 18), product of:", 
      "details" : [ { 
      "value" : 1.0, 
      "description" : "tf(termFreq(exact:AAPL)=1)" 
      }, { 
      "value" : 6.1701355, 
      "description" : "idf(docFreq=211, maxDocs=37299)" 
      }, { 
      "value" : 512.0, 
      "description" : "fieldNorm(field=exact, doc=18)" 
      } ] 
     } ] 
     } ] 
    }, { 
     "value" : 0.2, 
     "description" : "coord(1/5)" 
    } ] 
    } 
}, { 
    "_shard" : 0, 
    "_node" : "1", 
    "_index" : "instruments", 
    "_type" : "instrument", 
    "_id" : "AAPL*CALL*20140118*500", 
    "_score" : 163.35423, "_source" : {"exact":["AAPL","73773","AAPL C JAN 2014 500,00"],"id-compound":"AAPL*CALL*20140118*500"}, 
    "_explanation" : { 
    "value" : 163.35423, 
    "description" : "product of:", 
    "details" : [ { 
     "value" : 816.7711, 
     "description" : "sum of:", 
     "details" : [ { 
     "value" : 816.7711, 
     "description" : "weight(exact:AAPL in 383), product of:", 
     "details" : [ { 
      "value" : 0.25854474, 
      "description" : "queryWeight(exact:AAPL), product of:", 
      "details" : [ { 
      "value" : 6.1701355, 
      "description" : "idf(docFreq=211, maxDocs=37299)" 
      }, { 
      "value" : 0.0419026, 
      "description" : "queryNorm" 
      } ] 
     }, { 
      "value" : 3159.1094, 
      "description" : "fieldWeight(exact:AAPL in 383), product of:", 
      "details" : [ { 
      "value" : 1.0, 
      "description" : "tf(termFreq(exact:AAPL)=1)" 
      }, { 
      "value" : 6.1701355, 
      "description" : "idf(docFreq=211, maxDocs=37299)" 
      }, { 
      "value" : 512.0, 
      "description" : "fieldNorm(field=exact, doc=383)" 
      } ] 
     } ] 
     } ] 
    }, { 
     "value" : 0.2, 
     "description" : "coord(1/5)" 
    } ] 
    } 
}, { 
    "_id" : "AAPL*PUT*20140118*940", 
    "_score" : 163.35423, "_source" : {"exact":["AAPL","73773","AAPL P JAN 2014 940,00"],"id-compound":"AAPL*PUT*20140118*940"}, 
    "_explanation" : { 
    "value" : 163.35423, 
    "description" : "product of:", 
    "details" : [ { 
     "value" : 816.7711, 
     "description" : "sum of:", 
     "details" : [ { 
     "value" : 816.7711, 
     "description" : "weight(exact:AAPL in 794), product of:", 
     "details" : [ { 
      "value" : 0.25854474, 
      "description" : "queryWeight(exact:AAPL), product of:", 
      "details" : [ { 
      "value" : 6.1701355, 
      "description" : "idf(docFreq=211, maxDocs=37299)" 
      }, { 
      "value" : 0.0419026, 
      "description" : "queryNorm" 
      } ] 
     }, { 
      "value" : 3159.1094, 
      "description" : "fieldWeight(exact:AAPL in 794), product of:", 
      "details" : [ { 
      "value" : 1.0, 
      "description" : "tf(termFreq(exact:AAPL)=1)" 
      }, { 
      "value" : 6.1701355, 
      "description" : "idf(docFreq=211, maxDocs=37299)" 
      }, { 
      "value" : 512.0, 
      "description" : "fieldNorm(field=exact, doc=794)" 
      } ] 
     } ] 
     } ] 
    }, { 
     "value" : 0.2, 
     "description" : "coord(1/5)" 
    } ] 
    } 
}

，只是在情況下的，如果我分析我試圖存儲中的數據會發生什麼：

curl -XGET 'localhost:9200/instruments/_analyze?field=exact&pretty=true' -d 'ING P JUN 2013 6.00' 
{ 
    "tokens" : [ { 
    "token" : "ING P JUN 2013 6.00", 
    "start_offset" : 0, 
    "end_offset" : 20, 
    "type" : "word", 
    "position" : 1 
    } ]

來源

2013-05-16 Constantijn Visinescu

所有三個文件得到完全相同的分數，你可以從解釋輸出看到他們都匹配「AAPL」。該術語在文檔中總是出現一次（tf = 1），並且出現在37299個文檔中的211個（idf = 6.1701355）。因爲你正在使用索引時間提升（你的映射中的提升部分，10），所以現場常規要高得多，無論如何，沒有什麼大不了的，因爲匹配總是在同一個域上。只是，如果你在其他領域有一場比賽，那麼幾乎總會贏，這對你的情況可能是有意義的。

但問題是，AAPL P JAN 2014 885,00是不完全匹配，如果我看你的文件。我所看到的是，在查詢中的5個術語中只有一個匹配，這也由您的解釋輸出中的座標確認：coord（1/5）`。

keyword分析器似乎被應用，但是從返回的文檔中可以看出，您並不是將exact字段的內容作爲單個值發送，而是作爲一組值。由於您使用的是keyword分析儀，但其中每個項目都不會被標記，但仍有多個標記。我想你必須檢查你如何索引文件。

來源

2013-05-16 17:32:47 javanna

有一個在有精確匹配，它只是WAAAAAAAY下來。 –

這是一個完全匹配你，而不是elasticsearch/lucene如果你看看分數。 – javanna

什麼我不明白它：爲什麼它甚至匹配...我使用關鍵字分析器，它應該分析整個字符串作爲關鍵字...所以我正在闡述的是，當它搜索它轉向整個事情變成一個令牌，它試圖匹配。但顯然這不是發生了什麼事情。任何想法如何我可以得到我想要的行爲？我只想要一場比賽，如果一切都匹配，直到空間。（最好不區分大小寫） –

我認爲你已經找到了你的答案，只是想給其他同樣的問題多一點信息。

您使用field查詢從elasticsearch文檔：

字段查詢：

執行鍼對特定領域的查詢字符串的查詢。它是query_string查詢的簡化版本（通過將default_field設置爲此查詢執行的字段）。

我相信query_string查詢文本，即：它做了很多的查詢，使之模糊，等...

要使用（我想你發現了這一點什麼）是一個term查詢，它不會對搜索短語做任何事情，所以只給你完全匹配。

注意：分析發生在2個不同的時間，索引時間和查詢時間。設置"analyzer": "keyword"似乎隻影響搜索時間查詢「使用查詢字符串進行搜索時」form elasticsearch docs。我必須承認，我不知道究竟是什麼意思（我猜query_string，但它也可能意味着像http://../_search?q=exact:{query here}搜索）

來源

2013-06-05 10:29:49 ramseykhalaf

我不知道它是否技術上是最好的事情，但如果你只是在一個來自彈性搜索的單一特定答案，您可以使用一個過濾器和一個查找完全匹配的腳本。

{ 
    from : 0, 
    size : 1, 
    "query" : { 
    "text_phrase" : { 
     "title" : "AAPL P JAN 2014 885,00" 
    } 
    }, 
    "filter" : { 
    "script" : { 
     "script" : "_source.exact.contains(x)", 
     "params" : { 
     "x" : "AAPL P JAN 2014 885,00" 
     } 
    } 
    } 
}

我用這個來獲得彈性搜索一個已知的入口，它的工作很適合我。

來源

2013-07-23 16:29:34

您的關鍵字分析器在搜索查詢中似乎被忽略的原因是ES ES將這個字符串標記了兩次 - 首先運行它的DSL標記器，然後運行rezult上的映射中指定的標記器。這在本文中有更詳細的解釋http://paulsabou.com/blog/2012/03/25/advanced-exact-matching-with-elastic-search/

來源

2013-10-29 12:01:36 user501869

你不應該分析你的id字段。

定義你的領域爲：

"exact":{ 
    "type":"string", 
    "index":"not_analyzed" 
}

看一看Finding Exact Values

來源

2015-10-12 09:32:10 jogaco

Elasticsearch不首先返回完全匹配

回答

相關問題