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

mac2024-11-22  52

背景

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专有节点:否协调节点:否冷数据节点:否
最新回复(0)