「扫盲」Elasticsearch

时间 2020-01-22

标签扫盲 elasticsearch 栏目日志分析繁體版

原文原文链接

前言

只有光头才能变强。html

文本已收录至个人GitHub精选文章，欢迎Star：github.com/ZhongFuChen…java

不知道你们的公司用Elasticsearch多很少，反正我公司的是有在用的。平时听同事们聊天确定避免不了不认识的技术栈，例如说：把数据放在引擎，从引擎取出数据等等。node

若是对引擎不了解的同窗，就压根听不懂他们在说什么（我就是听不懂的一位，扎心了）。引擎通常指的是搜索引擎，如今用得比较多的就是Elasticsearch。git

这篇文章主要是对Elasticsearch一个简单的入门，没有高深的知识和使用。至少我想作到的是：之后同事们聊引擎了，至少知道他们在讲什么。github

什么是Elasticsearch？

Elasticsearch is a real-time, distributed storage, search, and analytics engine算法

Elasticsearch 是一个实时的分布式存储、搜索、分析的引擎。sql

介绍那儿有几个关键字：数据库

实时
分布式
搜索
分析

因而咱们就得知道Elasticsearch是怎么作到实时的，Elasticsearch的架构是怎么样的（分布式）。存储、搜索和分析（得知道Elasticsearch是怎么存储、搜索和分析的）缓存

这些问题在这篇文章中都会有说起。性能优化

我已经写了200多篇原创技术文章了，后续会写大数据相关的文章，若是想看我其余文章的同窗，不妨关注我吧。公众号：Java3y

若是以为我这篇文章还不错，对你有帮助，不要吝啬本身的赞！

为何要用Elasticsearch

在学习一项技术以前，必须先要了解为何要使用这项技术。因此，为何要使用Elasticsearch呢？咱们在平常开发中，数据库也能作到（实时、存储、搜索、分析）。

相对于数据库，Elasticsearch的强大之处就是能够模糊查询。

有的同窗可能就会说：我数据库怎么就不能模糊查询了？？我反手就给你写一个SQL：

select * from user where name like '%公众号Java3y%'
复制代码

这不就能够把公众号Java3y相关的内容搜索出来了吗？

的确，这样作的确能够。可是要明白的是：name like %Java3y%这类的查询是不走索引的，不走索引意味着：只要你的数据库的量很大（1亿条），你的查询确定会是秒级别的

若是对数据库索引还不是很了解的同窗，建议复看一下我之前的文章。我以为我当时写得还不赖（哈哈哈）

GitHub搜关键字：”索引“

并且，即使给你从数据库根据模糊匹配查出相应的记录了，那每每会返回大量的数据给你，每每你须要的数据量并无这么多，可能50条记录就足够了。

还有一个就是：用户输入的内容每每并无这么的精确，好比我从Google输入ElastcSeach（打错字），可是Google仍是能估算我想输入的是Elasticsearch

而Elasticsearch是专门作搜索的，就是为了解决上面所讲的问题而生的，换句话说：

Elasticsearch对模糊搜索很是擅长（搜索速度很快）
从Elasticsearch搜索到的数据能够根据评分过滤掉大部分的，只要返回评分高的给用户就行了（原生就支持排序）
没有那么准确的关键字也能搜出相关的结果（能匹配有相关性的记录）

下面咱们就来学学为何Elasticsearch能够作到上面的几点。

Elasticsearch的数据结构

众所周知，你要在查询的时候花得更少的时间，你就须要知道他的底层数据结构是怎么样的；举个例子：

树型的查找时间复杂度通常是O(logn)
链表的查找时间复杂度通常是O(n)
哈希表的查找时间复杂度通常是O(1)
....不一样的数据结构所花的时间每每不同，你想要查找的时候要快，就须要有底层的数据结构支持

从上面说Elasticsearch的模糊查询速度很快，那Elasticsearch的底层数据结构是什么呢？咱们来看看。

咱们根据“完整的条件”查找一条记录叫作正向索引；咱们一本书的章节目录就是正向索引，经过章节名称就找到对应的页码。

首先咱们得知道为何Elasticsearch为何能够实现快速的“模糊匹配”/“相关性查询”，其实是你写入数据到Elasticsearch的时候会进行分词。

仍是以上图为例，上图出现了4次“算法”这个词，咱们能不能根据此次词为它找他对应的目录？Elasticsearch正是这样干的，若是咱们根据上图来作这个事，会获得相似这样的结果：

算法 ->2,13,42,56

这表明着“算法”这个词确定是在第二页、第十三页、第四十二页、第五十六页出现过。这种根据某个词(不完整的条件)再查找对应记录，叫作倒排索引。

