Elasticsearch的相关知识

最近项目中用到了elasticsearch来进行商品搜索的，所以专门总结如下：

1. 倒排索引

又称反向索引，比如以诗歌中的字作为key，诗歌作为value，但直接对诗中的每一个字和诗的内容建立索引就会导致索引量爆炸，所以一般都会直接将value换成诗的题目：

再比如下面这个表格：

我们可以建立名字和内容之间的索引：

size的倒排索引：

sex的倒排索引：

大家可以看到所有的倒排所有都有Term和Posting List这两个概念，Posting list就是一个int的数组，存储了所有符合某个term的文档id。
接下来就是ES中的重要概念了，即Term Index和Term Dictionary：
Term Dictionary：这个很好理解，我上面说过都是各种Term组成的，那为了查找Term方便，es把所有的Term都排序了，是二分法查找的。
Trem Index：这是为了优化Term Dictionary而存在的，大家想呀这么多Term光是排序了肯定也不行，想要快就得放到内存，但是es数据量级往往是很大的，那放在磁盘？磁盘的寻址又会很慢，那怎么去减少磁盘上的寻址开销呢？Term Index其实就是跟新华字典一样，每个字母开头的是哪些，再按照拼音去排序。

PS：实际上，Term Index就存了一些前缀和映射关系，可以大大减少磁盘的随机读次数。

2. 接近实时（NTR）

ES写入的数据会先写到一个内存bufferr中去(在buffer里的时候数据是搜索不到的)，然后每隔默认是一秒会刷到os cache。

操作系统里面，磁盘文件其实都有一个东西，叫做os cache，操作系统缓存，就是说数据写入磁盘文件之前，会先进入os cache，先进入操作系统级别的一个内存缓存中去。

只要buffer中的数据被refresh操作，刷入os cache中，就代表这个数据就可以被搜索到了。默认是每隔1秒refresh一次的，所以es是准实时的，因为写入的数据1秒之后才能被看到。
如果我们不将查询到的数据先刷进OS cache而是直接放进磁盘情形如下：

这样是十分消耗资源的，而且写了马上去硬盘读取，并发量很难上去，你可以想象上万QPS写入的时候，还去查询磁盘，是怎样一个灾难级别的现场。
而es采用的做法是：

数据写入到buffer，然后再每秒刷到cache，这个时候就可以被搜到了，所以说准实时，而不是实时就是这一秒的差距，这样设计可以让磁盘压力减少不说，写入和查询都不会受到影响，并发也就上去了。

3、分词

停词过滤，所谓的停词过滤就是将一句话中的词“的”、“而”等等，这些词本身是没有意义的，就叫停顿词，建立索引的时候没必要考虑他们

所有搜索引擎一般都有三大过程，爬取内容、进行分词、建立反向索引

4、ES中的几个专有名词

索引、类型、文档，他可以与MySQL中的一些名词进行对应：

比如一首诗，有诗题、作者、朝代、字数、诗内容等字段，那么首先，我们可以建立一个名叫 Poems 的索引，然后创建一个名叫 Poem 的类型，类型是通过 Mapping 来定义每个字段的类型。

其中keyword和text都是表示字符串，但涉及到分词的问题，Keyword 类型是不会分词的，直接根据字符串内容建立反向索引，Text 类型在存入 Elasticsearch 的时候，会先分词，然后根据分词后的内容建立反向索引。

5、ES分布式原理

elasticsearch中节点是对等的，但属于master-slave架构，节点间会通过自己的一些规则选取集群的mater，Master会负责集群状态信息的改变,并同步给其他节点。同时，Elasticsearch 也是会对数据进行切分，同时每一个分片会保存多个副本，保证分布式环境下的高可用。

建立索引的请求先发到master，master建立完所以后，将集群状态同步到slave

这样不会导致写入效率低下，因为只有简历索引和类型需要经过 Master，数据的写入有一个简单的 Routing 规则，可以 Route 到集群中的任意节点，所以数据写入压力是分散在整个集群的。

6、脑裂

脑裂问题其实在集群部署的机器上都是会存在的，假设现在es集群有两个节点，节点1是主节点对外提供服务，节点2是副本分片节点。

现在两个节点因为网络原因断联了，会发现什么？主节点发现自己是主节点继续对外提供服务，副本节点发现没有主节点了，选举自己是主节点，也对外提供服务了，因为主节点不可用他也是被迫当主节点的。


如何解决？
elasticsearch.yml中有个配置:discovery.zen.minimum_master_nodes 这个参数决定了在选主过程中需要有多少个节点通信，默认是1，设置的原则就是设置为 集群节点数量/2+1个。

如果你的集群是三个节点，那这个参数就设置为3/2+1=2个，那挂了一个，另外两个可以通信，所以可以选出一个主的，如果你集群是两个个节点，参数还是2，但是你发现挂了一个只有一个节点自己跟自己通信，就不会选主了。

但是这样也有弊端只有2个节点的时候，挂一个就相当于服务不可用了，所以大家要保证集群是三个以上是最好的。
具体怎么选主主要是基于Bully选举算法

7、ELK

其实提到ES往往都是ELK三兄弟一起提到的，最后在收尾的地方，我就说一下另外两个兄弟吧。

L是Logstash，Logstash是一个开源数据收集引擎，具有实时管道功能。Logstash可以动态地将来自不同数据源的数据统一起来，并将数据标准化到你所选择的目的地。

Logstash管道有两个必需的元素：输入和输出，以及一个可选元素：过滤器。输入插件从数据源那里消费数据，过滤器插件根据你的期望修改数据，输出插件将数据写入目的地。

K就是Kibana，Kibana是一个针对Elasticsearch的开源分析及可视化平台，用来搜索、查看交互存储在Elasticsearch索引中的数据。使用Kibana，可以通过各种图表进行高级数据分析及展示。

Kibana让海量数据更容易理解。它操作简单，基于浏览器的用户界面可以快速创建仪表板（dashboard）实时显示Elasticsearch查询动态。

设置Kibana非常简单，无需编码或者额外的基础架构，几分钟内就可以完成Kibana安装并启动Elasticsearch索引监测。

运维人员分析日志的作用：
分析日志的用处可大了，你想，假如一个分布式系统有 1000 台机器，系统出现故障时，我要看下日志，还得一台一台登录上去查看，是不是非常麻烦？但是如果日志接入了 ELK 系统就不一样。比如系统运行过程中，突然出现了异常，在日志中就能及时反馈，日志进入 ELK 系统中，我们直接在 Kibana 就能看到日志情况。如果再接入一些实时计算模块，还能做实时报警功能。

总结：

• 反向索引又叫倒排索引，是根据文章内容中的关键字建立索引。
• 搜索引擎原理就是建立反向索引。
• Elasticsearch 在 Lucene 的基础上进行封装，实现了分布式搜索引擎。
• Elasticsearch 中的索引、类型和文档的概念比较重要，类似于 MySQL 中的数据库、表和行。
• Elasticsearch 也是 Master-slave 架构，也实现了数据的分片和备份。
• Elasticsearch 一个典型应用就是 ELK 日志分析系统。