工程组件-elasticsearch源码解析与优化实战（1.1 基本概念和原理）

背景

es是现今号称最快的搜索引擎，支持集群部署，本博客来白话一下es，算是一个启蒙吧。
参考：《Elasticsearch源码解析与优化实战》的第一章

划重点

es是实时的分布式的搜索引擎

• 实时：新增到es中的数据，在1s内就可以被检索到
• 分布式：可以弹性扩容，但分布式的规模在“百”台的级别，算是中等规模（大规模的为何难以支持呢？原因是什么呢？）

基于lucene实现全文搜索

• 全文搜索：通过文中的词语（所以必然会涉及到分词），去搜索文章，而且给出搜索排名（排名用倒排索引）
• Lucene：一个java库，2000年出品。既然只是一个库，那么它只提供搜索功能，不提供分布式功能

索引的结构

• 面向文档存储。文档，简单理解为一篇文章
• 存储结构，由_index、_type（即将废弃）、_id唯一标识一个文档。关键考虑_index 和 _id。
• _index，有很多地方都说 index可以理解为一个db数据库，我反而觉得index可以直接理解一个table，更好的理解为，一个分析型数据库的table（以分析功能为主的数据库，比如hive，存储的数据最好不好更改，比如update和delete操作。大家要说了，不能改多别扭。没关系，不能改，我们可以选择创建新表呀，大不了之前的表不用了。。。）
• _id，唯一索引，类似与mysql表中的主键id
• 删除数据，最好以index为单位，以id删，只是逻辑删除，空间并没有释放

分片shard

• 数据切分的理由，数据量太大，需要进行分布式存储，那么必然需要有一个策略，把数据等分到不同的机器上，因此出现分片概念
• 分片，既是es中的最小存储单元，也是最小计算单元
• 存储单元就不说了，计算单元，指的是Lucene的直接操作数据（即每次写入和读取）的单元，不同分片的并行操作，必然会用到多线程，所以分片过多，也必然会需要更多的线程，也就会产生更多的上下文切换，而降低效率

一个分片就是一个Lucene的索引，它本身就是一个完整的搜索引擎，可以独立执行建立索引和搜索的任务。

• 分片副本，通过es配置实现，主分片的机器宕机，可以由副本分片顶上去
• 分片（Lucene索引）由很多分段（segment）组成，分段专门是Lucene的概念，主要是用于全文索引。

以下是几个概念的关系图
https://www.processon.com/view/link/5dbab825e4b0893e9a6c3ec3

filed（字段）和term（分词）都Lucene的概念，完全是为了全文索引而存在。

分片的数量太大，机器的压力也就太大。
分片的数量太小，机器可能不会完全发挥它的计算性能，而导致浪费资源。。

阿里云对此有过推荐：

红色部分的白话就是：索引的分片数设置，不要超过节点数的五倍（阿里云默认是1倍）。

动态更新索引

• 更新，其实是Lucene建立了新的倒排索引，并不是实际意义上的更新（这里有个问题，之前的怎么办？博主猜测应该是做了标记删除）
• 删除，不是真正意义的删除，而只是进行标记，在分段合并的时候才会进行删除

段合并

• 分段，es每秒清空一次写缓冲，这个过程叫做refresh，每次refresh都会创建一个分段
• 分段太多怎么办？答案是，分段合并，es会策略的进行分段合并
• 分段太多有什么坏处？1）linux文件句柄不够；2）搜索需要进行所有分段的遍历，效率太低；

评价

本文重点是白话一下es中的几个重要的概念，重点帮助了解分片和节点，有助于es集群初期的建设和配置。
后续章节待有精力的时候继继续分享。

---

后记

近日，推荐系统需要申请es，用于存储文章，便于召回。在申请es中，最重要数据是：存储空间的计算。参考本博客已经能初步清楚空间的计算方法（有一部分参考了阿里云的建议），下面记录本次申请es的过程。

下面是同事申请的一个参考：

我的申请如下：
新建es集群，配置如下：

• 实例类型：商业版
• es版本：6.3
• 可用区数量：单区可用
• 规格：云盘
• 实例规则：2核4G
• 节点数量：2
• 存储类型：ssd云盘
• 云盘加密：否
• 单节点存储空间：30G
• 专有节点：否
• 协调节点：否
• 冷数据节点：否