菜单 学习猿地 - LMONKEY

VIP

开通学习猿地VIP

尊享10项VIP特权 持续新增

知识通关挑战

打卡带练!告别无效练习

接私单赚外块

VIP优先接,累计金额超百万

学习猿地私房课免费学

大厂实战课仅对VIP开放

你的一对一导师

每月可免费咨询大牛30次

领取更多软件工程师实用特权

入驻
100
0

elasticsearch

原创
05/13 14:22
阅读数 36126

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 个主分片的索引中搜索。 
当我们请求结果的第一页(结果从 110 ),每一个分片产生前 10 的结果,并且返回给 协调节点 ,
协调节点对 50 个结果排序得到全部结果的前 10 个。

现在假设我们请求第 1000 页--结果从 1000110010 。
所有都以相同的方式工作除了每个分片不得不产生前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": []
        }
    }
}

 

发表评论

0/200
100 点赞
0 评论
收藏