BE.JAVA-Elasticsearch笔记-技术揭秘 - HelloWorld开发者社区

海量数据系统架构的技术选型

https://db-engines.com/en/ran...
BE.JAVA-Elasticsearch笔记-技术揭秘

全文搜索引擎（NLP,爬虫，如百度）
垂直搜索引擎（电商，OA，站内搜索，视频网站）

搜索引擎具备要求：

查询速度快(高效的压缩算法，快速的编码和解码)
结果准确（BM25,TF-IDF）
检索结果丰富（召回率）

上手Elasticsearch

环境安装

操作系统|JDK|自身兼容性
jdk(8|11|14) 兼容性
elastic.co/cn/downloads 兼容性

Elasticsearch目录结构

bin：可执行脚本文件，包括启动es服务、插件管理、函数命令
config：配置文件目录，es配置、角色配置、jvm配置等
lib：es所依赖的java库
data: 默认的数据存放目录。包含节点、分片、索引、文档的所有数据，生产环境要求必须修改。
logs: 默认日志文件存储路径，生产环境务必修改。
modules: 包含所有es模块，如Cluster、Discovery、Indices等
plugins：已经安装的插件目录
jdk/jdk.app 7.0以后才有，自带的java环境

启动

启动 bin/elasticsearch ，打开 localhost:9200

多节点方式

多项目单节点

单项目多节点

elasticserach -E path.data=data1 -Ee path.logs=log1 -E node.name=node1 -E cluster.name=msb_teach
elasticserach -E path.data=data1 -Ee path.logs=log1 -E node.name=node1 -E cluster.name=msb_teach

集群健康值

健康值状态
- green 所有primary和replica均为active,集群健康
- yellow，至少一个replica不可用，但所有primary均active，数据认可保证完整
- red:至少一个primary 不可用，集群不可用
健康值检查
- _cat/health
- _cluster/health

kibana

验证服务启动成功 localhost:5601
配置es服务地址elasticsearch.host:["http://localhost:9201"](kibana.yml)
命令行关闭kibana:
- 关闭窗口
- ps -ef|grep 5601 或 ps -ef|grep kibana 或 lsof -i:5601
- kill -9 pid
关于“kibana server is not ready yet” 问题原因及解决办法
- kibana和Elasticsearch版本不兼容（保持版本一致）
- Elasticsearch的服务地址和Kibana中配置的elasticsearch.hosts不同（elasticsearch.yml中配置）
- Elasticsearch中禁止跨域访问（elasticsearch.yml中配置允许跨域）
- 服务器开启了防火墙（关闭防火墙或修改服务器安全策略）
- Elasticsearch所在磁盘剩余空间不足90%(清理磁盘空间，配置监控和报警)

透过现象看本质：带你看穿“索引”本质

索引

帮助快速检索
以数据结构为载体
以文件形式落地

数据库的组成结构
BE.JAVA-Elasticsearch笔记-技术揭秘

为什么B+Trees(Mysql)不适合大数据检索

mysql，十万级，无索引：0.295s
mysql, 百万级，无索引: 3.365s
mysql, 百万级，全文索引：1.033s
mysql, 千万级，全文索引：10.038s
es, 千万，.8s

mysql的索引结构 B-Trees 可视化
BE.JAVA-Elasticsearch笔记-技术揭秘

倒排索引完全解读

倒排索引数据结构
BE.JAVA-Elasticsearch笔记-技术揭秘
倒排索引核心算法

倒排表的压缩算法
- FOR:Frame Of Reference
- RBM:RoaringBitMap
词项索引的检索原理
- FST:Finit state Transducers
  http://examples.mikemccandles...
  
  FST在lucene的实现原理

正排索引倒排索引辨析：
首先要理解两种数据结构的概念doc values是文档到词项的映射，inverted是词项到文档id的映射。从原理上讲，先说倒排索引为什么不适合聚合，你无法通过倒排索引确定doc的总数量，并且因为默认会执行analysis，即使聚合，结果也可能不准确，所以你还要创建not_analyzed字段，徒增磁盘占用。举个最简单的例子，加入这是一个商品表，每个商品都有若干标，我们执行了以下查询

query:{
  match:{
    tags:"性价比"
  }，
  aggs:{
    tag_terms:{
      terms:{
        field:"tags.keyword"
      }
    }
  }
}

这段聚合查询的意思查询包含“性价比” 这个标签商品的所有标签

在执行agg的时候
我们使用倒排索引，那么语音是这样的的：在倒排索引中扫描逐个term，看看这个term对应的倒排表中对应的doc的标签，是否包含“性价比”，如果包含，则记录，由于我们不确定下面一个term是否符合条件，所以我们就要一个个的判断，就造成了扫表。

如果使用正排索引，而正排索引指的是，doc中包含了哪些词项，也就是当前docid=>当前字段所包含的所有词项的映射，我们要查找的是符合条件的doc中所有的标签，那么我们直接更具key(docid)去拿values(all terms)就可以了，就不用扫表。

所以聚合查询使用正排索引效率高的本质是两种数据结构的区别，和结合倒排索引没有关系，结合倒排索引只是预先进行了数据筛选。以上是正排索引在原理上对聚合查询友好的原因。

这两种数据结构在数据压缩上的不同：
doc values是一种序列化的列式存储结构，其中values也包含了词频数据。而这种结构是非常有利于数据压缩的（FOR和RBM压缩算法）因为Lucence底层读取文件的方式是局域mmap的，原理上是从磁盘读取到OS cache里面进行解码的，使用正排索引的数据结构，由于其列式存储的数据和posting list 一样可以被高效压缩，所以这种方式极大的增加了从磁盘中读取的速度，因为体积小了嘛，然后把数据在OS Cache中解码，这样的话读取速度就非常高，doc values更适合于聚合的原因。

举个通俗易懂的例子
有二十个学生报名学习辅导班，每个学生可以报多个班，每个班都有一个班主任

正排索引就是班主任，也就是每个班包含哪些学生

倒排索引就是，每个学生都报了哪些班

现在我们要知道音乐辅导班和美术辅导班都包含了哪些学生，问班主任问2次就行，如果我们问学生，就要每个学生都问一遍，问他你是否报了音乐和美术辅导班，如果你不问玩每个学生，你永远不知道你没有问过的学生是不是在音乐班和美术班里

在这个例子里，班主任相当于正排索引，每个doc就是一个班级，每个doc包含若干词项，每个词项就好比是一个学生。
班主任知道每个班级有哪些学生，也就是每个doc包含哪些词项，学生只知道自己属于哪些班，相当于哪些班级（doc）包含了这个词项。