周期学习计划(1.2) ES的springboot部署

最新推荐文章于 2024-07-15 11:06:06 发布

开心磊磊

最新推荐文章于 2024-07-15 11:06:06 发布

阅读量141

点赞数

分类专栏：系统学习文章标签： es spring boot

本文链接：https://blog.csdn.net/habazhu1110/article/details/116237163

版权

系统学习专栏收录该内容

7 篇文章 0 订阅

订阅专栏

本文详细介绍了如何在生产环境中使用Elasticsearch，涵盖elasticsearchTemplate的运用、文档操作、查询定制、数据冲突控制、分页和滚动搜索，以及批量操作的最佳实践，适合深入理解并实践ES技术。

摘要由CSDN通过智能技术生成

学习目标：

elasticsearch在生产环境中使用

内容参见https://blog.csdn.net/pyfysf/article/details/100810846

学习内容：

elasticsearchTemplate

//通过这个注解，可以不用写gettersetter方法
@Data
//通过这个注解可以声明一个文档，指定其所在的索引库和type,如果是es7type可以不写的
@Document(indexName = "testdoct", type = "_doc")
public class TestBean implements Serializable {
    public TestBean() {
    }

    public TestBean(long id, String name, Integer age, String sex, String desc) {
        this.id = id;
        this.name = name;
        this.age = age;
        this.sex = sex;
        this.desc = desc;
    }

	// 必须指定一个id，如果不给id的话就会自动生成一个uuid
    @Id
    private long id;
    // 这里配置了分词器，字段类型，可以不配置，默认也可
    @Field(analyzer = "ik_smart", type = FieldType.Text)
    private String name;
    //使用倒排索引,默认是true
    @Filed(store=ture) 
    private Integer age;
    @Field(analyzer = "ik_smart", type = FieldType.Text)
    private String sex;
	@Field(analyzer = "ik_smart", type = FieldType.Text)
    private String desc;
}

新增

tmp.index().相当于insertOrupdate

删除

当执行tmp.delete()其实es并没有物理删除,只是逻辑删除,等到磁盘区域不足的时候才会执行真正的物理删除.修改和删除都会让verson+1

定制化的查询,只查询_resource中的部分field.可以用restful的方式进行查询指定列

http://ip:端口/mydoc/1

查询包含1的

http://ip:端口/mydoc/1?id,name

查询文档

常规查询

GET /index_demo/_doc/1
GET /index_demo/_doc/_search
查询结果
{
"_index": "my_doc",
"_type": "_doc",
"_id": "2",
"_score": 1.0,
"_version": 9,
"_source": {
"id": 1002,
"name": "imooc-2",
"desc": "imooc is fashion",
"create_date": "2019-12-25"
}
}
元数据
_index：文档数据所属那个索引，理解为数据库的某张表即可。
_type：文档数据属于哪个类型，新版本使用_doc。
_id：文档数据的唯一标识，类似数据库中某张表的主键。可以自动生成或者手动指定。
_score：查询相关度，是否契合用户匹配，分数越高用户的搜索体验越高。
_version：版本号。
_source：文档数据，json格式。
定制结果集
GET /index_demo/_doc/1?_source=id,name
GET /index_demo/_doc/_search?_source=id,name
判断文档是否存在
HEAD /index_demo/_doc/1

可以通过query配置类似sql的查询条件.

还可以配置sort("asc") desc排序

highlight{

pre_tags:"高亮开始标记","post_tags":高亮结束标记, fields:[es数据库字段]

}

es如何控制数据冲突:乐观锁

老版本通过version来管理,新的通过_seq_no和_primary_term来实现.

es深度分页

增加from和size实现分页,如果分页第一万页,两万页那么此时性能消耗就很高.就是所谓的深度分页

{
 query:{},
from:9999
size:10
}

es的解决方案是

1.设置最大页数.比如淘宝限制最大页面是100页.超过100页的数据就不在展示.

2.可以通过settings语法查看.index.max_result_window查看内容和修改该值

大数据的查询

scroll 滚动搜索
一次性查询1万+数据，往往会造成性能影响，因为数据量太多了。这个时候可以使用滚动搜索，也就是 scroll。
滚动搜索可以先查询出一些数据，然后再紧接着依次往下查询。在第一次查询的时候会有一个滚动id，相当于一个锚标记，随后再次滚动搜索会需要上一次搜索的锚标记，根据这个进行下一次的搜索请求。每次搜索都是基于一个历史的数据快照，查询数据的期间，如果有数据变更，那么和搜索是没有关系的，搜索的内容还是快照中的数据。scroll=1m，相当于是一个session会话时间，搜索保持的上下文时间为1分钟。

