Elasticsearch 遇到的问题汇总

 

目录

一 名词解释

2 问题及分析

     2.1 批量写入性能

     2.2 查询性能

---

 

前段时间一直在研究ES（Elasticsearch简称）集群，故难免会遇到一些问题，现就遇到的问题做下深入的分析和总结。在分析之前我们先对ES集群中涉及到的关键名词进行了解。

一 名词解释

   1）shards

     shards指的是索引分片的大小，一个大的索引被分为若干个分片后，存储于不同的节点上以构成分布式搜索。分片不一定是越多越好，分片数量要按自己的业务要求来选定，且单台机器的分片数最好不要超过三个。如果这个值设置太大会对集群索引管理带来压力从而影响查询性能。

   2）replicas

     指代的是索引的副本数量，副本数虽然有利于集群的冗余，但是数量多了大大影响了集群的写入性能，且消耗集群更多的存储。为均衡考虑一般将此值设置为1

   3）recovery

     从字面意思可知，它代表的是数据的恢复，当索引主分片丢失时会从从分片去恢复数据，如果集群的内部资源都用于恢复数据，将会对集群的写入性能和查询性能带来很大的影响。故在恢复数据时，集群中可以指定恢复数据速率大小。

   4）索引结构名词

       （1）_all

             此字段的含义是指Elasticsearch 将会通过_all字段存储其他字段中的值，查询时只需给定待查询字段的值而不需要给定字段名称。此字段默认开启，如果不禁用_all，会使集群的索引变大，故一般情况下要禁用此字段。

       （2）_source

           此字段指在生成索引时会存储原始传给ES的Json数据, 此字段有如下功能：1 可以作为高亮功能的数据源、2 可以根据自己需求去包含或者排除某些字段。

此字段是默认开启的，如果考虑到存储性能和ES写入性能，可以禁用此字段或者根据此字段去包含或者排除不需要存储的字段。

        （3）doc_values

          此字段是在索引时建立的，而不是搜索的时候。当通过非反向的反向索引搜索时候（倒排索引），如果以in-memort方式，内存中的字段数据必须被频繁的读写，而doc_vaules 是预先建立的，并能更快的初始化。一般面对的场景有：1 索引量大的搜索，访问fielddata会比较缓慢，设置doc_values会有显著的效果，在大量请求的时候，你甚至不会注意到你的搜索会变慢。结合更快的垃圾回收机制和初始化时间，你会留意到搜索性能会得到有效提升。 2 文件系统的缓存空间越多，docvalue的性能会越好。如果文件都是docvalues并且都位于文件系统的缓存中，那么访问这些文件的速度几乎与访问内存媲美的。而文件系统缓存由内核控制而非JVM。此字段在ES1.x版本中默认是关闭的，但在ES2.x版本中默认开启。

          (4) store

          此字段指的是指定索引中某个字段需不需要单独存储，如果设置索引中feild2的store属性为true时，在查询时如果指定查询feild2字段，则ES集群会辨认此字段被单独存储，将不会从_source中加载数据，而是从feild2的存储块中取，此字段设置为true的场景：如果你的文档长度很长，存储_source或者从_source中获取field的代价很大，你可以显式的将某些field的store属性设置为yes。缺点如上边所说：假设你存储了10个field，而如果想获取这10个field的值，则需要多次的io，对集群性能影响很大。如果字段的store属性设置为true对集群的存储和写入性能有很大的影响。

        （5）fielddata_fields

           此字段例子如下：

            {  "query" : { 

                             ...

                       },

                  "fielddata_fields" : ["test1", "test2"] 

             }

        它的主要作用是返回指定的字段且该字段未被单独存储时(store的属性设置为no)，使用此字段会存在大量的内存消耗，使用时必须注意，指定的字段不能太多。突然联想到fields字段具有类似的功能，但是fields只能返回_source中的字段。

         

        （6）template

        从字段指可以为一个索引创建一个模板，此原理和设计模式中的模板模式类似。

          (7) _ttl

         此字段表示索引的生存时间，如果启用此字段默认，默认是对索引数据保存30天，由于启用此字段后，其会定时循环扫描ES集群看是否有索引或者类型超过了生存时间，故如果不禁止此字段会对集群性能有部分影响，

        

