一、什么是ElasticSearch
Elaticsearch,简称为 ES, ES 是一个开源的高扩展的分布式全文搜索引擎, 是整个 ElasticStack 技术栈的核心。它可以近乎实时的存储、检索数据;本身扩展性很好,可以扩展到上百台服务器,处理 PB 级别的数据。
二、Elasticsearch入门
1. 下载
下载路径 官方文档
2.解压并启动
注意两个端口号: (1)9300为ElasticSearch集群组件使用的端口号 (2)3200位浏览器访问的RestFul风格的端口
3.通过9200访问服务
看到该页面则说明启动成功
4.可能导致启动失败的原因
- 7.8以后的ElasticSearch需要JDK1.8以上,如果系统环境变量配置过JAVAHOME的话会优先使用系统配置的JDK,若系统没配置JAVAHOME则会使用自带的JDK
- 启动后闪退则修改
/config/jvm.options 配置文件
# 设置 JVM 初始内存为 1G。此值可以设置与-Xmx 相同,以避免每次垃圾回收完成后 JVM 重新分配内存
# Xms represents the initial size of total heap space
# 设置 JVM 最大可用内存为 1G
# Xmx represents the maximum size of total heap space
-Xms1g
-Xmx1g
三、使用前必了解知识点
1.什么是ESTful
REST 指的是一组架构约束条件和原则。满足这些约束条件和原则的应用程序或设计就是 RESTful。Web 应用程序最重要的 REST 原则是,客户端和服务器之间的交互在请求之间是无状态的。从客户端到服务器的每个请求都必须包含理解请求所必需的信息。如果服务器在请求之间的任何时间点重启,客户端不会得到通知。此外,无状态请求可以由任何可用服务器回答,这十分适合云计算之类的环境。客户端可以缓存数据以改进性能。在服务器端,应用程序状态和功能可以分为各种资源。资源是一个有趣的概念实体,它向客户端公开。资源的例子有:应用程序对象、数据库记录、算法等等。每个资源都使用 URI(Universal Resource Identifier) 得到一个唯一的地址。所有资源都共享统一的接口,以便在客户端和服务器之间传输状态。使用的是标准的 HTTP 方法,比如 GET、PUT、POST 和DELETE。 在 REST 样式的 Web 服务中,每个资源都有一个地址。资源本身都是方法调用的目标,方法列表对所有资源都是一样的。这些方法都是标准方法,包括 HTTP GET、POST、PUT、DELETE,还可能包括 HEAD 和 OPTIONS。简单的理解就是,如果想要访问互联网上的资源,就必须向资源所在的服务器发出请求,请求体中必须包含资源的网络路径,以及对资源进行的操作(增删改查)。
2.为什么要使用Postman
如果直接通过浏览器向 Elasticsearch 服务器发请求,那么需要在发送的请求中包含HTTP 标准的方法,而 HTTP 的大部分特性且仅支持 GET 和 POST 方法。所以为了能方便地进行客户端的访问,可以使用 Postman 软件。Postman 提供功能强大的 Web API 和 HTTP 请求调试。软件功能强大,界面简洁明晰、操作方便快捷,设计得很人性化。Postman 中文版能够发送任何类型的 HTTP 请求 (GET, HEAD, POST, PUT…),不仅能够表单提交,且可以附带任意类型请求体。
3.数据格式
Elasticsearch 是面向文档型数据库,一条数据在这里就是一个文档。我们将 Elasticsearch 里存储文档数据和关系型数据库 MySQL 存储数据的概念进行一个类比。 ES 里的 Index 可以看做一个库,而 Types 相当于表,Documents 则相当于表的行。这里 Types 的概念已经被逐渐弱化,Elasticsearch 6.X 中,一个 index 下已经只能包含一个type,Elasticsearch 7.X 中, Type 的概念已经被删除了。
4.正向索引和倒排索引
用两张表格来简单区别一下
- 正向索引
id | content |
---|
1001 | my name is zhangsan | 1002 | my name is lisi |
- 倒排索引
这种情况下表(ElasticSearch的type)的概念已经逐渐弱化,现在这种概念已经被删除了。
keyword | content |
---|
name | 1001,1002 | zhang | 1001 |
5.常用的四种请求方式
GET、Delete、 POST、 PUT,其中GET、Delete和PUT这三种请求方式执行的结果是幂等的,简单来说就是每次执行的结果都是相同的,而POST是不幂等的,每次执行的结果不一定是一样的。 其中HEAD也是幂等的。
四、索引的操作
1.创建索引
- 创建一个shopping的索引,PUT方式下的
127.0.0.1:9200/shopping - 如果重复创建
- 如果使用不具有幂等性的POST方式创建
2.获取索引的相关信息
- 查询指定索引信息,GET方式下的
127.0.0.1:9200/shopping - 查询所有索引的信息
3.删除索引
- 删除指定索引,DELETE方式下的
127.0.0.1:9200/shopping_1 再次查询发现的确删除成功
五、文档操作
1.创建文档(自动生成id)
在指定索引shopping下创建文档:在POST方式下访问127.0.0.1:9200/shopping/_doc ,因为创建时会创建一个id给文档,所有必须使用不具有幂等作用的post,如果我们给文档设定了指定id时则可以用其他方式。
{
"name" : "PNING",
"age": 18,
"hobbies" : ["eat","run"]
}
这种情况下如果重复运行则会创建多个具有不同id的文档
2.创建文档(指定id)
在指定索引shopping下创建文档:在POST方式下访问127.0.0.1:9200/shopping/_doc/1 ,
{
"name" : "PNING_1",
"age": 18,
"hobbies" : ["eat","run"]
}
这种情况下如果重复运行则全量修改(可以理解为数据部分被覆盖)该id文档下的数据包括版本号。
- 使用POST创建
- 使用PUT创建
3.查询文档数据
-
查询指定id文档数据,在GET方式下访问127.0.0.1:9200/shopping/_doc/2 ,即可查询shopping索引下id为2的文档数据 -
查询所有文档数据 (1)URL方式:在GET方式下访问127.0.0.1:9200/shopping/_search ,即可查询shopping索引下所以的文档数据 (2.)请求体方式:在GET方式下访问127.0.0.1:9200/shopping/_search
4. 修改文档数据
- 全量修改(覆盖存储的数据)
使用指定id创建文档的方式(PUT和POST都可以),即可全量修改上一次的数据,因为我不小心多点了一次,所以版本现在是3 - 局部数据修改(修改指定数据):在POST方式下访问
127.0.0.1:9200/shopping/_update/1 即可修改shopping索引下id为1的文档数据
{
"doc" :{
"hobbies" : ["play"]
}
}
六、删除文档
在DELETE方式下访问127.0.0.1:9200/shopping/_doc/1001 即可删除shopping索引下id为1001的文档数据
七、条件查询
1.单条件查询
- URL查询:
127.0.0.1:9200/shopping/_search?q=hobbies:play ,查询shopping索引下hobbies内容为play的数据 - 请求体查询(分页查询部分数据并进行排序)
127.0.0.1:9200/shopping/_search?q=hobbies:play ,查询shopping索引下hobbies内容为play的数据,从第0条开始,一页5条,展示资源为hobbies 字段,按年龄进行降序排序
{
"query" : {
"match" : {
"hobbies" : "eat"
}
},
"from" : 0,
"size" : 5,
"_source" : ["hobbies"],
"sort" : {
"age" : {
"order":"desc"
}
}
}
2.多条件查询
127.0.0.1:9200/shopping/_search?q=hobbies:play ,查询shopping索引下hobbies内容为eat或者名字为PNING的数据,并且筛选出age大于1 的那部分 注意:should属性为或,如果要且的话需要将should改为must
{
"query" : {
"bool" : {
"should" : [
{
"match" : {
"hobbies" : "eat"
}
},
{
"match" : {
"name" : "PNING"
}
}
],
"filter" : {
"range" : {
"age" :{
"gt" : 1
}
}
}
}
}
}
3.精确查询(仅对于中文)
如果是英文,则需要完全一致才会被查询出来,但如果为中文的话,我们上述的查询都只会变成模糊查询,例如查询华米商品时候,不仅会查询出华米本身的商品,还会把名字中带华和带米商品全部查询出来
{
"query" :{
"match_phrase" : {
"name" : "王亮"
}
},
"highlight" : {
"fields" : {
"name" : {}
}
}
}
此时查询出来的就只是单纯的模糊查询了,后面的是将查询出来的姓名高亮显示
|