Elasticsearch 技术分析（七）： Elasticsearch 的性能优化

时间 2019-11-18

原文原文链接

硬件选择

Elasticsearch（后文简称 ES）的基础是 Lucene，全部的索引和文档数据是存储在本地的磁盘中，具体的路径可在 ES 的配置文件../config/elasticsearch.yml中配置，以下：node

# ----------------------------------- 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，一般也比本地实例的存储要慢。

内部压缩

硬件资源比较昂贵，通常不会花大成本去购置这些，可控的解决方案仍是须要从软件方面来实现性能优化提高。json

其实，对于一个分布式、可扩展、支持PB级别数据、实时的搜索与数据分析引擎，ES 自己对于索引数据和文档数据的存储方面内部作了不少优化，具体体如今对数据的压缩，那么是如何压缩的呢？介绍前先要说明下 Postings lists 的概念。bootstrap

倒排列表 - 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个文档编号分别是18七、196和199，经过编号差值计算，在实际存储的时候就转化成了：18七、九、3。

之因此要对文档编号进行差值计算，主要缘由是为了更好地对数据进行压缩，原始文档编号通常都是大数值，经过差值计算，就有效地将大数值转换为了小数值，而这有助于增长数据的压缩率。

好比一个词对应的文档ID 列表[73, 300, 302, 332,343, 372] ，ID列表首先要从小到大排好序；

第一步： 增量编码就是从第二个数开始每一个数存储与前一个id的差值，即300-73=227，302-300=2，...，一直到最后一个数。
第二步： 就是将这些差值放到不一样的区块，Lucene使用256个区块，下面示例为了方便展现使用了3个区块，即每3个数一组。
第三步： 位压缩，计算每组3个数中最大的那个数须要占用bit位数，好比30、十一、29中最大数30最小须要5个bit位存储，这样十一、29也用5个bit位存储，这样才占用15个bit，不到2个字节，压缩效果很好。

以下面原理图所示，这是一个区块大小为3的示例（其实是256）：

考虑到频繁出现的term（所谓low cardinality的值），好比gender里的男或者女。若是有1百万个文档，那么性别为男的 posting list 里就会有50万个int值。用 Frame of Reference 编码进行压缩能够极大减小磁盘占用。这个优化对于减小索引尺寸有很是重要的意义。

由于这个 FOR 的编码是有解压缩成本的。利用skip list(跳表)，除了跳过了遍历的成本，也跳过了解压缩这些压缩过的block的过程，从而节省了cpu。

Roaring bitmaps （RBM）

在 elasticsearch 中使用filters 优化查询，filter查询只处理文档是否匹配与否，不涉及文档评分操做，查询的结果能够被缓存。具体的 Filter 和Query 的异同读者能够自行网上查阅资料。

对于filter 查询，elasticsearch 提供了Filter cache 这种特殊的缓存，filter cache 用来存储 filters 获得的结果集。缓存 filters 不须要太多的内存，它只保留一种信息，即哪些文档与filter相匹配。同时它能够由其它的查询复用，极大地提高了查询的性能。

Frame Of Reference 压缩算法对于倒排表来讲效果很好，但对于须要存储在内存中的 Filter cache 等不太合适。

倒排表和Filter cache二者之间有不少不一样之处：

倒排表存储在磁盘，针对每一个词都须要进行编码，而Filter等内存缓存只会存储那些常用的数据。
针对Filter数据的缓存就是为了加速处理效率，对压缩算法要求更高。

这就产生了下面针对内存缓存数据能够进行高效压缩解压和逻辑运算的roaring bitmaps算法。

说到Roaring bitmaps，就必须先从bitmap提及。Bitmap是一种数据结构，假设有某个posting list：

[3,1,4,7,8]

对应的Bitmap就是：

[0,1,0,1,1,0,0,1,1]

