elasticsearch 使用的查詢語言（dsl）
擁有一套查詢元件，這些元件可以以無限組合的方式進行搭配。這套元件可以在以下兩種情況下使用：過濾情況（filtering context）和查詢情況（query context）。
當使用於 過濾情況
時，查詢被設定成乙個「不評分」或者「過濾」查詢。即，這個查詢只是簡單的問乙個問題：「這篇文件是否匹配？」。回答也是非常的簡單，yes 或者 no ，二者必居其一。
當使用於 查詢情況
時，查詢就變成了乙個「評分」的查詢。和不評分的查詢類似，也要去判斷這個文件是否匹配，同時它還需要判斷這個文件匹配的有 _多好_（匹配程度如何）。 此查詢的典型用法是用於查詢以下文件：
乙個評分查詢計算每乙個文件與此查詢的 _相關程度_，同時將這個相關程度分配給表示相關性的字段 `_score`，並且按照相關性對匹配到的文件進行排序。這種相關性的概念是非常適合全文搜尋的情況，因為全文搜尋幾乎沒有完全 「正確」 的答案。
自 elasticsearch 問世以來，查詢與過濾（queries and filters）就獨自成為 elasticsearch 的元件。但從 elasticsearch 2.0 開始，過濾（filters）已經從技術上被排除了，同時所有的查詢（queries）擁有變成不評分查詢的能力。
然而，為了明確和簡單，我們用 "filter" 這個詞表示不評分、只過濾情況下的查詢。你可以把 "filter" 、 "filtering query" 和 "non-scoring query" 這幾個詞視為相同的。
相似的，如果單獨地不加任何修飾詞地使用 "query" 這個詞，我們指的是 "scoring query" 。
效能差異
過濾查詢（filtering queries）只是簡單的檢查包含或者排除，這就使得計算起來非常快。考慮到至少有乙個過濾查詢（filtering query）的結果是 「稀少的」（很少匹配的文件），並且經常使用不評分查詢（non-scoring queries），結果會被快取到記憶體中以便快速讀取，所以有各種各樣的手段來優化查詢結果。
相反，評分查詢（scoring queries）不僅僅要找出
匹配的文件，還要計算每個匹配文件的相關性，計算相關性使得它們比不評分查詢費力的多。同時，查詢結果並不快取。
多虧倒排索引（inverted index），乙個簡單的評分查詢在匹配少量文件時可能與乙個涵蓋百萬文件的filter表現的一樣好，甚至會更好。但是在一般情況下，乙個filter 會比乙個評分的query效能更優異，並且每次都表現的很穩定。
過濾（filtering）的目標是減少那些需要通過評分查詢（scoring queries）進行檢查的文件。
如何選擇查詢與過濾
通常的規則是，使用
查詢（query）語句來進行
全文相關性得分
的搜尋。除此以外的情況都使用過濾（filters)。
請求體查詢 驗證查詢
查詢可以變得非常的複雜，尤其 和不同的分析器與不同的字段對映結合時，理解起來就有點困難了。不過validate queryapi 可以用來驗證查詢是否合法。gb tweet validate query 以上validate請求的應答告訴我們這個查詢是不合法的 valid false shards ...
請求體查詢 最重要的查詢
雖然 elasticsearch 自帶了很多的查詢，但經常用到的也就那麼幾個。我們將在 深入搜尋 章節詳細討論那些查詢的細節，接下來我們對最重要的幾個查詢進行簡單介紹。match all查詢 match all查詢簡單的 匹配所有文件。在沒有指定查詢方式時，它是預設的查詢 match all 它經常...
ES 學習3 請求體查詢
1.空查詢 get index 2014 type1,type2 search get search 2.查詢表示式 dsl只需將查詢語句傳遞給query引數 get search 查詢全部 match all 跟空查詢等價 get search 針對某個字段，結構 get search 3.查詢與...