elasticsearch

took：執行整個搜尋請求耗費了多少毫秒。

/_search

在所有的索引中搜尋所有的類型

/gb/_search

在 gb 索引中搜尋所有的類型

/gb,us/_search

在 gb 和 us 索引中搜尋所有的文檔

/g*,u*/_search

在任何以 g 或者 u 開頭的索引中搜尋所有的類型

/gb/user/_search

在 gb 索引中搜尋 user 類型

/gb,us/user,tweet/_search

在 gb 和 us 索引中搜尋 user 和 tweet 類型

/_all/user,tweet/_search

在所有的索引中搜尋 user 和 tweet 類型

GET /_search?size=5

GET /_search?size=5&from=5

GET /_search?size=5&from=10

size

顯示應該傳回的結果數量，預設是 10

from

顯示應該跳過的初始結果數量，預設是 0

了解為什麼深度分頁是有問題的，我們可以假設在一個有 5 個主分片的索引中搜尋。 
當我們請求結果的第一頁（結果從 1 到 10 ），每一個分片産生前 10 的結果，并且傳回給 協調節點 ，
協調節點對 50 個結果排序得到全部結果的前 10 個。

現在假設我們請求第 1000 頁--結果從 10001 到 10010 。
所有都以相同的方式工作除了每個分片不得不産生前10010個結果以外。 
然後協調節點對全部 50050 個結果排序最後丢棄掉這些結果中的 50040 個結果。

可以看到，在分布式系統中，對結果排序的成本随分頁的深度成指數上升。
這就是 web 搜尋引擎對任何查詢都不要傳回超過 1000 個結果的原因。      

term是代表完全比對，不進行分詞器分析，文檔中必須包含整個搜尋的詞彙

{
    "query": {
        "term": {
            "area_code.keyword": "ALY"
        }
    }
}      

bool聯合查詢：must、must_not

must: 文檔必須完全比對條件

must_not: 文檔必須不比對條件

{
    "query": {
        "bool": {
            "must": {
                "term": {
                    "area_code.keyword": "ALY"
                }
            },
            "must_not": [],
            "should": []
        }
    }
}