ElasticSearch
- 一、ElasticSearch安装
- 二、kibana安装
- 三、ES核心概念
- 1、索引
- 2、文档
- 3、类型
- 4、倒排索引
1、什么是ElasticSearch？
Elasticsearch是一个基于Lucene的搜索服务器。它提供了一个分布式多用户能力的全文搜索引擎，基于RESTful web 接口。Elasticsearch是用Java语言开发的，并作为Apache许可条款下的开放源码发布，是一种流行的企业级搜索引擎。Elasticsearch用于云计算中，能够达到实时搜索，稳定，可靠，快速，安装使用方便。
2、ElasticSearch有什么用？
- 分布式的搜索引擎和数据分析引擎
- 全文检索，结构化检索，数据分析
- 对海量数据进行近实时的处理
3、Elasticsearch的特点？
（1）可以作为一个大型分布式集群（数百台服务器）技术，处理PB级数据，服务大公司；也可以运行在单机上，服务小公司。
（2）Elasticsearch不是什么新技术，主要是将全文检索、数据分析以及分布式技术，合并在了一起，才形成了独一无二的ES。lucene（全文检索），商用的数据分析软件（也是有的），分布式数据库（mycat）。
（3）对用户而言，是开箱即用的，非常简单，作为中小型的应用，直接3分钟部署一下ES，就可以作为生产环境的系统来使用了，数据量不大，操作不是太复杂。
（4）数据库的功能面对很多领域是不够用的（事务，还有各种联机事务型的操作）；特殊的功能，比如全文检索，同义词处理，相关度排名，复杂数据分析，海量数据的近实时处理；Elasticsearch作为传统数据库的一个补充，提供了数据库所不能提供的很多功能。
一、ElasticSearch安装
1、下载 ElasticSearch 7.6.1
2、安装启动ElasticSearch head （需要有node.js环境）
启动：
npm install
npm run start解决跨域问题 配置 elasticsearch.yml：
http.cors.enabled: true
http.cors.allow-origin: "*"重启elasticserach服务
二、kibana安装
1、什么是Kibanna？
Kibana是为Elasticsearch设计的开源分析和可视化平台。你可以使用 Kibana 来搜索，查看存储在 Elasticsearch 索引中的数据并与之交互。你可以很容易实现高级的数据分析和可视化，以图表的形式展现出来。
2、下载kibana
3、访问 http://localhost:5601/ ， 默认端口5601
4、Kibana汉化，更改kibana.yml：
i18n.locale: "zh-CN"更改配置文件后重启
三、ES核心概念
ElasticSearch是面向文档，关系型数据库与ElasticSearch对比，一切都是Json
Relationl DB | ElasticSearch |
数据库（DataBase） | 索引（indices） |
表（Tables） | Type |
行（Rows） | Documents |
字段（Columns） | Fileds |
物理设计：
ElasticSearch在后台把索引分成多个分片，每个分片可以在不同服务器中迁移
ElasticSearch一个人就是一只军队，默认的集群名字叫elasticsearch
逻辑设计：
一个索引类型中，包含多个文档，比如说文档1，文档2。当我们索引一篇文档时，可以通过这样的顺序找到它：索引 =>类型 =>文档ID，通过这个组合我们就能索引到某个具体的文档。 注意：ID不必是整数，实际上它是个字符串。
1、索引
可理解为数据库，索引是映射类型的容器，Elasticsearch中的索引是一个非常大的文档集合。索引存储了映射类型中的字段和其他设置。然后他们被保存到了各个分片上。
物理设计：节点和分片 如何工作？
一个集群至少有一个节点，而一个节点就是一个
Elasticsearch进程，节点可以有多个索引默认的，如果你创建一个索引，那么索引将会有5个分片（主分片），每一个分片会有一个副本（赋值分片）。
2、文档
es是面向文档的，文档是es中可搜索的最小单位，es的文档由一个或多个字段组成，类似于关系型数据库中的一行记录，但es的文档是以JSON进行序列化并保存的，每个JSON对象由一个或多个字段组成，字段类型可以是布尔，数值，字符串、二进制、日期等数据类型。
es每个文档都有唯一的id,这个id可以由我们自己指定，也可以由es自动生成。
3、类型
类型是文档的逻辑容器，就像关系型数据库，表格是行的容器。类型中对于字段的定义称为映射，比如name映射为字符串类型。文档是无模式的，它不需要有映射中定义的所有字段。
4、倒排索引
一切设计都是为了提高搜索的性能
倒排索引（Inverted Index）也叫反向索引，有反向索引必有正向索引。通俗地来讲，正向索引是通过key找value，反向索引则是通过value找key。
例如，假设我们有两个文档，每个文档的 content 域包含如下内容：
1、The quick brown fox jumped over the lazy dog
2、Quick brown foxes leap over lazy dogs in summer
为了创建倒排索引，我们首先将每个文档的 content 域拆分成单独的 词（我们称它为 词条 或 tokens ），创建一个包含所有不重复词条的排序列表，然后列出每个词条出现在哪个文档。结果如下所示：
Term Doc_1 Doc_2
-------------------------
Quick | | X
The | X |
brown | X | X
dog | X |
dogs | | X
fox | X |
foxes | | X
in | | X
jumped | X |
lazy | X | X
leap | | X
over | X | X
quick | X |
summer | | X
the | X |
------------------------现在，如果我们想搜索 quick brown ，我们只需要查找包含每个词条的文档：
Term Doc_1 Doc_2
-------------------------
brown | X | X
quick | X |
------------------------
Total | 2 | 1两个文档都匹配，但是第一个文档比第二个匹配度更高。如果我们使用仅计算匹配词条数量的简单 相似性算法 ，那么，我们可以说，对于我们查询的相关性来讲，第一个文档比第二个文档更佳。
但是，我们目前的倒排索引有一些问题：
-
Quick和quick以独立的词条出现，然而用户可能认为它们是相同的词。 -
fox和foxes非常相似, 就像dog和dogs；他们有相同的词根。 -
jumped和leap, 尽管没有相同的词根，但他们的意思很相近。他们是同义词。
使用前面的索引搜索 +Quick +fox 不会得到任何匹配文档。（记住，+ 前缀表明这个词必须存在。）只有同时出现 Quick 和 fox 的文档才满足这个查询条件，但是第一个文档包含 quick fox ，第二个文档包含 Quick foxes 。
我们的用户可以合理的期望两个文档与查询匹配。我们可以做的更好。
如果我们将词条规范为标准模式，那么我们可以找到与用户搜索的词条不完全一致，但具有足够相关性的文档。例如：
-
Quick可以小写化为quick。 -
foxes可以 词干提取 变为词根的格式为fox。类似的，dogs可以为提取为dog。 -
jumped和leap是同义词，可以索引为相同的单词jump。
现在索引看上去像这样：
Term Doc_1 Doc_2
-------------------------
brown | X | X
dog | X | X
fox | X | X
in | | X
jump | X | X
lazy | X | X
over | X | X
quick | X | X
summer | | X
the | X | X
------------------------这还远远不够。我们搜索 +Quick +fox 仍然 会失败，因为在我们的索引中，已经没有 Quick 了。但是，如果我们对搜索的字符串使用与 content 域相同的标准化规则，会变成查询 +quick +fox ，这样两个文档都会匹配！
这非常重要。你只能搜索在索引中出现的词条，所以索引文本和查询字符串必须标准化为相同的格式。
