es查询大文本效率_Elasticsearch 技术分析(七): Elasticsearch 的性能优化

本文介绍了Elasticsearch的性能优化,包括硬件选择、内部压缩的Frame Of Reference技术和Roaring Bitmaps,以及分片策略。硬件上推荐使用SSD和多块硬盘,避免远程挂载存储。压缩技术中,Frame Of Reference用于倒排列表的高效压缩,Roaring Bitmaps则适用于内存缓存。分片策略方面,强调合理设置分片数和副本,以及调整分片分配器类型。此外,还讨论了索引优化、查询效率和内存设置对性能的影响。
摘要由CSDN通过智能技术生成

java

java8

java开发

Elasticsearch 技术分析(七): Elasticsearch 的性能优化

硬件选择

Elasticsearch(后文简称 ES)的基础是 Lucene,所有的索引和文档数据是存储在本地的磁盘中,具体的路径可在 ES 的配置文件../config/elasticsearch.yml中配置,如下:

# ----------------------------------- Paths ------------------------------------

#

# Path to directory where to store the data (separate multiple locations by comma):

#

path.data: /path/to/data

#

# Path to log files:

#

path.logs: /path/to/logs

磁盘在现代服务器上通常都是瓶颈。Elasticsearch 重度使用磁盘,你的磁盘能处理的吞吐量越大,你的节点就越稳定。这里有一些优化磁盘 I/O 的技巧:

使用 SSD。就像其他地方提过的, 他们比机械磁盘优秀多了。

使用 RAID 0。条带化 RAID 会提高磁盘 I/O,代价显然就是当一块硬盘故障时整个就故障了。不要使用镜像或者奇偶校验 RAID 因为副本已经提供了这个功能。

另外,使用多块硬盘,并允许 Elasticsearch 通过多个 path.data 目录配置把数据条带化分配到它们上面。

不要使用远程挂载的存储,比如 NFS 或者 SMB/CIFS。这个引入的延迟对性能来说完全是背道而驰的。

如果你用的是 EC2,当心 EBS。即便是基于 SSD 的 EBS,通常也比本地实例的存储要慢。

内部压缩

硬件资源比较昂贵,一般不会花大成本去购置这些,可控的解决方案还是需要从软件方面来实现性能优化提升。

其实,对于一个分布式、可扩展、支持PB级别数据、实时的搜索与数据分析引擎,ES 本身对于索引数据和文档数据的存储方面内部做了很多优化,具体体现在对数据的压缩,那么是如何压缩的呢?介绍前先要说明下 Postings lists 的概念。

倒排列表 - postings list

搜索引擎一项很重要的工作就是高效的压缩和快速的解压缩一系列有序的整数列表。我们都知道,Elasticsearch 基于 Lucene,一个 Lucene 索引 我们在 Elasticsearch 称作 分片 , 并且引入了 按段搜索 的概念。

新的文档首先被添加到内存索引缓存中,然后写入到一个基于磁盘的段。在每个 segment 内文档都会有一个 0 到文档个数之间的标识符(最高值 2^31 -1),称之为 doc ID。这在概念上类似于数组中的索引:它本身不做存储,但足以识别每个item 数据。

Segments 按顺序存储有关文档的数据,在一个Segments 中 doc ID 是 文档的索引。因此,segment 中的第一个文档的 doc ID 为0,第二个为1,等等。直到最后一个文档,其 doc ID 等于 segment 中文档的总数减1。

那么这些 doc ID 有什么用呢?倒排索引需要将 terms 映射到包含该单词 (term) 的文档列表,这样的映射列表我们称之为:倒排列表(postings list)。具体某一条映射数据称之为:倒排索引项(Posting)。

举个例子,文档和词条之间的关系如下图所示,右边的关系表即为倒排列表:

倒排列表 用来记录有哪些文档包含了某个单词(Term)。一般在文档集合里会有很多文档包含某个单词,每个文档会记录文档编号(doc ID),单词在这个文档中出现的次数(TF)及单词在文档中哪些位置出现过等信息,这样与一个文档相关的信息被称做 倒排索引项(Posting),包含这个单词的一系列倒排索引项形成了列表结构,这就是某个单词对应的 倒排列表 。

Frame Of Reference

了解了分词(Term)和文档(Document)之间的映射关系后,为了高效的计算交集和并集,我们需要倒排列表(postings lists)是有序的,这样方便我们压缩和解压缩。

针对倒排列表,Lucene 采用一种增量编码的方式将一系列 ID 进行压缩存储,即称为Frame Of Reference的压缩方式(FOR),自Lucene 4.1以来一直在使用。

在实际的搜索引擎系统中,并不存储倒排索引项中的实际文档编号(Doc ID),而是代之以文档编号差值(D-Gap)。文档编号差值是倒排列表中相邻的两个倒排索引项文档编号的差值,一般在索引构建过程中,可以保证倒排列表中后面出现的文档编号大于之前出现的文档编号,所以文档编号差值总是大于0的整数。

如下图所示的例子中,原始的 3个文档编号分别是187、196和199,通过编号差值计算,在实际存储的时候就转化成了:187、9、3。

之所以要对文档编号进行差值计算,主要原因是为了更好地对数据进行压缩,原始文档编号一般都是大数值ÿ

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值