Elasticsearch - Elasticsearch核心概念

Posted 2022-09-09 MinggeQingchun

阅读本文前可先参考

https://blog.csdn.net/MinggeQingchun/article/details/126618387

Elasticsearch 是面向文档型数据库，一条数据在这里就是一个文档

Elasticsearch存储文档数据和关系型数据库 mysql对应关系        

Elasticsearch	Mysql
index（索引）	DataBase（数据库）
type（类型；6.0版本之后Type就被废弃）	Table（表）
Document（文档）	Row（行）
Field（字段）	Column（列）
Mapping（映射）	每个字段的类型约束，长度约束
索引可自由创建，包括空索引	index
Query DLS	SQL语句
GET：http://localhost:port/index	SELECT *FROM TABLE
PUT：http://localhost:port/index/type/文档id…	UPDATA TABLE SET

ES 里的 Index 可以看做一个库，Types 相当于表，Documents 则相当于表的行

ES中Types 的概念已经被逐渐弱化，Elasticsearch 6.X 中，一个 index 下已经只能包含一个type，Elasticsearch 7.X 中, Type 的概念已经被删除

一、Elasticsearch核心概念

1、索引 Index

索引是ES中最大的数据单元，相当于关系型数据库中 库的概念

一个索引就是一个拥有几分相似特征的文档的集合。一个索引由一个名字来标识（必须全部是小写字母），并且当我们要对这个索引中的文档进行索引、搜索、更新和删除的时候，都要使用到这个名字

一个文档 相当于MySQL中一行数据，如果按照关系型数据库中的对应关系，还应该有表的概念

ES中没有表的概念，这是ES和数据库的一个区别，在我们建立索引之后，可以直接往 索引 中写入文档

能搜索的数据必须索引，好处是可以提高查询速度，比如：新华字典前面的目录就是索引的意思目录可以提高查询速度

Elasticsearch 索引的精髓：一切设计都是为了提高搜索的性能

注：

在6.0版本之前，ES中有Type的概念，可以理解成关系型数据库中的表，但是官方说这是一个设计上的失误，所以在6.0版本之后Type就被废弃了

2、文档 Document

文档 在ES中相当于传统数据库中的行的概念，ES中的数据都以JSON的形式来表示，在MySQL中插入一行数据和ES中插入一个JSON文档是一个意思

文档以 JSON（Javascript Object Notation）格式来表示，而 JSON 是一个到处存在的互联网数据交互格式

下面的JSON数据表示，一个包含3个字段的文档

    "name":"zhangsan",
    "age":18,
    "sex":1

3、字段 Field

字段在ES中可以理解为JSON数据的键，类似mysql中的Column（列）

下面的JSON数据中，name 就是一个字段

    "name":"zhangsan"

4、映射Mapping

映射 是对文档中每个字段的类型进行定义，每一种数据类型都有对应的使用场景。如：string的数据会被作为全文本来处理，这种数据类型适合需要搜索的场景

有些数据类型，不需要对它进行搜索，相反需要对它做聚合运算，keyword、integer 数据类型就更合适

每个文档都有映射，但在大多数使用场景中，并不需要显示的创建映射，因为ES中实现了动态映射。我们在索引中写入一个下面的JSON文档，在动态映射的作用下，name会映射成text类型，age会映射成long类型

    "name":"zhangsan",
    "age":18

既然有动态映射，也可以自定义映射，在深度使用中，需要对数据类型进行精确的控制，以达到我们实际场景的要求，ES可能不知道我们需要数据类型，这种情况下我们可以使用自定义映射。通过映射API，我们可以方便的创建、修改、查看、删除映射

5、分片 Shards

索引是ES中最大的数据存储单元，我们可以往索引中不断写入文档，到了一定数量级，索引文件就会占满整个服务器的磁盘，磁盘容量只是其中一个问题，索引文件变的大，会严重降低搜索的效率

分片就是用来解决这些问题的，简单来讲，分片就是把单索引文件分成多份存储，且这些索引的分片可以分部在不同的机器上。假设单台机器磁盘容量1TB，现在需要存放5TB的索引数据，那就可以把5TB索引分成10份，分别存放到10台机器上每份500G，这就是所谓的分片

6、副本 Replicas

一个索引可以分成多个分片，分布在不同的机器上。假设10台机器中有一台发生故障了，在这台机器上的分片也就没了，就会导致索引损坏。

为了解决索引高可用的问题，ES引入了副本机制，这里的副本指的就是分片的副本，分片的原始数据称为主分片，主分片和副本会放在不同的机器上，即使有一个分片丢失了，另外的分片可以作为后备。如果主分片的机器挂掉了，其中一个副本分片就会升级成主分片。同时，因为副本分片的工作和主分片是一样的，所以增加副本的数量可以提升查询性能

7、词项 term

在传统关系型数据库中，假如想要存储一篇几千字的文本，可以通过text直接存进去，和存储其它类型的数据没什么不同。存储虽然很方便，但是要对文本中的关键词进行搜索，查询速度非常慢，尤其是在大数据量的时候

在ES中存储这篇文章，它不会直接存进去，而是先把大文本切割成很多个小的词，这些词就是我们所说的词项，它是ES搜索的最小单位，每个查询都是按词项搜索的

ES使用了倒排索引来存储数据。在关系型数据中，最好的方式是用主键id来查询，可以快速定位到文章内容，而倒排索引则相反，它建立的是词项和文章id的对应关系，索引它更适合文本搜索

倒排索引底层原理决定了ES天生适合做全文本搜索

8、配置 Setting