很是直观，用0/1表示某个值是否存在，好比8这个值就对应第8位，对应的bit值是1，这样用一个字节就能够表明8个文档id（1B = 8bit），旧版本(5.0以前)的Lucene就是用这样的方式来压缩的。但这样的压缩方式仍然不够高效，Bitmap自身就有压缩的特色，其用一个byte就能够表明8个文档，因此100万个文档只须要12.5万个byte。可是考虑到文档可能有数十亿之多，在内存里保存Bitmap仍然是很奢侈的事情。并且对于个每个filter都要消耗一个Bitmap，好比age=18缓存起来的话是一个Bitmap，18<=age<25是另一个filter缓存起来也要一个Bitmap。

Bitmap的缺点是存储空间随着文档个数线性增加，因此秘诀就在于须要有一个数据结构打破这个魔咒，那么就必定要用到某些指数特性：

能够很压缩地保存上亿个bit表明对应的文档是否匹配filter；
这个压缩的Bitmap仍然能够很快地进行AND和 OR的逻辑操做。

Lucene使用的这个数据结构叫作 Roaring Bitmap，即位图压缩算法，简称BMP。

其压缩的思路其实很简单。与其保存100个0，占用100个bit。还不如保存0一次，而后声明这个0重复了100遍。

这两种合并使用索引的方式都有其用途。Elasticsearch 对其性能有详细的对比，可阅读 Frame of Reference and Roaring Bitmaps。

分片策略

合理设置分片数

建立索引的时候，咱们须要预分配 ES 集群的分片数和副本数，即便是单机状况下。若是没有在 mapping 文件中指定，那么索引在默认状况下会被分配5个主分片和每一个主分片的1个副本。

分片和副本的设计为 ES 提供了支持分布式和故障转移的特性，但并不意味着分片和副本是能够无限分配的。并且索引的分片完成分配后因为索引的路由机制，咱们是不能从新修改分片数的。

例如某个创业公司初始用户的索引 t_user 分片数为2，可是随着业务的发展用户的数据量迅速增加，这时咱们是不能从新将索引 t_user 的分片数增长为3或者更大的数。

可能有人会说，我不知道这个索引未来会变得多大，而且事后我也不能更改索引的大小，因此为了保险起见，仍是给它设为 1000 个分片吧…

一个分片并非没有代价的。须要了解：

一个分片的底层即为一个 Lucene 索引，会消耗必定文件句柄、内存、以及 CPU 运转。
每个搜索请求都须要命中索引中的每个分片，若是每个分片都处于不一样的节点还好，但若是多个分片都须要在同一个节点上竞争使用相同的资源就有些糟糕了。
用于计算相关度的词项统计信息是基于分片的。若是有许多分片，每个都只有不多的数据会致使很低的相关度。

适当的预分配是好的。但上千个分片就有些糟糕。咱们很难去定义分片是否过多了，这取决于它们的大小以及如何去使用它们。一百个分片但不多使用还好，两个分片但很是频繁地使用有可能就有点多了。监控你的节点保证它们留有足够的空闲资源来处理一些特殊状况。

一个业务索引具体须要分配多少分片可能须要架构师和技术人员对业务的增加有个预先的判断，横向扩展应当分阶段进行。为下一阶段准备好足够的资源。只有当你进入到下一个阶段，你才有时间思考须要做出哪些改变来达到这个阶段。

通常来讲，咱们遵循一些原则：

控制每一个分片占用的硬盘容量不超过ES的最大JVM的堆空间设置（通常设置不超过32G，参考下文的JVM设置原则），所以，若是索引的总容量在500G左右，那分片大小在16个左右便可；固然，最好同时考虑原则2。
考虑一下node数量，通常一个节点有时候就是一台物理机，若是分片数过多，大大超过了节点数，极可能会致使一个节点上存在多个分片，一旦该节点故障，即便保持了1个以上的副本，一样有可能会致使数据丢失，集群没法恢复。因此，通常都设置分片数不超过节点数的3倍。
主分片，副本和节点最大数之间数量，咱们分配的时候能够参考如下关系：
节点数<=主分片数*（副本数+1）

建立索引的时候须要控制分片分配行为，合理分配分片，若是后期索引所对应的数据愈来愈多，咱们还能够经过索引别名等其余方式解决。

