目录
1 基本概念
1.1 检索概念
Es 索引、类型、文档、Field 分别怎么理解？这些概念背后的物理含义。
| 名称 | 概念 | 对应关系型数据库概念 | 说明 | 备注 |
|---|---|---|---|---|
| Cluster | 集群 |
| 一个或多个节点的集合，通过启动时指定名字作为唯一标识，默认cluster-state |
|
| node | 节点 |
| 启动的ES的单个实例，保存数据并具有索引和搜索的能力，通过名字唯一标识，默认node-n |
|
| index | 索引 | Database | 具有相似特点的文档的集合，可以对应为关系型数据库中的数据库，通过名字在集群内唯一标识 |
|
| type | 文档类别 | Table | 索引内部的逻辑分类，可以对应为Mysql中的表，ES 6.x 版本中，一个索引只允许一个type，不再支持多个type。7.x版本中，type将废弃。 |
|
| document | 文档 | Row | 构成索引的最小单元，属于一个索引的某个类别，从属关系为： Index -> Type -> Document，通过id 在Type 内唯一标识。 也是构建索引和查询的最小单位 |
|
| field | 字段 | Column | 构成文档的单元 | 比如对于一篇，论文，作者、标题、正文、发表时间 |
| mapping | 索引映射（约束） | Schema | 用来约束文档字段的类型，可以理解为索引内部结构。类似数据库中的表定义。核心数据类型： 字符串 text, 字符串：keyword 数值型、布尔型、日期型、范围型 | http://laijianfeng.org/2018/08/Elasticsearch-6-x-Mapping%E8%AE%BE%E7%BD%AE/ |
| shard | 分片 |
| 将索引分为多个块，每块叫做一个分片。索引定义时需要指定分片数且不能更改，默认一个索引有5个分片，每个分片都是一个功能完整的Index，分片带来规模上（数据水平切分）和性能上（并行执行）的提升，是ES数据存储的最小单位 |
|
| replicas | 分片的备份 |
| 每个分片默认一个备份分片，它可以提升节点的可用性，同时能够提升搜索时的并发性能（搜索可以在全部分片上并行执行） |
|
2 Lucene
2.1 简介
2.1.1 Lucene基本流程
2.1.2 Lucene特性说明
非实时，从建索引到可以搜索中间有一个时间延迟，而当前的“近实时”(Lucene Near Real Time search)搜索方案的可扩展性有待进一步完善
非实时，从建索引到可以搜索中间有一个时间延迟？？？这个时间间隔具体在干什么？ 为什么Lucene不实时？
Es采用了近实时方案，Es怎么解决Lucene的那个时间间隔的问题？
Es的解决方式是引入了一个FileSystemCache，在内存中生成索引之后，如果写到磁盘比较慢，但是如果先写到FileSystemCache中，速度非常快，生成到FileSystemCahce就可以使用索引了，后续的问题再交由FileSystemCache中。
[Lucene版本变迁] https://blog.csdn.net/jiangchao858/article/details/78897818
2.2 基本概念及操作
2.2.1 检索建模
文档、Filed、term
类关系图
从上述类关系图就可以看出来，Document只是一个Field的容器，并没有格式化的scheme，即不同的Document可以有不同名称的Field。
构建和查询的最小单元：文档是构建索引的最小单元，Field是索引查询的最小单元。
构建索引的时候
indexWriter.addDocument(doc);从上述代码可以看出doc是构建索引的单元；查询的时候是指定一个索引目录，查询的过程就是在这个查询目录下进行，查询的时候可以指定在某个Field下查询，所以查询的最小单元是Field。
不同Filed之间的区别：
Field StringField和TextField的区别,是否tokenized。简而言之，是否作为一个整体去索引。
2.2.2 创建索引
示意图：
创建方式：
创建有三种，通过IndexWriterConfig.OpenMode进行指定，分别是
-
CREATE：创建一个新的索引或者覆写已经存在的索引
-
APPEND：打开一个已经存在的索引
-
CREATE_OR_APPEND：如果不存在则创建新的索引，如果存在则追加索引
2.2.3 更新索引
先删除再新建；注意：只可根据索引的字段进行更新。
2.3 Lucene底层数据结构及原理
DocId的编码、term的存储
2.3.1 term存储
原始数据怎么高效存储？
倒排表怎么高效存储？ FST (从Lucene4开始，从Lucene3开始，在3及其以前是使用跳表，但是跳表对模糊查询支持不好，故改成了跳表)
倒排表的形式决定了key大部分的前缀或者后缀是可以高效利用的。
采用这种是为了加载到内存中，如果不能加载到内存中，怎么办？
2.2.3
通过FST找对对应的docIds(docId都是有序集合)之后，如何并集、交集、差集。
交集：
[有序数组求交集方法] http://www.6aiq.com/article/1559927141249?p=1&m=0
Lucene5开始使用了bitMap来求交集；bitMap的使用得先判定使用场景。
2.4 Lucene的评分机制
3 ElasticSearch
3.1 定位及竞品对比
| 对比项 | 优点 | 缺点 |
|---|---|---|
| Es |
| Elasticsearch 是计算密集型的。官方建议 运行 ES 的机器最好有 64 GB 的内存，强烈反对在低于 8 GB 内存的机器上运行它。Elasticsearch 是一个 内存中 数据库，这样使它的查询速度非常快，但这也非常占用系统内存。在生产系统中使用时，他们强烈建议在一个集群中运行多个 Elasticsearch 节点，以实现高可用、自动分区和一个节点失败时的数据冗余。 |
| Solr |
|
|
| 总结 | Solr 利用 Zookeeper 进行分布式管理，而 Elasticsearch 自身带有分布式协调管理功能; Solr 在传统的搜索应用中表现好于 Elasticsearch，但在处理实时搜索应用时效率明显低于 Elasticsearch。总之，Solr 是传统搜索应用的有力解决方案，但 Elasticsearch 更适用于新兴的实时搜索应用。 Es耗资源其实不算一种缺点，其实更应该算是一个特性。
| |
3.2 分布式架构设计
在3.1节中，我们也提到Es是自己实现了分布式框架。具体来说，分为两块
-
节点发现 --> Zen Discovery(基于gossip协议)
-
一致性算法 --> 自行实现了Raft协议
这两块其实和Consul非常类似，可以参考
3.2.1 Zen Discovery 模块
Es基于Gossip协议来实现了节点发现功能，该模块称之为Zen Discovery模块。
3.2.2 分布式架构
主从架构 or p2p架构
经常遇到说Es是p2p的对等架构，也有不少说Es是主从架构的。那么Es到底是主从架构还是P2P架构了？其实这两种说法都对，只是分别是从不同的角度来描述Es的架构。
架构图：
详细说明：
从分布式系统的角度来说，Es与其他分布式不一样的是Es是p2p架构。一般的分布式系统，都是采用主从架构，master用来接受请求，并做请求的解析、任务的划分，子任务结果的收集及聚合汇总操作(worker一般仅仅完成计算任务)。
当然主从架构不一定是分布式计算系统，在普通的集群中，也是广泛使用主从架构
但是Es的任一节点都可以做请求解析，任务划分及调度、汇总聚合这些主节点的操作。从这个角度来说，Es是P2P架构。
什么使用p2p架构，为了解决单点故障问题？几台Master组成一个集群，也能解决单点故障。
在Es的语境中也有master的概念，诸多Es节点会选出一个Master(等同于Leader)，当一个节点被选举成为 主 节点时， 它将负责管理集群范围内的所有变更，例如增加、删除索引，或者增加、删除节点等。 而主节点并不需要涉及到文档级别的变更和搜索等操作(不承载所有的请求)，所以当集群只拥有一个主节点的情况下，即使流量的增加它也不会成为瓶颈。 任何节点都可以成为主节点。
这个Master的职责是维护集群元数据(集群节点信息)，维护索引元数据(创建索引、修改索引、删除索引)，
而worker节点则可以接受查询任务(分布式完成)。
作为用户，我们可以将请求发送到 集群中的任何节点 ，包括主节点。 每个节点都知道任意文档所处的位置，并且能够将我们的请求直接转发到存储我们所需文档的节点。 无论我们将请求发送到哪个节点，它都能负责从各个包含我们所需文档的节点收集回数据，并将最终结果返回給客户端。 Elasticsearch 对这一切的管理都是透明的。
所以单纯从架构角度来说，Es其实也是主从架构的，采用了类似raft的协议，至于为啥不用raft协议，说法很多。
3.3 系统通信
Es的系统之间的通信是使用Netty。
基于Netty有没有继续封装？？
https://zhuanlan.zhihu.com/p/36940048
3.4 文件存储
https://cloud.tencent.com/developer/article/1461826
Es并没有使用外接的分布式文件系统，Es使用的是类似于基于本地文件系统的主从备份机制的文件存储方式。
3.5 水平扩容
https://www.elastic.co/guide/cn/elasticsearch/guide/current/_coping_with_failure.html
如何扩容，扩容作用？
9 参考资料
https://blog.csdn.net/laoyang360/article/details/52244917
[Es竞品分析]https://youzhixueyuan.com/comparison-of-open-source-search-engine-selection.html
[使用 Docker 和 Elasticsearch 构建一个全文搜索应用程序] https://www.zcfy.cc/article/building-a-full-text-search-app-using-docker-and-elasticsearch
0 其他
-
Lucene是否保留原数据 。 其实就是正排文件，这个文件完整保留。
-
构建索引会生成哪些文件？ --> 倒排索引(term-> docId)的一个映射；
-
这些文件如何存储压缩？ docId重新编码、term->docId这种kv结构采用了FST的存储方式
-
shard的水平迁移过程
2万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