再看下面的图，好好体会一下：

众所周知，世界上有这么多的语言，那Elasticsearch怎么切分这些词呢？，Elasticsearch内置了一些分词器

Standard Analyzer 。按词切分，将词小写
Simple Analyzer。按非字母过滤（符号被过滤掉），将词小写
WhitespaceAnalyzer。按照空格切分，不转小写
....等等等

Elasticsearch分词器主要由三部分组成：

􏱀􏰉􏰂􏰈􏰂􏰆􏰄Character Filters（文本过滤器，去除HTML）
Tokenizer（按照规则切分，好比空格）
TokenFilter（将切分后的词进行处理，好比转成小写）

显然，Elasticsearch是老外写的，内置的分词器都是英文类的，而咱们用户搜索的时候每每搜的是中文，如今中文分词器用得最多的就是IK。

扯了一大堆，那Elasticsearch的数据结构是怎么样的呢？看下面的图：

咱们输入一段文字，Elasticsearch会根据分词器对咱们的那段文字进行分词（也就是图上所看到的Ada/Allen/Sara..)，这些分词汇总起来咱们叫作Term Dictionary，而咱们须要经过分词找到对应的记录，这些文档ID保存在PostingList

在Term Dictionary中的词因为是很是很是多的，因此咱们会为其进行排序，等要查找的时候就能够经过二分来查，不须要遍历整个Term Dictionary

因为Term Dictionary的词实在太多了，不可能把Term Dictionary全部的词都放在内存中，因而Elasticsearch还抽了一层叫作Term Index，这层只存储部分 词的前缀，Term Index会存在内存中（检索会特别快）

Term Index在内存中是以FST（Finite State Transducers）的形式保存的，其特色是很是节省内存。FST有两个优势：

1）空间占用小。经过对词典中单词前缀和后缀的重复利用，压缩了存储空间；
2）查询速度快。O(len(str))的查询时间复杂度。

前面讲到了Term Index是存储在内存中的，且Elasticsearch用FST（Finite State Transducers）的形式保存（节省内存空间）。Term Dictionary在Elasticsearch也是为他进行排序（查找的时候方便），其实PostingList也有对应的优化。

PostingList会使用Frame Of Reference（FOR）编码技术对里边的数据进行压缩，节约磁盘空间。

PostingList里边存的是文档ID，咱们查的时候每每须要对这些文档ID作交集和并集的操做（好比在多条件查询时)，PostingList使用Roaring Bitmaps来对文档ID进行交并集操做。

使用Roaring Bitmaps的好处就是能够节省空间和快速得出交并集的结果。

因此到这里咱们总结一下Elasticsearch的数据结构有什么特色：

Elasticsearch的术语和架构

从官网的介绍咱们已经知道Elasticsearch是分布式存储的，若是看过个人文章的同窗，对分布式这个概念应该不陌生了。

若是对分布式还不是很了解的同窗，建议复看一下我之前的文章。我以为我当时写得还不赖（哈哈哈）

GitHub搜关键字：”SpringCloud“,"Zookeeper","Kafka","单点登陆"

在讲解Elasticsearch的架构以前，首先咱们得了解一下Elasticsearch的一些常见术语。

Index：Elasticsearch的Index至关于数据库的Table
Type：这个在新的Elasticsearch版本已经废除（在之前的Elasticsearch版本，一个Index下支持多个Type--有点相似于消息队列一个topic下多个group的概念）
Document：Document至关于数据库的一行记录
Field：至关于数据库的Column的概念
Mapping：至关于数据库的Schema的概念
DSL：至关于数据库的SQL（给咱们读取Elasticsearch数据的API）

相信你们看完上面的对比图，对Elasticsearch的一些术语就不难理解了。那Elasticsearch的架构是怎么样的呢？下面咱们来看看：

一个Elasticsearch集群会有多个Elasticsearch节点，所谓节点实际上就是运行着Elasticsearch进程的机器。

在众多的节点中，其中会有一个Master Node，它主要负责维护索引元数据、负责切换主分片和副本分片身份等工做（后面会讲到分片的概念），若是主节点挂了，会选举出一个新的主节点。

从上面咱们也已经得知，Elasticsearch最外层的是Index（至关于数据库表的概念）；一个Index的数据咱们能够分发到不一样的Node上进行存储，这个操做就叫作分片。

好比如今我集群里边有4个节点，我如今有一个Index，想将这个Index在4个节点上存储，那咱们能够设置为4个分片。这4个分片的数据合起来就是Index的数据

为何要分片？缘由也很简单：

