目录
1. 简单操作
1.1 查询所有
GET //DeviceLog/_search
GET _search
返回数据含义
took:耗费了几毫秒
timed_out:是否超时,false是没有,默认无timeout
_shards:shards fail的条件(primary和replica全部挂掉),不影响其他shard。
默认情况下来说,一个搜索请求,会打到一个index的所有primary shard上去,当然了,
每个primary shard都可能会有一个或多个replic shard,所以请求也可以到primary shard的其中一个replica shard上去。
hits.total:本次搜索,返回了几条结果
hits.max_score:score的含义,就是document对于一个search的相关度的匹配分数,越相关,就越匹配,分数也高
hits.hits:包含了匹配搜索的document的详细数据,默认查询前10条数据,按_score降序排序
timeout这边默认是没有的,也就意味着当你搜索的时候他会直到所有搜索结束才会返回结果,但是当我们做一些时间比较敏感的搜
索的时候,等待时间很久,对用户来说是非常不友好的。那我们可以通过设置timeout这个值,来定时返回已经搜索到的数据timeout
机制,指定每个shard,就只能在timeout时间范围内,将搜索到的部分数据(也可能是搜索到的全部数据),直接返回给client,而
不是等到所有数据全部搜索出来后再返回。
timeout=10ms,timeout=1s,timeout=1m
GET /_search?timeout=10m
1.2 索引重命名
https://blog.csdn.net/qq_34624315/article/details/83089794
POST _reindex
{
"source": {
"index": "devicelog_2019-10"
},
"dest": {
"index": "devicelog_2019-05"
}
}
1.3 删除索引
删除索引:
DELETE /my_index
你也可以这样删除多个索引:
DELETE /index_one,index_two
DELETE /index_*
你甚至可以这样删除 全部 索引:
DELETE /_all
DELETE /*
1.4 显示所有的索引
GET _cat/indices
自增ID
如果我们的数据没有自然ID,我们可以让Elasticsearch自动为我们生成。
请求结构发生了变化:PUT方法——“在这个URL中存储文档”变成了POST方法。
指定 ID 创建文档,使用 PUT。
其中的 doc 就是之前提到过的 type,在 6.0 之后已经废弃了,全部写成 doc 即可
PUT /test_index/doc/1
{
"username": "es",
"age": 12
}
不指定 ID ,使用 POST ,此时会随机生成一个 ID。
POST /test_index/doc
{
"username": "elk",
"age": 12
}
1.5 替换文档(全量替换)
PUT /ecommerce/product/1
{
"name" : "jiaqiangban gaolujie yagao",
"desc" : "gaoxiao meibai",
"price" : 30,
"producer" : "gaolujie producer",
"tags": [ "meibai", "fangzhu" ]
}
document是不可变的,如果要修改document的内容,可以通过全量替换,直接对document重新建立索引,
替换里面所有的内容。
es会将老的document标记为deleted(逻辑删除),然后新增我们给定的一个document,
当我们创建越来越多的document的时候,es会在适当的时机在后台自动删除(物理删除)标记为deleted的document。
替换必须带上所有的field,否则其他数据会丢失。
删除文档(删除)
DELETE /ecommerce/product/1
1.6 更新文档
ElasticSearch教程——partial update(更新文档)实现原理及并发控制
partial update语法如下
post /index/type/id/_update
{
"doc": {
"要修改的少数几个field即可,不需要全量的数据":"对应field的数据"
}
}
内部原理
看起来,好像partial update比较方便,每次就传递少数几个发生修改的field即可,
不需要将全量的document数据发送过去,那他是指上的内部原理又是什么呢?
其实es内部对partial update的实际执行和传统的全量替换方式是几乎一样的,其步骤如下
内部先获取到对应的document;
将传递过来的field更新到document的json中(这一步实质上也是一样的);
将老的document标记为deleted(到一定时候才会物理删除);
将修改后的新的document创建出来
partial update相比较全量替换的优点
所有从查询、修改和写回操作都是发生在es中的一个shard内部(一瞬间就完成,可能基本上是毫秒级别的),
避免了所有的网络数据传输的开销,大大提升了性能;
减少了查询和修改中的时间间隔,可以有效减少并发冲突的情况;
并发控制
partial update内部会自动执行我们之前所说的乐观锁的并发控制策略,具体可以参考ElasticSearch教程——并发问题与锁机制
即修改数据之前会比对版本,如果版本不对会更新到最新的数据,然后再进行修改,这个过程可能需要周而复始才能成功。
retry策略
就像ElasticSearch教程——并发问题与锁机制这篇博客在乐观锁的缺点中所说的一样,在尝试获取版本并进行数据更新的过程中,
这个过程可能需要多次重复执行,然而在某些时候我们又需要对这个重复执行的次数做个限制,那应该怎么做呢?
这边的retry_on_conflict就是我们设置的修改失败后的重复次数
post /index/type/id/_update?retry_on_conflict=5
当然啦,如果倔强的你必须规定是某个版本下的修改失败的最大重复次数还可以这么写
post /index/type/id/_update?retry_on_conflict=5&version=6
1.7 删除文档
delete /ecommerce/product/1
2. query DSL
DSL:Domain Specified Language,特定领域的语言
http request body:请求体,可以用json的格式来构建查询语法,比较方便,可以构建各种复杂的语法,比query string search肯定强大多了。
2.1 查询所有
GET /ecommerce/product/_search
{
"query": { "match_all": {} }
}
2.2 查询名字包含某个的商品,并按商品价格降序返回
get /ecommerce/product/_search
{
"query":{
"match": {
"name": "gaolujie"
}
},
"sort":{
"price":"desc"
}
}
2.3 分页查询
GET /ecommerce/product/_search
{
"query": { "match_all": {} },
"from": 1,
"size": 1
}
2.4 查询指定项
对返回的结果包含哪些filed进行限制
GET /ecommerce/product/_search
{
"query": { "match_all": {} },
"_source": ["name", "price"]
}
2.5 过滤查询
查询名字包含“gaolujie”的商品,并过滤出price在20到35之间的产品
GET /ecommerce/product/_search
{
"query": {
"bool": {
"must": [
{
"match": {
"name": "gaolujie"
}
}
],
"filter": {
"range": {
"price": {
"gte": 20,
"lte": 35
}
}
}
}
}
}
2.6 全文搜索与短语搜索
全文检索会将输入的搜索串拆解开来,去倒排索引里面去一一匹配,只要能匹配上任意一个拆解后的单词,就可以作为结果返回
全文搜索
GET /ecommerce/product/_search
{
"query" : {
"match" : {
"producer" : "6677"
}
}
}
phrase search,要求输入的搜索串,必须在指定的字段文本中,完全包含一模一样的,才可以算匹配,才能作为结果返回
短语搜索
GET /ecommerce/product/_search
{
"query" : {
"match_phrase" : {
"producer" : "gaolujie producer"
}
}
}