调整分片分配器的类型

以上是在建立每一个索引的时候须要考虑的优化方法，然而在索引已建立好的前提下，是否就是没有办法从分片的角度提升了性能了呢？固然不是，首先能作的是调整分片分配器的类型，具体是在 elasticsearch.yml 中设置cluster.routing.allocation.type 属性，共有两种分片器even_shard，balanced（默认）。

even_shard 是尽可能保证每一个节点都具备相同数量的分片，balanced 是基于可控制的权重进行分配，相对于前一个分配器，它更暴漏了一些参数而引入调整分配过程的能力。

每次ES的分片调整都是在ES上的数据分布发生了变化的时候进行的，最有表明性的就是有新的数据节点加入了集群的时候。固然调整分片的时机并非由某个阈值触发的，ES内置十一个裁决者来决定是否触发分片调整，这里暂不赘述。另外，这些分配部署策略都是能够在运行时更新的，更多配置分片的属性也请你们自行查阅网上资料。

推迟分片分配

对于节点瞬时中断的问题，默认状况，集群会等待一分钟来查看节点是否会从新加入，若是这个节点在此期间从新加入，从新加入的节点会保持其现有的分片数据，不会触发新的分片分配。这样就能够减小 ES 在自动再平衡可用分片时所带来的极大开销。

经过修改参数 delayed_timeout ，能够延长再均衡的时间，能够全局设置也能够在索引级别进行修改:

PUT /_all/_settings 
{
  "settings": {
    "index.unassigned.node_left.delayed_timeout": "5m" 
  }
}

经过使用 _all 索引名，咱们能够为集群里面的全部的索引使用这个参数，默认时间被延长成了 5 分钟。

这个配置是动态的，能够在运行时进行修改。若是你但愿分片当即分配而不想等待，你能够设置参数： delayed_timeout: 0。

延迟分配不会阻止副本被提拔为主分片。集群仍是会进行必要的提拔来让集群回到 yellow 状态。缺失副本的重建是惟一被延迟的过程。

索引优化

Mapping建模

尽可能避免使用nested或 parent/child，能不用就不用；

nested query慢， parent/child query 更慢，比nested query慢上百倍；所以能在mapping设计阶段搞定的（大宽表设计或采用比较smart的数据结构），就不要用父子关系的mapping。
若是必定要使用nested fields，保证nested fields字段不能过多，目前ES默认限制是50。参考：
```
index.mapping.nested_fields.limit ：50
```
由于针对1个document, 每个nested field, 都会生成一个独立的document, 这将使Doc数量剧增，影响查询效率，尤为是Join的效率。
避免使用动态值做字段(key)，动态递增的mapping，会致使集群崩溃；一样，也须要控制字段的数量，业务中不使用的字段，就不要索引。

控制索引的字段数量、mapping深度、索引字段的类型，对于ES的性能优化是重中之重。如下是ES关于字段数、mapping深度的一些默认设置：
```
index.mapping.nested_objects.limit :10000
index.mapping.total_fields.limit:1000
index.mapping.depth.limit: 20
```
不须要作模糊检索的字段使用 keyword类型代替 text 类型，这样能够避免在创建索引前对这些文本进行分词。
对于那些不须要聚合和排序的索引字段禁用Doc values。

Doc Values 默认对全部字段启用，除了 analyzed strings。也就是说全部的数字、地理坐标、日期、IP 和不分析（ not_analyzed ）字符类型都会默认开启。

由于 Doc Values 默认启用，也就是说ES对你数据集里面的大多数字段均可以进行聚合和排序操做。可是若是你知道你永远也不会对某些字段进行聚合、排序或是使用脚本操做，尽管这并不常见，这时你能够经过禁用特定字段的 Doc Values 。这样不只节省磁盘空间，也会提高索引的速度。

要禁用 Doc Values ，在字段的映射（mapping）设置 doc_values: false 便可。

索引设置

