3.1_springboot2.x检索之elasticsearch安装&快速入门
1、elasticsearch简介&安装
1.1.1、elasticsearch介绍
我们的应用经常需要添加检索功能,开源的 ElasticSearch 是目前全文搜索引擎的首选。他可以快速的存储、搜索和分析海量数据。Spring Boot通过整合Spring Data ElasticSearch为我们提供了非常便捷的检索功能支持;
Elasticsearch是一个分布式搜索服务,提供Restful API,底层基于Lucene,采用多shard(分片)的方式保证数据安全,并且提供自动resharding的功能,github等大型的站点也是采用了ElasticSearch作为其搜索服务。
1.1.2、安装elasticsearch
启动linux虚拟机,下载elasticsearch镜像
在docker容器中查看镜像
docker search elasticsearch
下载:
docker pull elasticsearch:6.8.3
查看镜像:
docker images
注意:
下载完镜像,运行:
elasticsearch用java编写,默认初始会占用2G内存空间,虚拟机内存不够,所以得限制使用内存。
docker run -e ES_JAVA_OPTS="-Xms256m -Xmx256m" -d -p
9200:9200 -p 9300:9300 --name ES01 dd156dd42341
端口说明:
9200:web通信
9300:分布式节点通信
这里有可能启动报错:错误原因之一运行:
.docker logs -f 容器id
查看容器日志信息,看最后
面发现一个error:
ERROR: [1] bootstrap checks failed
[1]: max virtual memory areas vm.max_map_count
[65530] is too low, increase to at least
显示max_map_count的值太小了,需要设大到262144
查看max_map_count :
cat /proc/sys/vm/max_map_count
65530
设置max_map_count:
sysctl -w vm.max_map_count=262144
vm.max_map_count = 262144
重启容器:docker start 容器id或名字
测试:
elasticsearch快速入门
Elasticsearch是面向文档(document oriented)的,这意味着它可以存储整个对象或文档(document)。然而它不仅仅是存储,还会**索引(index)**每个文档的内容使之可以被搜索。在Elasticsearch中,你可以对文档(而非成行成列的数据)进行索引、搜索、排序、过滤。这种理解数据的方式与以往完全不同,这也是Elasticsearch能够执行复杂的全文搜索的原因之一。
ELasticsearch使用Javascript对象符号(JavaScript Object Notation),也就是JSON,作为文档序列化格式。JSON现在已经被大多语言所支持,而且已经成为NoSQL领域的标准格式。它简洁、简单且容易阅读。
以下使用JSON文档来表示一个用户对象:
{
"email": "john@smith.com",
"first_name": "John",
"last_name": "Smith",
"info": {
"bio": "Eco-warrior and defender of the weak",
"age": 25,
"interests": [ "dolphins", "whales" ]
},
"join_date": "2014/05/01"
}
**理解elasticsearch:**举例
假设我们刚好在Megacorp工作,这时人力资源部门出于某种目的需要让我们创建一个员工目录,这个目录用于促进人文关怀和用于实时协同工作,所以它有以下不同的需求:
-
数据能够包含多个值的标签、数字和纯文本。
-
检索任何员工的所有信息。
-
支持结构化搜索,例如查找30岁以上的员工。
-
支持简单的全文搜索和更复杂的**短语(phrase)**搜索
-
高亮搜索结果中的关键字
-
能够利用图表管理分析这些数据
我们首先要做的是存储员工数据,每个文档代表一个员工。在Elasticsearch中存储数据的行为就叫做索引(indexing),不过在索引之前,我们需要明确数据应该存储在哪里。
在Elasticsearch中,文档归属于一种类型(type),而这些类型存在于**索引(index)**中,我们可以画一些简单的对比图来类比传统关系型数据库:
索引–mysq哪个数据库
类型–mysql数据库中的表
文档–mysql表中的每一行记录
属性–mysql中每一列的属性-
索引(名词) 如上文所述,一个索引(index)就像是传统关系数据库中的数据库,它是相关文档存储的地方,index的复数是indices 或indexes。
-
索引(动词) **「索引一个文档」表示把一个文档存储到索引(名词)**里,以便它可以被检索或者查询。这很像SQL中的
INSERT
关键字,差别是,如果文档已经存在,新的文档将覆盖旧的文档。 -
倒排索引 传统数据库为特定列增加一个索引,例如B-Tree索引来加速检索。Elasticsearch和Lucene使用一种叫做**倒排索引(inverted index)**的数据结构来达到相同目的。
所以为了创建员工目录,我们将进行如下操作:
- 为每个员工的**文档(document)**建立索引,每个文档包含了相应员工的所有信息。
- 每个文档的类型为
employee
。 employee
类型归属于索引megacorp
。megacorp
索引存储在Elasticsearch集群中。
PUT /megacorp/employee/1 { "first_name" : "John", "last_name" : "Smith", "age" : 25, "about" : "I love to go rock climbing", "interests": [ "sports", "music" ] }
我们看到path:
/megacorp/employee/1
包含三部分信息:megacorp:索引名
employee:类型名
1:这个员工的ID
Postman简单测试:
-
让我们在目录中加入更多员工信息:
存储数据
PUT /megacorp/employee/2
{
"first_name" : "Jane",
"last_name" : "Smith",
"age" : 32,
"about" : "I like to collect rock albums",
"interests": [ "music" ]
}
PUT /megacorp/employee/3
{
"first_name" : "Douglas",
"last_name" : "Fir",
"age" : 35,
"about": "I like to build cabinets",
"interests": [ "forestry" ]
}
检索文档
我们只要执行HTTP GET请求并指出文档的“地址”——索引、类型和ID既可。根据这三部分信息,我们就可以返回原始JSON文档:
GET /megacorp/employee/1
响应的内容中包含一些文档的元信息,John Smith的原始JSON文档包含在_source
字段中。
DELETE:删除员工
HEAD:检查员工是否存在,看状态码
我们通过HTTP方法GET
来检索文档,同样的,我们可以使用DELETE
方法删除文档,使用HEAD
方法检查某文档是否存在。如果想更新已存在的文档,我们只需再PUT
一次。
简单搜索
GET
请求非常简单——你能轻松获取你想要的文档。让我们来进一步尝试一些东西,比如简单的搜索!
我们尝试一个最简单的搜索全部员工的请求:
GET /megacorp/employee/_search
你可以看到我们依然使用megacorp
索引和employee
类型,但是我们在结尾使用关键字_search
来取代原来的文档ID。响应内容的hits
数组中包含了我们所有的三个文档。默认情况下搜索会返回前10个结果。
接下来,让我们搜索姓氏中包含**“Smith”的员工。要做到这一点,我们将在命令行中使用轻量级的搜索方法。这种方法常被称作查询字符串(query string)**搜索,因为我们像传递URL参数一样去传递查询语句
GET /megacorp/employee/_search?q=last_name:Smith
我们在请求中依旧使用_search
关键字,然后将查询语句传递给参数q=
。这样就可以得到所有姓氏为Smith的结果:
{
...
"hits": {
"total": 2,
"max_score": 0.30685282,
"hits": [
{
...
"_source": {
"first_name": "John",
"last_name": "Smith",
"age": 25,
"about": "I love to go rock climbing",
"interests": [ "sports", "music" ]
}
},
{
...
"_source": {
"first_name": "Jane",
"last_name": "Smith",
"age": 32,
"about": "I like to collect rock albums",
"interests": [ "music" ]
}
}
]
}
}
使用DSL语句查询
查询字符串搜索便于通过命令行完成特定(ad hoc)的搜索,但是它也有局限性(参阅简单搜索章节)。Elasticsearch提供丰富且灵活的查询语言叫做DSL查询(Query DSL),它允许你构建更加复杂、强大的查询。
**DSL(Domain Specific Language特定领域语言)**以JSON请求体的形式出现。我们可以这样表示之前关于“Smith”的查询:
GET /megacorp/employee/_search
{
"query" : {
"match" : {
"last_name" : "Smith"
}
}
}
这会返回与之前查询相同的结果。你可以看到有些东西改变了,我们不再使用**查询字符串(query string)**做为参数,而是使用请求体代替。这个请求体使用JSON表示,其中使用了match
语句(查询类型之一,具体我们以后会学到)
更复杂的搜索
我们让搜索稍微再变的复杂一些。我们依旧想要找到姓氏为“Smith”的员工,但是我们只想得到年龄大于30岁的员工。我们的语句将添加过滤器(filter),它使得我们高效率的执行一个结构化搜索:
GET /megacorp/employee/_search
{
"query" : {
"filtered" : {
"filter" : {
"range" : {
"age" : { "gt" : 30 } <1>
}
},
"query" : {
"match" : {
"last_name" : "smith" <2>
}
}
}
}
}
- <1> 这部分查询属于区间过滤器(range filter),它用于查找所有年龄大于30岁的数据——
gt
为"greater than"的缩写。 - <2> 这部分查询与之前的
match
**语句(query)**一致。
现在不要担心语法太多,我们将会在以后详细的讨论。你只要知道我们添加了一个**过滤器(filter)**用于执行区间搜索,然后重复利用了之前的match
语句。现在我们的搜索结果只显示了一个32岁且名字是“Jane Smith”的员工:
{
...
"hits": {
"total": 1,
"max_score": 0.30685282,
"hits": [
{
...
"_source": {
"first_name": "Jane",
"last_name": "Smith",
"age": 32,
"about": "I like to collect rock albums",
"interests": [ "music" ]
}
}
]
}
}
全文搜索
到目前为止搜索都很简单:搜索特定的名字,通过年龄筛选。让我们尝试一种更高级的搜索,全文搜索——一种传统数据库很难实现的功能。
我们将会搜索所有喜欢**“rock climbing”**的员工:
GET /megacorp/employee/_search
{
"query" : {
"match" : {
"about" : "rock climbing"
}
}
}
你可以看到我们使用了之前的match
查询,从about
字段中搜索**“rock climbing”**,我们得到了两个匹配文档:
{
...
"hits": {
"total": 2,
"max_score": 0.16273327,
"hits": [
{
...
"_score": 0.16273327, <1>
"_source": {
"first_name": "John",
"last_name": "Smith",
"age": 25,
"about": "I love to go rock climbing",
"interests": [ "sports", "music" ]
}
},
{
...
"_score": 0.016878016, <2>
"_source": {
"first_name": "Jane",
"last_name": "Smith",
"age": 32,
"about": "I like to collect rock albums",
"interests": [ "music" ]
}
}
]
}
}
- <1><2> 结果相关性评分。
默认情况下,Elasticsearch根据结果相关性评分来对结果集进行排序,所谓的「结果相关性评分」就是文档与查询条件的匹配程度。很显然,排名第一的John Smith
的about
字段明确的写到**“rock climbing”**。
但是为什么Jane Smith
也会出现在结果里呢?原因是**“rock”在她的abuot
字段中被提及了。因为只有“rock”被提及而“climbing”**没有,所以她的_score
要低于John。
这个例子很好的解释了Elasticsearch如何在各种文本字段中进行全文搜索,并且返回相关性最大的结果集。**相关性(relevance)**的概念在Elasticsearch中非常重要,而这个概念在传统关系型数据库中是不可想象的,因为传统数据库对记录的查询只有匹配或者不匹配。
短语搜索
目前我们可以在字段中搜索单独的一个词,这挺好的,但是有时候你想要确切的匹配若干个单词或者短语(phrases)。例如我们想要查询同时包含"rock"和"climbing"(并且是相邻的)的员工记录。
要做到这个,我们只要将match
查询变更为match_phrase
查询即可:
GET /megacorp/employee/_search
{
"query" : {
"match_phrase" : {
"about" : "rock climbing"
}
}
}
毫无疑问,该查询返回John Smith的文档:
{
...
"hits": {
"total": 1,
"max_score": 0.23013961,
"hits": [
{
...
"_score": 0.23013961,
"_source": {
"first_name": "John",
"last_name": "Smith",
"age": 25,
"about": "I love to go rock climbing",
"interests": [ "sports", "music" ]
}
}
]
}
}
高亮我们的搜索
很多应用喜欢从每个搜索结果中**高亮(highlight)**匹配到的关键字,这样用户可以知道为什么这些文档和查询相匹配。在Elasticsearch中高亮片段是非常容易的。
让我们在之前的语句上增加highlight
参数:
GET /megacorp/employee/_search
{
"query" : {
"match_phrase" : {
"about" : "rock climbing"
}
},
"highlight": {
"fields" : {
"about" : {}
}
}
}
当我们运行这个语句时,会命中与之前相同的结果,但是在返回结果中会有一个新的部分叫做highlight
,这里包含了来自about
字段中的文本,并且用<em></em>
来标识匹配到的单词。
{
...
"hits": {
"total": 1,
"max_score": 0.23013961,
"hits": [
{
...
"_score": 0.23013961,
"_source": {
"first_name": "John",
"last_name": "Smith",
"age": 25,
"about": "I love to go rock climbing",
"interests": [ "sports", "music" ]
},
"highlight": {
"about": [
"I love to go <em>rock</em> <em>climbing</em>" <1>
]
}
}
]
}
}
分析
最后,我们还有一个需求需要完成:允许管理者在职员目录中进行一些分析。 Elasticsearch有一个功能叫做聚合(aggregations),它允许你在数据上生成复杂的分析统计。它很像SQL中的GROUP BY
但是功能更强大。
举个例子,让我们找到所有职员中最大的共同点(兴趣爱好)是什么:
GET /megacorp/employee/_search
{
"aggs": {
"all_interests": {
"terms": { "field": "interests" }
}
}
}
暂时先忽略语法只看查询结果:
{
...
"hits": { ... },
"aggregations": {
"all_interests": {
"buckets": [
{
"key": "music",
"doc_count": 2
},
{
"key": "forestry",
"doc_count": 1
},
{
"key": "sports",
"doc_count": 1
}
]
}
}
}
我们可以看到两个职员对音乐有兴趣,一个喜欢林学,一个喜欢运动。这些数据并没有被预先计算好,它们是实时的从匹配查询语句的文档中动态计算生成的。如果我们想知道所有姓"Smith"的人最大的共同点(兴趣爱好),我们只需要增加合适的语句既可:
GET /megacorp/employee/_search
{
"query": {
"match": {
"last_name": "smith"
}
},
"aggs": {
"all_interests": {
"terms": {
"field": "interests"
}
}
}
}
all_interests
聚合已经变成只包含和查询语句相匹配的文档了:
...
"all_interests": {
"buckets": [
{
"key": "music",
"doc_count": 2
},
{
"key": "sports",
"doc_count": 1
}
]
}
聚合也允许分级汇总。例如,让我们统计每种兴趣下职员的平均年龄:
GET /megacorp/employee/_search
{
"aggs" : {
"all_interests" : {
"terms" : { "field" : "interests" },
"aggs" : {
"avg_age" : {
"avg" : { "field" : "age" }
}
}
}
}
}
虽然这次返回的聚合结果有些复杂,但任然很容易理解:
...
"all_interests": {
"buckets": [
{
"key": "music",
"doc_count": 2,
"avg_age": {
"value": 28.5
}
},
{
"key": "forestry",
"doc_count": 1,
"avg_age": {
"value": 35
}
},
{
"key": "sports",
"doc_count": 1,
"avg_age": {
"value": 25
}
}
]
}
该聚合结果比之前的聚合结果要更加丰富。我们依然得到了兴趣以及数量(指具有该兴趣的员工人数)的列表,但是现在每个兴趣额外拥有avg_age
字段来显示具有该兴趣员工的平均年龄
即使你还不理解语法,但你也可以大概感觉到通过这个特性可以完成相当复杂的聚合工作,你可以处理任何类型的数据。
更多介绍请查看官方文档。