Es优化（二）

最新推荐文章于 2024-09-29 11:27:40 发布

卡奥斯道

最新推荐文章于 2024-09-29 11:27:40 发布

阅读量1.4k

点赞数

分类专栏： elasticsearch

elasticsearch 专栏收录该内容

6 篇文章 0 订阅

订阅专栏

亿级规模的ES查询优化实战

能用filter就不用query
filter拿到相应的doc后不计算score不用排序
query会对符合条件的doc计算score并进行排序
filter的查询速度比query快很多
增加相关cache的配置
indices.cache.filter.size: 30%
indices.fielddata.cache.size: 60%
index.cache.field.type: soft
indices.breaker.fielddata.limit: 70%
优化方案——总结
能用filter就不用query
增加冗余字段将部分range aggregation查询变成terms aggregation
为常用字段增加配置，将fielddata的loading设成eager，尽量多加载到内存
增加集群的缓存资源，把内存尽量多的用起来
Global ordinals
Index warmer
调整aggregation的collect_mode
上SSD

elasticsearch一些使用经验以及优化方法

Elasticsearch索引速度优化
index.refresh_interval :-1
index.number_of_shards : X
index.number_of_replicas : 0
index.translog.sync_interval : 30s
index.translog.durability : “async”
index.translog.flush_threshold_size: 4g
index.translog.flush_threshold_ops: 50000
其它
去掉_all字段可节省一半空间
开启索引压缩可节省空间，但会有10%-20%的性能损耗

不需分词的字符串字段设成not_analyzed
========================================
（零）ElasticSearch架构概述

ElasticSearch是现在技术前沿的大数据引擎，常见的组合有ES+Logstash+Kibana作为一套成熟的日志系统，其中Logstash是ETL工具，Kibana是数据分析展示平台。ES让人惊艳的是他强大的搜索相关能力和灾备策略，ES开放了一些接口供开发者研发自己的插件，ES结合中文分词的插件会给ES的搜索和分析起到很大的推动作用。ElasticSearch是使用开源全文检索库ApacheLucene进行索引和搜索的，说架构必须和Lucene的一些东西打交道。

关于Lucene：

ApacheLucene将写入索引的所有信息组织成一种倒排索引（Inverted Index）的结构之中，该结构是种将词项映射到文档的数据结构。其工作方式与传统的关系数据库不同，大致来说倒排索引是面向词项而不是面向文档的。且Lucene索引之中还存储了很多其他的信息，如词向量等等，每个Lucene都是由多个段构成的，每个段只会被创建一次但会被查询多次，段一旦创建就不会再被修改。多个段会在段合并的阶段合并在一起，何时合并由Lucene的内在机制决定，段合并后数量会变少，但是相应的段本身会变大。段合并的过程是非常消耗I/O的，且与之同时会有些不再使用的信息被清理掉。在Lucene中，将数据转化为倒排索引，将完整串转化为可用于搜索的词项的过程叫做分析。文本分析由分析器（Analyzer）来执行，分析其由分词器（Tokenizer），过滤器（Filter）和字符映射器（Character Mapper）组成，其各个功能显而易见。除此之外，Lucene有自己的一套完整的查询语言来帮助我们进行搜索和读写。

[注]ES中的索引指的是查询/寻址时URI中的一个字段如：[host]：[port（9200）]/[index]/[type]/[ID]?[option]，而Lucene中的索引更多地和ES中的分片的概念相对应。

回到ElasticSearch，ES的架构遵循的设计理念有以下几个特征：

1. 合理的默认配置：只需修改节点中的Yaml配置文件，就可以迅捷配置。这和Spring4中对配置的简化有相似的地方。

2. 分布式工作模式：ES强大的Zen发现机制不仅支持组广播也支持点单播，且有“知一点即知天下”之妙。

3. 对等架构：节点之间自动备份分片，且使分片本身和样本之间尽量”远离“，可以避免单点故障。且Master节点和Data节点几乎完全等价。

4. 易于向集群扩充新节点：大大简化研发或运维将新节点加入集群所需的工作。

5. 不对索引中的数据结构增加任何限制：ES支持在一个索引之中存在多种数据类型。

6. 准实时：搜索和版本同步，由于ES是分布式应用，一个重大的挑战就是一致性问题，无论索引还是文档数据，然而事实证明ES表现优秀。