若是你的搜索结果不须要近实时的准确度，考虑把每一个索引的 index.refresh_interval 改到 30s或者更大。若是你是在作大批量导入，设置 refresh_interval 为-1，同时设置number_of_replicas 为0，经过关闭 refresh 间隔周期，同时不设置副原本提升写性能。

文档在复制的时候，整个文档内容都被发往副本节点，而后逐字的把索引过程重复一遍。这意味着每一个副本也会执行分析、索引以及可能的合并过程。

相反，若是你的索引是零副本，而后在写入完成后再开启副本，恢复过程本质上只是一个字节到字节的网络传输。相比重复索引过程，这个算是至关高效的了。
修改 index_buffer_size 的设置，能够设置成百分数，也可设置成具体的大小，最多给512M，大于这个值会触发refresh。默认值是JVM的内存10%，可是是全部切片共享大小。可根据集群的规模作不一样的设置测试。
indices.memory.index_buffer_size：10%（默认） indices.memory.min_index_buffer_size： 48mb（默认） indices.memory.max_index_buffer_size
修改 translog 相关的设置：

a. 控制数据从内存到硬盘的操做频率，以减小硬盘IO。可将 sync_interval 的时间设置大一些。
index.translog.sync_interval：5s(默认)。
b. 控制 tranlog 数据块的大小，达到 threshold 大小时，才会 flush 到 lucene 索引文件。
index.translog.flush_threshold_size：512mb(默认)

_id字段的使用，应尽量避免自定义_id, 以免针对ID的版本管理；建议使用ES的默认ID生成策略或使用数字类型ID作为主键，包括零填充序列 ID、UUID-1 和纳秒；这些 ID 都是有一致的，压缩良好的序列模式。相反的，像 UUID-4 这样的 ID，本质上是随机的，压缩比很低，会明显拖慢 Lucene。
_all 字段及_source 字段的使用，应该注意场景和须要，_all字段包含了全部的索引字段，方便作全文检索，若是无此需求，能够禁用；_source存储了原始的document内容，若是没有获取原始文档数据的需求，可经过设置includes、excludes 属性来定义放入_source的字段。
合理的配置使用index属性，analyzed 和not_analyzed，根据业务需求来控制字段是否分词或不分词。只有 groupby需求的字段，配置时就设置成not_analyzed, 以提升查询或聚类的效率。

查询效率

使用批量请求，批量索引的效率确定比单条索引的效率要高。
query_string 或 multi_match 的查询字段越多，查询越慢。能够在 mapping 阶段，利用 copy_to 属性将多字段的值索引到一个新字段，multi_match时，用新的字段查询。
日期字段的查询，尤为是用now 的查询其实是不存在缓存的，所以，能够从业务的角度来考虑是否必定要用now, 毕竟利用 query cache 是可以大大提升查询效率的。
查询结果集的大小不能随意设置成大得离谱的值，如query.setSize不能设置成 Integer.MAX_VALUE，由于ES内部须要创建一个数据结构来放指定大小的结果集数据。
尽可能避免使用 script，万不得已须要使用的话，选择painless & experssions 引擎。一旦使用 script 查询，必定要注意控制返回，千万不要有死循环（以下错误的例子），由于ES没有脚本运行的超时控制，只要当前的脚本没执行完，该查询会一直阻塞。如：
{ “script_fields”：{ “test1”：{ “lang”：“groovy”， “script”：“while（true）{print 'don’t use script'}” } } }
避免层级过深的聚合查询，层级过深的group by , 会致使内存、CPU消耗，建议在服务层经过程序来组装业务，也能够经过pipeline 的方式来优化。
复用预索引数据方式来提升 AGG 性能：

如经过 terms aggregations 替代 range aggregations，如要根据年龄来分组，分组目标是: 少年（14岁如下）青年（14-28）中年（29-50）老年（51以上），能够在索引的时候设置一个age_group字段，预先将数据进行分类。从而不用按age来作range aggregations, 经过age_group字段就能够了。
Cache的设置及使用：

