<ruby id="bdb3f"></ruby>

    <p id="bdb3f"><cite id="bdb3f"></cite></p>

      <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
        <p id="bdb3f"><cite id="bdb3f"></cite></p>

          <pre id="bdb3f"></pre>
          <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

          <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
          <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

          <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                <ruby id="bdb3f"></ruby>

                ThinkChat2.0新版上線,更智能更精彩,支持會話、畫圖、視頻、閱讀、搜索等,送10W Token,即刻開啟你的AI之旅 廣告
                # Recipes(訣竅) 原文鏈接 :?[https://www.elastic.co/guide/en/elasticsearch/reference/5.3/recipes.html](https://www.elastic.co/guide/en/elasticsearch/reference/5.3/recipes.html) 譯文鏈接 :?[http://www.apache.wiki/pages/viewpage.action?pageId=10027113](http://www.apache.wiki/pages/viewpage.action?pageId=10027113) 貢獻者 : [李堅](/display/~lijian),[ApacheCN](/display/~apachecn),[Apache中文網](/display/~apachechina) ### Mixing exact search with stemming(用?stemming(詞干)進行精確搜索) 在構建搜索應用程序時,stemming (詞干)經常是必須有的,因為它描述了針對 skiing 上的查詢,以匹配包含 ski 或 skis 的文檔。但是用戶如果想要指定 skiing 來搜索呢?執行此操作的典型方式是使用 multi-field,以便以兩種不同的方式對相同的內容進行索引。 ``` PUT index { "settings": { "analysis": { "analyzer": { "english_exact": { "tokenizer": "standard", "filter": [ "lowercase" ] } } } }, "mappings": { "type": { "properties": { "body": { "type": "text", "analyzer": "english", "fields": { "exact": { "type": "text", "analyzer": "english_exact" } } } } } } } PUT index/type/1 { "body": "Ski resort" } PUT index/type/2 { "body": "A pair of skis" } POST index/_refresh ``` 按照這樣的設置,在 body 中搜索 ski 這兩個 documents(文檔) 都將會被返回: ``` GET index/_search { "query": { "simple_query_string": { "fields": [ "body" ], "query": "ski" } } } ``` ``` { "took": 2, "timed_out": false, "_shards": { "total": 5, "successful": 5, "failed": 0 }, "hits": { "total": 2, "max_score": 0.25811607, "hits": [ { "_index": "index", "_type": "type", "_id": "2", "_score": 0.25811607, "_source": { "body": "A pair of skis" } }, { "_index": "index", "_type": "type", "_id": "1", "_score": 0.25811607, "_source": { "body": "Ski resort" } } ] } } ``` 另一方面,搜索 body.exact 上的 ski 只會返回文檔 1,因為 body.exact 的分析鏈不執行 stemming。 ``` GET index/_search { "query": { "simple_query_string": { "fields": [ "body.exact" ], "query": "ski" } } } ``` ``` { "took": 1, "timed_out": false, "_shards": { "total": 5, "successful": 5, "failed": 0 }, "hits": { "total": 1, "max_score": 0.25811607, "hits": [ { "_index": "index", "_type": "type", "_id": "1", "_score": 0.25811607, "_source": { "body": "Ski resort" } } ] } } ``` 這還不是最終暴露給用戶的東西,因為我們需要有一個方法來確定是否完全匹配他們正在尋找的東西,并重定向到相應的字段。如果只有部分查詢需要匹配,而其他部分仍然應該考慮在內,該怎么辦? 幸運的是,query_string 和 simple_query_string 查詢具有解決這個問題的功能:quote_field_suffix。 這告訴 Elasticsearch,引號之間出現的單詞將被重定向到一個不同的字段,如下所示: ``` GET index/_search { "query": { "simple_query_string": { "fields": [ "body" ], "quote_field_suffix": ".exact", "query": "\"ski\"" } } } ``` ``` { "took": 2, "timed_out": false, "_shards": { "total": 5, "successful": 5, "failed": 0 }, "hits": { "total": 1, "max_score": 0.25811607, "hits": [ { "_index": "index", "_type": "type", "_id": "1", "_score": 0.25811607, "_source": { "body": "Ski resort" } } ] } } ``` 在上述情況下,由于 ski 是在引號之間,所以在 body.exact 字段上搜索,由于 quote_field_suffix 參數存在,所以只有文檔1匹配。這樣,用戶可以根據需要將精確搜索與搜索結合在一起。 ### Getting consistent scoring(獲得一致的得分) 實際上,Elasticsearch 運行 shards(分片) 和 replicas(副本)的時候會增加壓力,同時也會獲得一個比較好的得分。 #### Scores are not reproducible(得分不可重現) 同一個用戶連續兩次運行相同的請求,documents(文檔) 不會在同一個 order 中返回【將會返回兩次】,這是一個非常糟糕的體驗,不是嗎?不幸的是,如果您開啟了副本(index.number_of_replicas 大于 0),這些可能會發生。原因是 Elasticsearch 以循環方式選擇查詢應該進行的 shards(分片),因此如果您連續運行相同的查詢兩次,那么它將轉到相同 shards(分片)的不同 replicas(副本)去查詢。 為什么會出現這種情況? index(索引)統計信息是得分的一個重要組成部分。由于已刪除的文檔,這些index(索引)統計數據可能因同一分片的副本而異。documents(文檔)被刪除或更新時,舊的 documents(文檔)不會立即從索引中刪除,它只是被標記為已刪除,并且只有在下一次合并該舊 documents(文檔)所屬段時才會從磁盤中刪除 。但是由于實際的原因,這些已刪除的 documents(文檔)被考慮在 index(索引)統計上。所以假設主 shards(分片)剛剛完成了一個大的合并,刪除了大量被標記為已刪除的 documents(文檔),那么它可能具有與 replicas(副本)(仍然有大量已刪除的文檔)有很大不同的 index(索引)統計信息,因此分數也不同。 ?解決此問題推薦的方法是使用標識被記錄的用戶(例如,用戶 ID 或會話 ID)作為首選項的字符串。這樣可以確保給定用戶的所有查詢都將始終打到相同的 shards(分片),因此分數在查詢之間保持更加一致。 這樣做有另一個好處:當兩個 documents(文檔)具有相同的分數時,它們將按照 Lucene 內部 doc id(與_id或_uid無關)排序。但是,這些 documents(文檔)在同一個 shards(分片)的 replicas(副本)上可能不同。 所以總是碰到同樣的 shards(分片),我們會得到更一致的順序的 documents(文檔)并具有相同的分數。 #### Relevancy looks wrong(相關性錯誤) 如果您注意到具有相同內容的兩個 documents(文檔)獲得不同的分數,或者完全匹配不排在第一位,則該問題可能與 shards(分片)有關。默認情況下,Elasticsearch 使每個 shards(分片)都生成自己的分數。然而,由于 index(索引)統計數據是分數的重要貢獻者,所以如果 shards(分片)具有相似的 index(索引)統計信息,這只能使它運行的更好。假設默認情況下 documents(文檔)均勻分配到 shards(分片),所以 index(索引)統計數據應該非常相似,評分將按預期方式工作。但是,如果您在索引時使用 routing(路由), - 查詢多個 index(索引),或者索引中的數據太少,在搜索請求中所涉及的所有碎片都沒有類似的索引統計信息,相關性可能很差。 如果您有一個小數據集,解決此問題的最簡單的方法是將所有內容索引到具有單個 shards(分片)(index.number_of_shards:1)的 index(索引)中。 那么所有文件的 index(索引)統計將是一樣的,分數將是一致的。 否則,解決這個問題的推薦方式來是使用 dfs_query_then_fetch 搜索類型。這將使 Elasticsearch 對所有相關的 shards(分片)進行初始化往返,詢問它們相對于查詢的 index(索引)統計信息,然后協調節點將合并這些統計信息,并在請求 shards(分片)執行查詢階段時發送合并的統計信息, 因此 shards(分片)可以使用這些全局統計數據而不是自己的統計數據來進行評分。 在大多數情況下,這次額外的往返操作資源消耗不大。但是,如果您的查詢包含大量的 fileds / terms 或 ?fuzzy queries(模糊查詢),注意,只統計數據的話可能資源消耗會比較高,因為所有 term 都必須在 terms dictionaries 中才能查找統計信息。
                  <ruby id="bdb3f"></ruby>

                  <p id="bdb3f"><cite id="bdb3f"></cite></p>

                    <p id="bdb3f"><cite id="bdb3f"><th id="bdb3f"></th></cite></p><p id="bdb3f"></p>
                      <p id="bdb3f"><cite id="bdb3f"></cite></p>

                        <pre id="bdb3f"></pre>
                        <pre id="bdb3f"><del id="bdb3f"><thead id="bdb3f"></thead></del></pre>

                        <ruby id="bdb3f"><mark id="bdb3f"></mark></ruby><ruby id="bdb3f"></ruby>
                        <pre id="bdb3f"><pre id="bdb3f"><mark id="bdb3f"></mark></pre></pre><output id="bdb3f"></output><p id="bdb3f"></p><p id="bdb3f"></p>

                        <pre id="bdb3f"><del id="bdb3f"><progress id="bdb3f"></progress></del></pre>

                              <ruby id="bdb3f"></ruby>

                              哎呀哎呀视频在线观看