Settings是对集群中索引的定义信息，比如一个索引默认的分片数、副本数等

9、分析器 Analyzers

ES中不会把一篇文章直接存入磁盘，在存储时它会先对文本进行分析，分析器的就是用来分析这些文本，中间包括过滤、分词等过程，经过分析处理后再存储到磁盘。

分析器由3部分组成，分别是字符过滤器、分词器和词项处理器。

字符过滤器把原始文本作为字符流来处理，它可以过滤一些特殊字符、html标签等

分词器是分析器的核心部分，它负责把大文本分割成多个词项，比如文本 "Hello,World!"，可以被分割成 2个词项，[Hello, World!]

词项处理器接受词项流，它可以移除一些不需要的词

ES提供了多种分析器，默认使用标准的分析器，能满足大部分的需求，实在不行也可以使用自定义的分析器，除了分析器以外，分词器、字符过滤器等在ES中也提供了多种选择

10、节点 Node & 集群 Cluster

节点就是一个ElasticSearch进程，当我们启动一个ElasticSearch程序，就启动了一个节点，很多个节点集合在一起就成了集群，即使只有单个节点，也可以把它看成只有单个节点的集群

节点也分多种类型，主要分为 主节点、数据节点、协调节点和Ingest节点，每个节点都有各自的职责，如果集群中只有单个节点，那这个节点会扮演多个节点的角色，它需要独自完成整个搜索和索引的过程

集群对外提供服务时，相当于一个整体，集群中的每个节点都可以处理Http请求，每个请求经过一系列内部转发，处理完成后返回数据给外部客户端。集群内部每个节点之间通信使用Java API ，它的底层是基于TCP的自定义协议，而对于外部客户端，ES使用的是Restful风格的Http协议

在Elasticsearch集群中，节点的状态有Green、Yellow、Red三种

（1）Green，绿色，表示节点运行状态为健康状态。所有主分片和副本分片都可以正常工作，集群100%健康

（2）Yellow，黄色，表示节点的运行状态为预警状态。所有的主分片都可以正常工作，但是至少有一个副本分片是不能正常工作的。此时集群仍然可以正常工作，但集群的高可用性在某种程度上被弱化

（3）Red，红色，表示集群无法正常工作。此时，集群中至少有一个分片的主分片及他的全部副本都不可正常工作。虽然集群的查询操作还可以进行，但是也只能返回部分数据（其他正常分片的数据可以被正常返回），而分配到这个有问题分片的写入请求会报错，最终造成数据丢失

查看创建的集群健康状态

GET _cluster/health?pretty
或者使用
curl "http://10.182.61.116:9200/_cluster/health?pretty"

参考文章

Elasticsearch使用

二、正排索引，倒排索引

Elasticsearch 使用一种称为倒排索引的结构，它适用于快速的全文搜索

1、正向索引（forward index）

正向索引（正排索引），就是搜索引擎会将待搜索的文件都对应一个文件 ID，搜索时将这个ID 和搜索关键字进行对应，形成 K-V 对，然后对关键字进行统计计数

正排索引也称为"前向索引"，这种组织方法在建立索引的时候结构比较简单，建立比较方便且易于维护；因为索引是基于文档建立的，若是有新的文档加入，直接为该文档建立一个新的索引块，挂接在原来索引文件的后面。若是有文档删除，则直接找到该文档号文档对应的索引信息，将其直接删除。

它适合根据文档ID来查询对应的内容。但是在查询一个keyword在哪些文档里包含的时候需对所有的文档进行扫描以确保没有遗漏，这样就使得检索时间大大延长，检索效率低下

“文档1”的ID > 单词1：出现次数，出现位置列表；单词2：出现次数，出现位置列表；......

“文档2”的ID > 此文档出现的关键词列表
 

• 优点：工作原理非常的简单
• 缺点：检索效率太低，只能在一起简单的场景下使用

互联网上收录在搜索引擎中的文档的数目是个天文数字，这样的索引结构根本无法满足 实时返回排名结果的要求。所以，搜索引擎会将正向索引重新构建为倒排索引，即把文件ID对应到关键词的映射转换为关键词到文件ID的映射，每个关键词都对应着一系列的文件， 这些文件中都出现这个关键词。

2、倒排索引（反向索引；inverted index）

单词编号(Word ID)：与文档编号类似，搜索引擎内部以唯一的编号来表征某个单词，单词编号可以作为某个单词的唯一表征

单词词典(Lexicon)：搜索引擎的通常索引单位是单词，单词词典是由文档集合中出现过的所有单词构成的字符串集合，单词词典内每条索引项记载单词本身的一些信息以及指向“倒排列表”的指针

倒排列表(PostingList)：倒排列表记载了出现过某个单词的所有文档的文档列表及单词在该文档中出现的位置信息，每条记录称为一个倒排项(Posting)。根据倒排列表，即可获知哪些文档包含某个单词

倒排文件(Inverted File)：所有单词的倒排列表往往顺序地存储在磁盘的某个文件里，这个文件即被称之为倒排文件，倒排文件是存储倒排索引的物理文件

• 单词ID：记录每个单词的单词编号；
• 单词：对应的单词；
• 文档频率：代表文档集合中有多少个文档包含某个单词
• 倒排列表：包含单词ID及其他必要信息
• DocId：单词出现的文档id
• TF：单词在某个文档中出现的次数
• POS：单词在文档中出现的位置

根据切分的关键词表去找含有这个关键词的文档ID

 倒排索引的结构如下：

“关键词1”：“文档1”的ID，“文档2”的ID，……

“关键词2”：带有此关键词的文档ID列表