a) QueryCache: ES查询的时候，使用filter查询会使用query cache, 若是业务场景中的过滤查询比较多，建议将querycache设置大一些，以提升查询速度。
indices.queries.cache.size： 10%（默认），//可设置成百分比，也可设置成具体值，如256mb。
固然也能够禁用查询缓存（默认是开启），经过index.queries.cache.enabled：false设置。

b) FieldDataCache: 在聚类或排序时，field data cache会使用频繁，所以，设置字段数据缓存的大小，在聚类或排序场景较多的情形下颇有必要，可经过indices.fielddata.cache.size：30% 或具体值10GB来设置。可是若是场景或数据变动比较频繁，设置cache并非好的作法，由于缓存加载的开销也是特别大的。

c) ShardRequestCache: 查询请求发起后，每一个分片会将结果返回给协调节点(Coordinating Node), 由协调节点将结果整合。

若是有需求，能够设置开启; 经过设置index.requests.cache.enable: true来开启。

不过，shard request cache 只缓存 hits.total, aggregations, suggestions 类型的数据，并不会缓存hits的内容。也能够经过设置indices.requests.cache.size: 1%（默认）来控制缓存空间大小。

ES的内存设置

因为ES构建基于lucene, 而lucene设计强大之处在于lucene可以很好的利用操做系统内存来缓存索引数据，以提供快速的查询性能。lucene的索引文件segements是存储在单文件中的，而且不可变，对于OS来讲，可以很友好地将索引文件保持在cache中，以便快速访问；所以，咱们颇有必要将一半的物理内存留给lucene ; 另外一半的物理内存留给ES（JVM heap )。因此，在ES内存设置方面，能够遵循如下原则：

当机器内存小于64G时，遵循通用的原则，50%给ES，50%留给lucene。
当机器内存大于64G时，遵循如下原则：
- a. 若是主要的使用场景是全文检索, 那么建议给ES Heap分配 4~32G的内存便可；其它内存留给操做系统, 供lucene使用（segments cache), 以提供更快的查询性能。
- b. 若是主要的使用场景是聚合或排序，而且大多数是numerics, dates, geo_points 以及not_analyzed的字符类型，建议分配给ES Heap分配 4~32G的内存便可，其它内存留给操做系统，供lucene使用(doc values cache)，提供快速的基于文档的聚类、排序性能。
- c. 若是使用场景是聚合或排序，而且都是基于analyzed 字符数据，这时须要更多的 heap size, 建议机器上运行多ES实例，每一个实例保持不超过50%的ES heap设置(但不超过32G，堆内存设置32G如下时，JVM使用对象指标压缩技巧节省空间)，50%以上留给lucene。
禁止swap，一旦容许内存与磁盘的交换，会引发致命的性能问题。经过：在elasticsearch.yml 中 bootstrap.memory_lock: true，以保持JVM锁定内存，保证ES的性能。
GC设置原则：
- a. 保持GC的现有设置，默认设置为：Concurrent-Mark and Sweep (CMS)，别换成G1GC，由于目前G1还有不少BUG。
- b. 保持线程池的现有设置，目前ES的线程池较1.X有了较多优化设置，保持现状便可；默认线程池大小等于CPU核心数。若是必定要改，按公式（（CPU核心数* 3）/ 2）+ 1 设置；不能超过CPU核心数的2倍；可是不建议修改默认配置，不然会对CPU形成硬伤。

调整JVM设置

ES 是在 lucene 的基础上进行研发的，隐藏了 lucene 的复杂性，提供简单易用的 RESTful Api接口。ES 的分片至关于 lucene 的索引。因为 lucene 是 Java 语言开发的，是 Java 语言就涉及到 JVM，因此 ES 存在 JVM的调优问题。

调整内存大小。当频繁出现full gc后考虑增长内存大小，可是堆内存和堆外内存不要超过32G。
调整写入的线程数和队列大小。不过线程数最大不能超过33个（es控制死）。
ES很是依赖文件系统缓存，以便快速搜索。通常来讲，应该至少确保物理上有一半的可用内存分配到文件系统缓存。

参考文档：