<!--秀川譯--> ### 關聯失效 在我們去討論多字段檢索中的更復雜的查詢前，讓我們順便先解釋一下為什么我們只用一個主分片來創建索引。 有時有的新手會開一個問題說通過相關性排序沒有效果，并且提供了一小段復制的結果：該用戶創建了一些文檔，執行了一個簡單的查詢，結果發現相關性較低的結果排在了相關性較高的結果的前面。 為了理解為什么會出現這樣的結果，我們假設用兩個分片創建一個索引，以及索引10個文檔，6個文檔包含詞 `foo`，這樣可能會出現分片1中有3個文檔包含 `foo`，分片2中也有三個文檔包含 `foo`。換句話說，我們的文檔做了比較好的分布式。 在相關性介紹這一節，我們描述了Elasticsearch默認的相似算法，叫做詞頻率/反轉文檔頻率（TF/IDF）。詞頻率是一個詞在我們當前查詢的文檔的字段中出現的次數。出現的次數越多，相關性就越大。反轉文檔頻率指的是該索引中所有文檔數與出現這個詞的文件數的百分比，詞出現的頻率越大，IDF越小。 然而，由于性能問題，Elasticsearch不通過索引中所有的文檔計算IDF。每個分片會為分片中所有的文檔計算一個本地的IDF取而代之。 因為我們的文檔做了很好的分布式，每個分片的IDF是相同的。現在假設5個包含`foo`的文檔在分片1中，以及其他6各文檔在分片2中。在這個場景下，詞`foo`在第一個分片中是非常普通的（因此重要性較小），但是在另一個分片中是很稀少的（因此重要性較高）。這些區別在IDF中就會產生不正確的結果。 事實證明，這并不是一個問題。你索引越多的文檔，本地IDF和全局IDF的區別就會越少。在實際工作的數據量下，本地IDF立刻能夠很好的工作（With real-world volumes of data, the local IDFs soon even out，不知道這么翻譯合不合適）。所以問題不是因為關聯失效，而是因為數據太少。 為了測試的目的，對于這個問題，有兩種方法可以奏效。第一種方法是創建一個只有一個主分片的索引，像我們介紹`match`查詢那節一樣做。如果你只有一個分片，那么本地IDF就是全局IDF。 第二種方法是在你們請求中添加`?search_type=dfs_query_then_fetch`。`dfs`就是*Distributed Frequency Search*，并且它會告訴Elasticsearch檢查每一個分片的本地IDF為了計算整個索引的全局IDF。 > 提示：不要把`dfs_query_then_fetch`用于生產環境。它實在是沒有必要。只要有足夠的數據就能夠確保詞頻率很好的分布。沒有理由在每個你要執行的查詢中添加額外的DFS步驟。 <!-- [[relevance-is-broken]] === Relevance Is Broken! Before we move on to discussing more-complex queries in <<multi-field-search>>, let's make a quick detour to explain why we <<match-test-data,created our test index>> with just one primary shard. Every now and again a new user opens an issue claiming that sorting by relevance((("relevance", "differences in IDF producing incorrect results"))) is broken and offering a short reproduction: the user indexes a few documents, runs a simple query, and finds apparently less-relevant results appearing above more-relevant results. To understand why this happens, let's imagine that we create an index with two primary shards and we index ten documents, six of which contain the word `foo`. It may happen that shard 1 contains three of the `foo` documents and shard 2 contains the other three. In other words, our documents are well distributed. In <<relevance-intro>>, we described the default similarity algorithm used in Elasticsearch, ((("Term Frequency/Inverse Document Frequency (TF/IDF) similarity algorithm")))called _term frequency / inverse document frequency_ or TF/IDF. Term frequency counts the number of times a term appears within the field we are querying in the current document. The more times it appears, the more relevant is this document. The _inverse document frequency_ takes((("inverse document frequency")))((("IDF", see="inverse document frequency"))) into account how often a term appears as a percentage of _all the documents in the index_. The more frequently the term appears, the less weight it has. However, for performance reasons, Elasticsearch doesn't calculate the IDF across all documents in the index.((("shards", "local inverse document frequency (IDF)"))) Instead, each shard calculates a local IDF for the documents contained _in that shard_. Because our documents are well distributed, the IDF for both shards will be the same. Now imagine instead that five of the `foo` documents are on shard 1, and the sixth document is on shard 2. In this scenario, the term `foo` is very common on one shard (and so of little importance), but rare on the other shard (and so much more important). These differences in IDF can produce incorrect results. In practice, this is not a problem. The differences between local and global IDF diminish the more documents that you add to the index. With real-world volumes of data, the local IDFs soon even out. The problem is not that relevance is broken but that there is too little data. For testing purposes, there are two ways we can work around this issue. The first is to create an index with one primary shard, as we did in the section introducing the <<match-query,`match` query>>. If you have only one shard, then the local IDF _is_ the global IDF. The second workaround is to add `?search_type=dfs_query_then_fetch` to your search requests. The `dfs` stands((("search_type", "dfs_query_then_fetch")))((("dfs_query_then_fetch search type")))((("DFS (Distributed Frequency Search)"))) for _Distributed Frequency Search_, and it tells Elasticsearch to first retrieve the local IDF from each shard in order to calculate the global IDF across the whole index. TIP: Don't use `dfs_query_then_fetch` in production. It really isn't required. Just having enough data will ensure that your term frequencies are well distributed. There is no reason to add this extra DFS step to every query that you run. -->