（一）分片策略

选择合适的分片数和副本数。ES的分片分为两种，主分片（Primary Shard）和副本（Replicas）。默认情况下，ES会为每个索引创建5个分片，即使是在单机环境下，这种冗余被称作过度分配（Over Allocation），目前看来这么做完全没有必要，仅在散布文档到分片和处理查询的过程中就增加了更多的复杂性，好在ES的优秀性能掩盖了这一点。假设一个索引由一个分片构成，那么当索引的大小超过单个节点的容量的时候，ES不能将索引分割成多份，因此必须在创建索引的时候就指定好需要的分片数量。此时我们所能做的就是创建一个新的索引，并在初始设定之中指定这个索引拥有更多的分片。反之如果过度分配，就增大了Lucene在合并分片查询结果时的复杂度，从而增大了耗时，所以我们得到了以下结论：

我们应该使用最少的分片！

主分片，副本和节点最大数之间数量存在以下关系：

节点数<=主分片数*（副本数+1）

控制分片分配行为。以上是在创建每个索引的时候需要考虑的优化方法，然而在索引已创建好的前提下，是否就是没有办法从分片的角度提高了性能了呢？当然不是，首先能做的是调整分片分配器的类型，具体是在elasticsearch.yml中设置cluster.routing.allocation.type属性，共有两种分片器even_shard,balanced（默认）。even_shard是尽量保证每个节点都具有相同数量的分片，balanced是基于可控制的权重进行分配，相对于前一个分配器，它更暴漏了一些参数而引入调整分配过程的能力。

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

（二）路由优化

ES中所谓的路由和IP网络不同，是一个类似于Tag的东西。在创建文档的时候，可以通过字段为文档增加一个路由属性的Tag。ES内在机制决定了拥有相同路由属性的文档，一定会被分配到同一个分片上，无论是主分片还是副本。那么，在查询的过程中，一旦指定了感兴趣的路由属性，ES就可以直接到相应的分片所在的机器上进行搜索，而避免了复杂的分布式协同的一些工作，从而提升了ES的性能。于此同时，假设机器1上存有路由属性A的文档，机器2上存有路由属性为B的文档，那么我在查询的时候一旦指定目标路由属性为A，即使机器2故障瘫痪，对机器1构不成很大影响，所以这么做对灾况下的查询也提出了解决方案。所谓的路由，本质上是一个分桶（Bucketing）操作。当然，查询中也可以指定多个路由属性，机制大同小异。

（三）ES上的GC调优

ElasticSearch本质上是个Java程序，所以配置JVM垃圾回收器本身也是一个很有意义的工作。我们使用JVM的Xms和Xmx参数来提供指定内存大小，本质上提供的是JVM的堆空间大小，当JVM的堆空间不足的时候就会触发致命的OutOfMemoryException。这意味着要么内存不足，要么出现了内存泄露。处理GC问题，首先要确定问题的源头，一般有两种方案：

1. 开启ElasticSearch上的GC日志

2. 使用jstat命令

3. 生成内存Dump

关于第一条，在ES的配置文件elasticsearch.yml中有相关的属性可以配置，关于每个属性的用途这里当然说不完。

第二条，jstat命令可以帮助我们查看JVM堆中各个区的使用情况和GC的耗时情况。

第三条，最后的办法就是将JVM的堆空间转储到文件中去，实质上是对JVM堆空间的一个快照。

想了解更多关于JVM本身GC调优方法请参考：http://www.oracle.com/technetwork/java/javase/gc-tuning-6-140523.html

另外，通过修改ES节点的启动参数，也可以调整GC的方式，但是实质上和上述方法是等同的。

（四）避免内存交换

这一点很简单，由于操作系统的虚拟内存页交换机制，会给性能带来障碍，如数据写满内存会写入Linux中的Swap分区。

可以通过在elasticsearch.yml文件中的bootstrap.mlockall设置为true来实现，但是需要管理员权限，需要修改操作系统的相关配置文件。

（五）控制索引合并

上文提到过，ES中的分片和副本本质上都是Lucene索引，而Lucene索引又基于多个索引段构建（至少一个），索引文件中的绝大多数都是只被写一次，读多次，在Lucene内在机制控制下，当满足某种条件的时候多个索引段会被合并到一个更大的索引段，而那些旧的索引段会被抛弃并移除磁盘，这个操作叫做段合并。

