ElasticSearch 学习笔记
基本概念
术语
- 文档（document）：每条记录就是一个文档，会以 JSON 格式进行存储
- 映射（mapping）：索引中文档字段的约束信息，类似 RDBMS 中的表结构约束（schema）
- 词条（term）：对文档内容分词得到的词语，是索引里面最小的存储和查询单元
- 词典（term dictionary）：由文本集合中出现过的所有词条所组成的集合
- 词条索引（term Index）：为了在词典中快速找到某个词条，需要为词条建立索引。通过压缩算法，词条索引的大小只有所有词条的几十分之一，因此词条索引可以存储在内存中，从而提供更快的查找速度
- 倒排表（posting list）：记录词条出现在哪些文档里，以及出现的位置和频率等信息。倒排表中的每条记录称为一个倒排项（posting）
- 索引（index）：相同类型（文档结构）的文档集合
索引前的文档集合：
索引后的文档集合：
8.
比较
- RDBMS vs ES
- 使用场景：MySQL 擅长于事务类型操作，可以确保数据的安全性和一致性；ES 则擅长于海量数据的检索、分析与计算。
MySQL + ES 组合使用架构：
语法
DDL
类型
注意：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
修改文档
- 全量修改
PUT /索引库名/_doc/文档id
{
"字段1": "值1",
"字段2": {
"子字段1" : "子值1"
}
}
注意：当 文档id 指定的文档不存在时，就是新增文档
- 局部修改
POST /索引库名/_update/文档id
{
"doc": {
"字段2": {
"子字段1" : "子值1"
}
}
}
DSL 查询
语法
全文检索
会先对用户输入的类型进行「分词」，然后去倒排索引库去检索
// 全部查询
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", // <=
}
}
}
}
地理查询
复合查询
打分算法原理
TF刻画了词语w对某篇文档的重要性，IDF刻画了w对整个文档集的重要性。TF与IDF没有必然联系，TF低并不一定伴随着IDF高。实际上我们可以看出来，IDF其实是给TF加了一个权重。
新版 ES 都默认使用 BM25 作为打分算法。
BM25 考虑到了文档长度对于 TF 的影响。在 TF-IDF 中，长文档可能会因为包含更多的词而得到较高的 TF 值。为了消除这种影响，BM25 引入了文档长度归一化，使得长文档和短文档在计算 TF 时能够处于同一水平。BM25 相对 TF-IDF 有哪些优势？
TF-IDF 存在的问题
- 在一个相当长的文档中，像 the 和 and 这样词出现的数量会高得离谱，以致它们的权重被人为放大。
- Bool 查询
搜索结果处理
排序
分页
深分页问题
深分页解决方案：
ES 深分页问题解决方案
search_after 是 ES 5 新引入的一种分页查询机制，其实 原理几乎就是和 scroll 一样，简单总结如下：
- 必须先要 指定排序；
- 必须 从第一页开始；
- 从第一页开始，以后每次都带上 search_after=lastEmittedDocFieldValue 从而为无状态实现一个状态，其实就是把每次固定的 from + size 偏移变成一个确定值 lastEmittedDocFieldValue，而查询则从这个偏移量开始获取 size 个 _doc（每个 shard 获取 size 个，coordinate node 最后汇总 shards * size 个）。
也就是说，无论去到多少页，coordinate node 向其它 node 发送的请求始终就是请求 size 个 docs，是个常量，而不再是 from + size 那样，越往后你要请求的 docs 就越多，而要丢弃的垃圾结果也就越多。也就是说，如果要做非常多页的查询时，最起码 search_after 是一个常量查询延迟和开销。
高亮
注意：ES 默认要求搜索字段与高亮字段一致才会高亮显示。设置 “require_field_match”: false 则可以忽视该规定
倒排索引原理
倒排索引建立的是分词（Term）和文档（Document）集合之间的映射关系，在倒排索引中，数据是面向词（Term）而不是面向文档的。
在数据生成的时候，比如插入一份文档，内容是“小米手机与华为手机”，这个时候通过使用分词器，会将它分解为“小米”、“手机”、“与”、“华为”四个词语，然后可能还会把“与”这个无具体意义的关联词语干掉，最后生成一张倒排表。
每搜索一个单词，就对倒排表进行全局遍历，效率特别低，所以需要对倒排表进行排序，以便采用二分查找等方式提高遍历效率。另一方面，光使用排序还会因磁盘 IO 导致查询速度过慢，若将数据放全部入内存，又会导致内存爆满。所以，在倒排表的基础上，又通过 FST （trie、FSA、FST（转））的形式引入了 term index，它不存储所有的单词，只存储单词前缀，并将其完全放入到内存中，通过字典树找到单词所在的块（单词的大概位置），再在块里进行二分查找，找到对应的单词，再找到单词对应的文档列表。
FST
Lucene的FST（Finite-State Transducers）是一种高效的数据结构（变种的trie树，trie树只共享了前缀，而 FST 既共享前缀也共享后缀。），是Lucene用来构建和管理自动机的一部分，它具有高度的压缩性和空间效率，能够帮助Lucene提高搜索和排序的效率。在FST中，任何字符串都可以看作一个有限状态机，每个状态代表着字符串的某个前缀。FST基于原理：序列化哈希值，通过将无序键序列化到字节数组中，强制所有的比较和排序在序列化字节上进行。
聚合
自动补全
type: “completion”
数据同步
场景
- ElasticSearch 结合工具 LogStash、 Kibana （ELK）进行日志分析、实时监控。
问题
慢查
- 使用 search 查询时，指定的查询条件不够精准，导致查询范围过大
- 返回的 id 过多，在协调节点做排序截断时，会产生比较大的 CPU 压力
- 返回的 id 过多，会导致第二步通过 id 请求数据 node 获取文档详细时，使得数据节点以及协调节点产生大量的 IO 操作，以及 CPU 消耗
seaerch 查询
GET /my-index/_search
- Client 将请求发送到任意节点 node，该 node 节点成为协调节点（coordinating node）
- 协调节点进行分词等操作后，去查询所有的数据节点 shard （primary shard 和 replica shard 选择一个）
- 所有数据节点 shard 将满足条件的数据 id、排序字段等信息返回给协调节点
- 协调节点重新进行排序，再通过截取数据后获取到真正需要返回的数据 id
- 协调节点再次请求对应的数据节点 shard （此时有 id 了，可以直接定位到对应 shard），获取数据文档
- 协调节点从数据节点获取到全量数据文档后将其返回给 Client
ID 查询
GET my-index/_doc/0
- Client 将请求发送到任意节点 node，该 node 节点就是协调节点（coordinating node）。
- 协调节点对 id 进行路由，从而判断该数据在哪个 shard。
- 从 primary shard 和 replica shard 随机选择一个，请求获取 doc。
- 接收请求的节点会将数据返回给协调节点，协调节点会将数据返回给 Client
其它
- ElasticSearch 高手之路：ES 查询语法文档
- Elasticsearch 倒排索引原理
- 为什么 ElasticSearch 比 MySQL 更适合复杂条件搜索
思考
ElaticSearch 为什么快
ES vs MySQL
Elasticsearch 比 MySQL 快的原因
- 基于分词后的全文检索：例如 select * from test where name like ‘%张三%’，对于 mysql来说，因为索引失效，会进行全表检索；对 ES 而言，分词后每个字都可以利用 FST 高速找到倒排索引的位置，并迅速获取文档 id 列表，大大的提升了性能，减少了磁盘IO。
- 精确检索：有时 MySQL 可能更快一些，比如当 MySQL 通过索引覆盖，无需回表查询时；ES 始终会通过 FST 找到倒排索引的位置获取文档 id 列表，再根据文档id获取文档并根据相关度进行排序。另外 ES 还有个优势，分布式架构使其在进行大量数据搜索时，可以通过分片降低检索规模，并且通过并行检索提升效率，使用 filter 操作时，更是可以直接跳过检索直接走缓存。