若是一个Index的数据量太大，只有一个分片，那只会在一个节点上存储，随着数据量的增加，一个节点未必能把一个Index存储下来。
多个分片，在写入或查询的时候就能够并行操做（从各个节点中读写数据，提升吞吐量）

如今问题来了，若是某个节点挂了，那部分数据就丢了吗？显然Elasticsearch也会想到这个问题，因此分片会有主分片和副本分片之分（为了实现高可用）

数据写入的时候是写到主分片，副本分片会复制主分片的数据，读取的时候主分片和副本分片均可以读。

Index须要分为多少个分片和副本分片都是能够经过配置设置的

若是某个节点挂了，前面所提升的Master Node就会把对应的副本分片提拔为主分片，这样即使节点挂了，数据就不会丢。

到这里咱们能够简单总结一下Elasticsearch的架构了：

Elasticsearch 写入的流程

上面咱们已经知道当咱们向Elasticsearch写入数据的时候，是写到主分片上的，咱们能够了解更多的细节。

客户端写入一条数据，到Elasticsearch集群里边就是由节点来处理此次请求：

集群上的每一个节点都是coordinating node（协调节点），协调节点代表这个节点能够作路由。好比节点1接收到了请求，但发现这个请求的数据应该是由节点2处理（由于主分片在节点2上），因此会把请求转发到节点2上。

coodinate（协调）节点经过hash算法能够计算出是在哪一个主分片上，而后路由到对应的节点
shard = hash(document_id) % (num_of_primary_shards)

路由到对应的节点以及对应的主分片时，会作如下的事：

将数据写到内存缓存区
而后将数据写到translog缓存区
每隔1s数据从buffer中refresh到FileSystemCache中，生成segment文件，一旦生成segment文件，就能经过索引查询到了
refresh完，memory buffer就清空了。
每隔5s中，translog 从buffer flush到磁盘中
按期/定量从FileSystemCache中,结合translog内容flush index到磁盘中。

解释一下：

Elasticsearch会把数据先写入内存缓冲区，而后每隔1s刷新到文件系统缓存区（当数据被刷新到文件系统缓冲区之后，数据才能够被检索到）。因此：Elasticsearch写入的数据须要1s才能查询到
为了防止节点宕机，内存中的数据丢失，Elasticsearch会另写一份数据到日志文件上，但最开始的仍是写到内存缓冲区，每隔5s才会将缓冲区的刷到磁盘中。因此：Elasticsearch某个节点若是挂了，可能会形成有5s的数据丢失。
等到磁盘上的translog文件大到必定程度或者超过了30分钟，会触发commit操做，将内存中的segement文件异步刷到磁盘中，完成持久化操做。

说白了就是：写内存缓冲区（定时去生成segement，生成translog），可以让数据能被索引、被持久化。最后经过commit完成一次的持久化。

等主分片写完了之后，会将数据并行发送到副本集节点上，等到全部的节点写入成功就返回ack给协调节点，协调节点返回ack给客户端，完成一次的写入。

Elasticsearch更新和删除

Elasticsearch的更新和删除操做流程：

给对应的doc记录打上.del标识，若是是删除操做就打上delete状态，若是是更新操做就把原来的doc标志为delete，而后从新新写入一条数据

前面提到了，每隔1s会生成一个segement 文件，那segement文件会愈来愈多愈来愈多。Elasticsearch会有一个merge任务，会将多个segement文件合并成一个segement文件。

在合并的过程当中，会把带有delete状态的doc给物理删除掉。

Elasticsearch查询

查询咱们最简单的方式能够分为两种：

根据ID查询doc
根据query（搜索词）去查询匹配的doc

public TopDocs search(Query query, int n);
public Document doc(int docID);
复制代码

根据ID去查询具体的doc的流程是：

检索内存的Translog文件
检索硬盘的Translog文件
检索硬盘的Segement文件

根据query去匹配doc的流程是：

同时去查询内存和硬盘的Segement文件

从上面所讲的写入流程，咱们就能够知道：Get（经过ID去查Doc是实时的），Query（经过query去匹配Doc是近实时的）

由于segement文件是每隔一秒才生成一次的

Elasticsearch查询又分能够为三个阶段：

QUERY_AND_FETCH（查询完就返回整个Doc内容）
QUERY_THEN_FETCH（先查询出对应的Doc id ，而后再根据Doc id 匹配去对应的文档）
DFS_QUERY_THEN_FETCH（先算分，再查询）
- 「这里的分指的是 词频率和文档的频率（Term Frequency、Document Frequency）众所周知，出现频率越高，相关性就更强」