Lucene要执行段合并的理由很简单充分：索引段粒度越小，查询性能越低且耗费的内存越多。频繁的文档更改操作会导致大量的小索引段，从而导致文件句柄打开过多的问题，如修改系统配置，增大系统允许的最大文件打开数。总的来讲，当索引段由多一个合并为一个的时候，会减少索引段的数量从而提高ES性能。对于研发者来讲，我们所能做的就是选择合适的合并策略，尽管段合并完全是Lucene的任务，但随着Lucene开放更多配置借口，新版本的ES还是提供了三种合并的策略tiered，log_byte_size，log_doc。另外，ES也提供了两种Lucene索引段合并的调度器：concurrent和serial。其中各者具体区别，这里暂不赘述，只是抛砖引玉。
========================================================================
ES 手册

如何提高ES的性能

不要返回较大的结果集

ES是设计成一个搜索引擎的，只擅长返回匹配查询较少文档，如果需要返回非常多的文档需要使用Scroll。

避免稀疏

因为ES是基于Lucene来索引和存储数据的，所以对稠密的数据更有效。Lucene能够有效的确定文档是通过一个整数的文档id，无论有没有数据都会话费一个字节存储id。稀疏主要影响norms和doc_values，一些可以避免稀疏的推荐：

避免将不相关的数据放到相同的索引中

规范的文档结构

使用相同的字段名来保存同样的数据。

避免类型

不用norms和doc_values在稀疏字段

调整索引速度

使用bulk请求

并且每个请求不超过几十M，因为太大会导致内存使用过大

使用 multiple workers/threads发送数据到ES

多进程或者线程，如果看到TOO_MANY_REQUESTS (429)和EsRejectedExecutionException则说明ES跟不上索引的速度，当集群的I/O或者CPU饱和就得到了工作者的数量。

增加刷新间隔

index.refresh_interval默认是1s，可以改成30s以减少合并压力。

在加载大量数据时候可以暂时不用refresh和repliccas

index.refresh_interval to -1 and index.number_of_replicas to 0

禁用swapping

禁用swapping

给文件缓存分配内存

缓存是用来缓存I/O操作的，至少用一般的内存来运行ES文件缓存。

使用更快的硬件
- 使用SSD作为存储设备。
- 使用本地存储，避免使用NFS或者SMB
- 注意使用虚拟存储，比如亚马逊的EBS
索引缓冲大小

indices.memory.index_buffer_size通常是JVM的0.1，确保他足够处理至多512MB的索引。

调整搜索速度

给文件系统缓存大内存

至少给可用内存的一半到文件系统缓存。

使用更快的硬件
- 使用SSD作为存储设备。
- 使用性能更好的CPU，高并发
- 使用本地存储，避免使用NFS或者SMB
- 注意使用虚拟存储，比如亚马逊的EBS
文档建模

避免链接，嵌套会使查询慢几倍，而亲自关系能使查询慢几百倍，所以如果同样的问题可以通过没有链接的非规范回答就可以提升速度。

预索引数据

不明觉厉

映射

数值型数据不一定要映射成整形或者长整型

避免scripts

如果实在要使用，就用painless和expressions

强势合并只读索引

https://www.elastic.co/guide/en/elasticsearch/reference/master/indices-forcemerge.html
不要强势合并正在写的索引

准备全局顺序

准备文件系统缓存

index.store.preload，如果内存不是很大会使搜索变得缓慢。

调整磁盘使用

禁用不需要的功能
- 不需要过滤时可以禁用索引“index”：false
- 如果你不需要text字段的score，可以禁用”norms”：false
- 如果不需要短语查询可以不索引positions"indexe_options":"freqs"
不用默认的动态字符串匹配

不要使用_all

使用best_compression

使用最小的足够用的数值类型

byte,short,integer,long
half_float,float,double

https://www.elastic.co/guide/en/elasticsearch/reference/master/indices-create-index.html#mappings
https://www.elastic.co/guide/en/elasticsearch/reference/master/index-modules.html#dynamic-index-settings
https://www.elastic.co/guide/en/elasticsearch/reference/master/search-request-scroll.html