ElasticSearch 学习笔记

基本概念

术语

  1. 文档(document):每条记录就是一个文档,会以 JSON 格式进行存储
    ElasticSearch 学习笔记_第1张图片
  2. 映射(mapping):索引中文档字段的约束信息,类似 RDBMS 中的表结构约束(schema)
  3. 词条(term):对文档内容分词得到的词语,是索引里面最小的存储和查询单元
  4. 词典(term dictionary):由文本集合中出现过的所有词条所组成的集合
  5. 词条索引(term Index):为了在词典中快速找到某个词条,需要为词条建立索引。通过压缩算法,词条索引的大小只有所有词条的几十分之一,因此词条索引可以存储在内存中,从而提供更快的查找速度
  6. 倒排表(posting list):记录词条出现在哪些文档里,以及出现的位置和频率等信息。倒排表中的每条记录称为一个倒排项(posting)
  7. 索引(index):相同类型(文档结构)的文档集合

索引前的文档集合:
ElasticSearch 学习笔记_第2张图片
索引后的文档集合:
ElasticSearch 学习笔记_第3张图片
8.

比较

  1. RDBMS vs ES
    ElasticSearch 学习笔记_第4张图片
  2. 使用场景:MySQL 擅长于事务类型操作,可以确保数据的安全性和一致性;ES 则擅长于海量数据的检索、分析与计算。

MySQL + ES 组合使用架构:
ElasticSearch 学习笔记_第5张图片

语法

DDL
类型

ElasticSearch 学习笔记_第6张图片
注意:index 默认为 true,即 ES 会默认给设置的字段设置倒排索引,如无需设置倒排索引需要手动设置为 false

语法示例
PUT /索引库名称
{
	"mappings": { // 定义 schema
		"properties": { // schema 的具体字段极其类型说明
			"字段1": {
				"type": "text"
				"analyzer": "ik_smart"
			},
			"字段2": {
				"type": "keyword",
				"index": false
			},
			"字段3": {
				"type": "object",
				"properties": { // 嵌套字段
					"子字段1": {
						"type": integer
						"index": false
					}
				}
			}
		}
	}
}

GET /索引库名

DELETE /索引库名

// ES 禁止修改索引库已有字段,只允许新增字段
PUT /索引库名/_mapping
{
	"properties": {
		"新字段名": {
			"type": "long"
			"index": false
		}
	}
}
DML
新增文档
POST /索引库名/_doc/文档id
{
	"字段1": "值1",
	"字段2": {
		"子字段1" : "子值1"
	}
}
查询/删除文档
GET /索引库名/_doc/文档id

DELETE /索引库名/_doc/文档id
修改文档
  1. 全量修改
PUT /索引库名/_doc/文档id
{
	"字段1": "值1",
	"字段2": {
		"子字段1" : "子值1"
	}
}

注意:当 文档id 指定的文档不存在时,就是新增文档

  1. 局部修改
POST /索引库名/_update/文档id
{
	"doc": {
		"字段2": {
			"子字段1" : "子值1"
		}
	}
}
DSL 查询

ElasticSearch 学习笔记_第7张图片

语法
全文检索

会先对用户输入的类型进行「分词」,然后去倒排索引库去检索

// 全部查询
GET /索引库名/_search
{
	"query": {
		"match_all": {}
	}
}

// match 查询
GET /索引库名/_search
{
	"query": {
		"match": {
			"字段名": "字段值"
		}
	}
}

// multi_match 查询,注意参与查询字段越多,查询性能越差
GET /索引库名/_search
{
	"query": {
		"multi_match": {
			"query": "字段值"
			"fields": ["字段名1", "字段名2"]
		}
	}
}
精确查询

直接使用提供的值进行匹配查询,而不会先进行分词操作

// term 查询
GET /索引库名/_search
{
	"query": {
		"term": {
			"字段名": {
				"value": "字段值"
			}
		}
	}
}

// range 查询
GET /索引库名/_search
{
	"query": {
		"range": {
			"字段名": {
				"gte": "字段值1", // >=
				"lte": "字段值2", // <=
			}
		}
	}
}
地理查询
复合查询

ElasticSearch 学习笔记_第8张图片
打分算法原理

TF刻画了词语w对某篇文档的重要性,IDF刻画了w对整个文档集的重要性。TF与IDF没有必然联系,TF低并不一定伴随着IDF高。实际上我们可以看出来,IDF其实是给TF加了一个权重。

ElasticSearch 学习笔记_第9张图片
新版 ES 都默认使用 BM25 作为打分算法。

BM25 考虑到了文档长度对于 TF 的影响。在 TF-IDF 中,长文档可能会因为包含更多的词而得到较高的 TF 值。为了消除这种影响,BM25 引入了文档长度归一化,使得长文档和短文档在计算 TF 时能够处于同一水平。BM25 相对 TF-IDF 有哪些优势?

TF-IDF 存在的问题

  1. 在一个相当长的文档中,像 the 和 and 这样词出现的数量会高得离谱,以致它们的权重被人为放大。

ElasticSearch 学习笔记_第10张图片

  • Bool 查询
    ElasticSearch 学习笔记_第11张图片
搜索结果处理
排序

ElasticSearch 学习笔记_第12张图片

分页

ElasticSearch 学习笔记_第13张图片
深分页问题
ElasticSearch 学习笔记_第14张图片
深分页解决方案:
ElasticSearch 学习笔记_第15张图片
ES 深分页问题解决方案