2 问题及分析

  2.1 批量写入性能

    离线数据写入ES集群对写入速度要求比较高，故一直在追寻影响批量写入性能的原因。刚开始时一直在怀疑是ES中机器和网络传输性能影响，经过测试排查后发现当离线数据写入ES集群时，每台机器的各项负载都比较低，故此原因直接排除。故唯一的可能是ES集群批量接受数据性能的影响，影响ES集群写入速度可以分为以下几个方面：         

    1）索引的结构

         索引的结构的对数据的写入速度影响最大,在上节的名词解释了使用_source、store、_all、doc_value会对写入性能有很大影响，故可以考虑上节介绍去改变索引结构去提升写入性能。

    2)  副本数量

       写入索引数据时，会先向相应的索引分片写入数据，然后其分片同步向其副本写入数据，如果索引副本写入完成，整个写入过程才完成。如果副本过多会对写入速度有影响。

    3）批量接受队列大小

       集群接受批量请求队列如果过于小，则其余数据会一直等待，从而引起客户端写入程序超时异常，客户端程序捕获超时异常后会重传数据，故整个过程对写入速度有一定的影响。

    4）索引段合并

      在索引shard中,会存在索引段，当段文件过多时，ES集群内部会自动段合并，段合并会消耗集群的性能，故对集群的写入速度有一些影响。一般情况下设置索引段文件数为默认的值，不仅加快查询速度也提升集群批量写入性能。也可以指定段合并的速率来控制合并消耗的资源。

    5）减少索引shard刷新间隔和禁止_ttl字段

     索引shard刷新和启用_ttl字段会消耗集群资源，故对批量写入性能存在影响

 

2.2 查询性能

    要想提升ES集群的查询性能必须了解数据的索引过程

   1) ES索引的过程(转载网上)

   ES索引的过程到相对Lucene的索引过程多了分布式数据的扩展，而ES集群主要是用tranlog进行各节点之间的数据平衡。所以从上我可以通过索引的settings进行第一优化：   

  “index.translog.flush_threshold_ops”: “100000″  

  “index.refresh_interval”: “-1″

 这两个参数第一是到tranlog数据达到多少条进行平衡，默认为5000，而这个过程相对而言是比较浪费时间和资源的。所以我们可以将这个值调大一些还是设为-1关闭，进而手动进行tranlog平衡。第二参数是刷新频率，默认为120s是指索引在生命周期内定时刷新，一但有数据进来能refresh像lucene里面commit,我们知道当数据addDoucment会，还不能检索到要commit之后才能行数据的检索所以可以将其关闭，在最初索引完后手动refresh一之，然后将索引setting里面的index.refresh_interval参数按需求进行修改，从而可以提高索引过程效率。另外的知道ES索引过程中如果有副本存在，数据也会马上同步到副本中去。我个人建议在索引过程中将副本数设为0，待索引完成后将副本数按需量改回来，这样也可以提高索引效率。

 “number_of_replicas”: 0

上面聊了一次索引过程的优化之后，我们再来聊一下检索速度比较慢的问题，其实检索速度快度与索引质量有很大的关系。而索引质量的好坏与很多因素有关。

  2）影响副本的性能因素

     （1）分片数

          在第一节说到，分片数的大小对写入和查询性能影响。

       (2）副本数

         不要误解副本数越多，对查询性能帮助越大，经过测试发现随副本数的增加检索速度会有微量的下降。

    （3）分词

       现阶段ES项目中尚未接触到分词，可以肯定的是选用不同的词库分词，索引速度是有影响。

    （4）索引段

       索引段即lucene中的segments概念，我们知道ES索引过程中会refresh和tranlog也就是说我们在索引过程中segments number不至一个。而segments number与检索是有直接联系的，segments number越多检索越慢，而将segments numbers 有可能的情况下保证为1这将可以提到将近一半的检索速度。

      max_num_segments =1 

       (5) 删除文档

       经过一段时间测试发现，执行删除命令时，虽然索引名称删除了，但是真实的数据没有删除，其实在ES集群内部在删除时会存在大量的段合并，此合并会消耗很多集群资源，从而造成索引速度变慢。解决办法

    $ curl -XPOST 'http://localhost:9200/twitter/_optimize? only_expunge_deletes =true'  这样就直接删除了文档了。

 

接下如再遇到ES其他问题，将会在此文档更新！