Elastic Search中Query String常见语法

1 搜索所有数据
timeout参数:是超时时长定义。代表每个节点上的每个shard执行搜索时最多耗时多久。不会影响响应的正常返回。只会影响返回响应中的数据数量。
如:索引a中,有10亿数据。存储在5个shard中,假设每个shard中2亿数据,执行全数据搜索的时候,需要耗时1000毫秒。定义timeout为10毫秒,代表的是shard执行10毫秒,搜索出多少数据,直接返回。
语法:

GET _search?timeout=10ms

结果:

{
  "took": 144, #请求耗时多少毫秒
  "timed_out": false, #是否超时。默认情况下没有超时机制,也就是客户端等待ES搜索结束(无论执行多久),提供超时机制的话,ES则在指定时长内处理搜索,在指定时长结束的时候,将搜索的结果直接返回(无论是否搜索结束)。指定超时的方式是传递参数,参数单位是:毫秒-ms。秒-s。分钟-m。
  "_shards": {
    "total": 1, #请求发送到多少个shard上
    "successful": 1,#成功返回搜索结果的shard
    "skipped": 0, #停止服务的shard
    "failed": 0 #失败的shard
  },
  "hits": {
    "total": 1, #返回了多少结果
    "max_score": 1, #搜索结果中,最大的相关度分数,相关度越大分数越高,_score越大,排位越靠前。
    "hits": [ #搜索到的结果集合,默认查询前10条数据。
      {
        "_index": "test_index", #数据所在索引
        "_type": "my_type", #数据所在类型
        "_id": "1", #数据的id
        "_score": 1, #数据的搜索相关度分数
        "_source": { # 数据的具体内容。
          "field": "value"
        }
      }
    ]
  }
}


2 _all应用1
_all也是ES中的一个内置元数据。也可以成为内置变量名。代表全部的意思。一般来说_all使用的很少。
语法:

GET /_all/_search

这种_all的用法相当于在所有的索引中搜索数据。也就是_all代表所有的索引。


3 multi-index搜索模式
所谓的multi-index就是从多个index中搜索数据。相对使用较少,只有在复合数据搜索的时候,可能出现。一般来说,如果真使用复合数据搜索,都会使用_all。
如:搜索引擎中的无条件搜索。(现在的应用中都被屏蔽了。使用的是默认搜索条件,执行数据搜索。 如: 电商中的搜索框默认值, 搜索引擎中的类别)
无条件搜索,在搜索应用中称为“魔鬼搜索”,代表的是,搜索引擎会执行全数据检索,效率极低,且对资源有非常高的压力。
语法:

GET _search

GET /index_name1,index_name2/_search # 搜索多个index中的数据

GET /index_name/type_name1/_search # 所属一个index中type的数据

GET /prefix_*/_search # 通配符搜索
GET /*_suffix/_search

GET /index_name1,index_name2/type_name1/_search # 搜索多个index中type的数据

GET /_all/_search # _all代表所有的索引

  


4 分页搜索
语法:

GET /_search?size=10 # size查询数据的行数

GET /_search?from=0&size=10 # from 从第几行开始查询,行号从0开始。

 


4.1 deep paging问题
什么是deep paging?
就是搜索深度,如数据有100万,分页要求每页50条数据,总计2万页,现在搜索第1000页,执行的搜索语句就是: GET /_search?from=49999&size=50。执行的时候,请求发送到协调节点中,协调节点将搜索请求发送给所有的节点,而数据可能分部在多个节点中,那么搜索过程就很麻烦了。过程是集群中的每个节点将节点内符合要求的数据返回给协调节点,协调节点再将所有节点返回的数据根据默认排序条件(_score)排序,并筛选最终符合要求的数据返回给客户端。
这个搜索的过程对协调节点的压力太高。尽量避免出现deep paging操作。
上述案例解释:集群有4个节点,每个节点有1个分片(primary shard),每个分片中有数据25万。请求发起,命令为GET /_search?from=49999&size=50。协调节点将请求发给所有的节点,所有的节点分别查询第50000~50050条数据,ES的分页实际上是伪分页,每个节点返回的数据是0~50050条数据。协调节点得到的数据是50050*4条数据。协调节点实现排序,再找出50000~50050的50条数据,再返回。


5 +/-搜索
语法:
GET /products_index/phone_type/_search?q=name:plus

GET /products_index/phone_type/_search?q=+name:plus

GET /products_index/phone_type/_search?q=-name:plus
+ :和不定义符号含义一样,就是搜索指定的字段中包含key words的数据
- : 与+符号含义相反,就是搜索指定的字段中不包含key words的数据


6 _all应用2
如:电商平台中,搜索手机,问,是搜索商品名中包含手机的商品?还是搜索商品卖点中包含手机的商品?还是搜索商品详情描述中包含手机的商品?
在ES中,可以直接提供一个搜索关键字,不提供搜索的字段名。默认是再全字段数据中搜索关键字内容。
在ES中,每保存一个document,都会将document中所有的field拼接到一起,保存为一个命名为_all的字段。这个_all字段,就是默认搜索的字段。
_all是一个默认使用的搜索数据存储单元,不是一个可以指明使用的字段命名。
语法:
GET /index_name/type_name/_search?q=key_words
这种搜索代表索引中的Document中,任意的一个field包含key_words都会被搜索到。执行命令的时候,ES底层是使用_all元数据搜索的。在ES维护Document的时候,会将Document中的所有字段数据作为一个_all元数据执行的field。如:
Document数据是{ "name" : "zhangsan", "age" : 20, "email" : "[email protected]" },在ES保存Document的时候,会额外维护一个_all字段,字段数据为"zhangsan 20 [email protected]"。那么在搜索的时候,不指定要搜索匹配的field,ES就从_all元数据中匹配key_words。
不推荐生产环境中使用,因为数据越复杂,搜索效率越低。

猜你喜欢

转载自www.cnblogs.com/yucongblog/p/11953560.html
今日推荐