search_after 是 ES 5 新引入的一种分页查询机制,其实 原理几乎就是和 scroll 一样,简单总结如下:

  1. 必须先要 指定排序;
  2. 必须 从第一页开始;
  3. 从第一页开始,以后每次都带上 search_after=lastEmittedDocFieldValue 从而为无状态实现一个状态,其实就是把每次固定的 from + size 偏移变成一个确定值 lastEmittedDocFieldValue,而查询则从这个偏移量开始获取 size 个 _doc(每个 shard 获取 size 个,coordinate node 最后汇总 shards * size 个)。

也就是说,无论去到多少页,coordinate node 向其它 node 发送的请求始终就是请求 size 个 docs,是个常量,而不再是 from + size 那样,越往后你要请求的 docs 就越多,而要丢弃的垃圾结果也就越多。也就是说,如果要做非常多页的查询时,最起码 search_after 是一个常量查询延迟和开销。

高亮

ElasticSearch 学习笔记_第16张图片
注意:ES 默认要求搜索字段与高亮字段一致才会高亮显示。设置 “require_field_match”: false 则可以忽视该规定

倒排索引原理

倒排索引建立的是分词(Term)和文档(Document)集合之间的映射关系,在倒排索引中,数据是面向词(Term)而不是面向文档的。

在数据生成的时候,比如插入一份文档,内容是“小米手机与华为手机”,这个时候通过使用分词器,会将它分解为“小米”、“手机”、“与”、“华为”四个词语,然后可能还会把“与”这个无具体意义的关联词语干掉,最后生成一张倒排表。
ElasticSearch 学习笔记_第17张图片
每搜索一个单词,就对倒排表进行全局遍历,效率特别低,所以需要对倒排表进行排序,以便采用二分查找等方式提高遍历效率。另一方面,光使用排序还会因磁盘 IO 导致查询速度过慢,若将数据放全部入内存,又会导致内存爆满。所以,在倒排表的基础上,又通过 FST (trie、FSA、FST(转))的形式引入了 term index,它不存储所有的单词,只存储单词前缀,并将其完全放入到内存中,通过字典树找到单词所在的块(单词的大概位置),再在块里进行二分查找,找到对应的单词,再找到单词对应的文档列表。
ElasticSearch 学习笔记_第18张图片

FST

Lucene的FST(Finite-State Transducers)是一种高效的数据结构(变种的trie树,trie树只共享了前缀,而 FST 既共享前缀也共享后缀。),是Lucene用来构建和管理自动机的一部分,它具有高度的压缩性和空间效率,能够帮助Lucene提高搜索和排序的效率。在FST中,任何字符串都可以看作一个有限状态机,每个状态代表着字符串的某个前缀。FST基于原理:序列化哈希值,通过将无序键序列化到字节数组中,强制所有的比较和排序在序列化字节上进行。

聚合

ElasticSearch 学习笔记_第19张图片

自动补全

type: “completion”

数据同步

场景

  1. ElasticSearch 结合工具 LogStash、 Kibana (ELK)进行日志分析、实时监控。

问题

慢查

  1. 使用 search 查询时,指定的查询条件不够精准,导致查询范围过大
  • 返回的 id 过多,在协调节点做排序截断时,会产生比较大的 CPU 压力
  • 返回的 id 过多,会导致第二步通过 id 请求数据 node 获取文档详细时,使得数据节点以及协调节点产生大量的 IO 操作,以及 CPU 消耗

seaerch 查询

GET /my-index/_search

ElasticSearch 学习笔记_第20张图片

  1. Client 将请求发送到任意节点 node,该 node 节点成为协调节点(coordinating node)
  2. 协调节点进行分词等操作后,去查询所有的数据节点 shard (primary shard 和 replica shard 选择一个)
  3. 所有数据节点 shard 将满足条件的数据 id、排序字段等信息返回给协调节点
  4. 协调节点重新进行排序,再通过截取数据后获取到真正需要返回的数据 id
  5. 协调节点再次请求对应的数据节点 shard (此时有 id 了,可以直接定位到对应 shard),获取数据文档
  6. 协调节点从数据节点获取到全量数据文档后将其返回给 Client

ID 查询

GET my-index/_doc/0

ElasticSearch 学习笔记_第21张图片

  1. Client 将请求发送到任意节点 node,该 node 节点就是协调节点(coordinating node)。
  2. 协调节点对 id 进行路由,从而判断该数据在哪个 shard。
  3. 从 primary shard 和 replica shard 随机选择一个,请求获取 doc。
  4. 接收请求的节点会将数据返回给协调节点,协调节点会将数据返回给 Client

其它

  1. ElasticSearch 高手之路:ES 查询语法文档
  2. Elasticsearch 倒排索引原理
  3. 为什么 ElasticSearch 比 MySQL 更适合复杂条件搜索

思考

ElaticSearch 为什么快

ES vs MySQL

Elasticsearch 比 MySQL 快的原因

  1. 基于分词后的全文检索:例如 select * from test where name like ‘%张三%’,对于 mysql来说,因为索引失效,会进行全表检索;对 ES 而言,分词后每个字都可以利用 FST 高速找到倒排索引的位置,并迅速获取文档 id 列表,大大的提升了性能,减少了磁盘IO。
  2. 精确检索:有时 MySQL 可能更快一些,比如当 MySQL 通过索引覆盖,无需回表查询时;ES 始终会通过 FST 找到倒排索引的位置获取文档 id 列表,再根据文档id获取文档并根据相关度进行排序。另外 ES 还有个优势,分布式架构使其在进行大量数据搜索时,可以通过分片降低检索规模,并且通过并行检索提升效率,使用 filter 操作时,更是可以直接跳过检索直接走缓存。

你可能感兴趣的:(数据库,elasticsearch)