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": []
        }
    }
}