POST    /shop/_search?scroll=1m
{
    "query": { 
        "match_all": {
        }
    },  
    "sort" : ["_doc"], 
    "size":  5
}

POST    /_search/scroll
{
    "scroll": "1m", 
    "scroll_id" : "your last scroll_id"
}

官文地址：https://www.elastic.co/guide/cn/elasticsearch/guide/current/scroll.html

滚动搜索需要注意的就是查询结果是基于快照,也就是会有数据延迟,在设置的时间内快照不会受到es数据库的数据变更影响..首次查询返回一个scoreId,下次查询把scrollId带回去,需要注意的是一旦超过设置时间,scoreId也就不能用了,使用的话会报错.

批量搜索megt

和value相比返回值的结构不一样.

批量操作bluk 增删改

基本语法
bulk操作和以往的普通请求格式有区别。不要格式化json，不然就不在同一行了，这个需要注意。

{ action: { metadata }}\n
{ request body }\n
{ action: { metadata }}\n
{ request body }\n
...
{ action: { metadata }}代表批量操作的类型，可以是新增、删除或修改
\n是每行结尾必须填写的一个规范，每一行包括最后一行都要写，用于es的解析
{ request body }是请求body，增加和修改操作需要，删除操作则不需要
批量操作的类型
action 必须是以下选项之一:

create：如果文档不存在，那么就创建它。存在会报错。发生异常报错不会影响其他操作。
index：创建一个新文档或者替换一个现有的文档。
update：部分更新一个文档。
delete：删除一个文档。
metadata 中需要指定要操作的文档的_index 、 _type 和 _id，_index 、 _type也可以在url中指定

实操
create新增文档数据，在metadata中指定index以及type

POST /_bulk
{"create": {"_index": "shop2", "_type": "_doc", "_id": "2001"}}
{"id": "2001", "nickname": "name2001"}
{"create": {"_index": "shop2", "_type": "_doc", "_id": "2002"}}
{"id": "2002", "nickname": "name2002"}
{"create": {"_index": "shop2", "_type": "_doc", "_id": "2003"}}
{"id": "2003", "nickname": "name2003"}
create创建已有id文档，在url中指定index和type

POST /shop/_doc/_bulk
{"create": {"_id": "2003"}}
{"id": "2003", "nickname": "name2003"}
{"create": {"_id": "2004"}}
{"id": "2004", "nickname": "name2004"}
{"create": {"_id": "2005"}}
{"id": "2005", "nickname": "name2005"}
index创建，已有文档id会被覆盖，不存在的id则新增

POST /shop/_doc/_bulk
{"index": {"_id": "2004"}}
{"id": "2004", "nickname": "index2004"}
{"index": {"_id": "2007"}}
{"id": "2007", "nickname": "name2007"}
{"index": {"_id": "2008"}}
{"id": "2008", "nickname": "name2008"}

update跟新部分文档数据

POST /shop/_doc/_bulk
{"update": {"_id": "2004"}}
{"doc":{ "id": "3004"}}
{"update": {"_id": "2007"}}
{"doc":{ "nickname": "nameupdate"}}
delete批量删除
POST /shop/_doc/_bulk
{"delete": {"_id": "2004"}}
{"delete": {"_id": "2007"}}
综合批量各种操作

POST /shop/_doc/_bulk
{"create": {"_id": "8001"}}
{"id": "8001", "nickname": "name8001"}
{"update": {"_id": "2001"}}
{"doc":{ "id": "20010"}}
{"delete": {"_id": "2003"}}
{"delete": {"_id": "2005"}}
官文：https://www.elastic.co/guide/cn/elasticsearch/guide/current/bulk.html

批量操作一旦部分数据异常时不阻塞的.

create:不存在就新增,存在就报异常

index:不存在就新增,存在就更新

批量操作是不是一定是高效的,未必的,这个批量操作是把所有相关数据放到内存,所以批量结果是受硬件影响的并不是越大越好,官网给了一些探索这个值的建议.但是就类似于mysql的批量插入一样,我们可以设置1000作为批量,性能也一定比单条要爽.