Elasticsearch调优

最近一直在着手优化公司某些业务的大数据的查询。
数据量级大约在每天110亿个doc左右，并且通常要对最近两天的数据，并对这两天的数据做一定的处理，query的响应时间比较长，因此需要优化query api响应时间

但是在架构层面从一开始的mapping、分片数量、节点等各种配置上已经确定了，一些修改对数据影响比较大，所以只能在一些其他方面做一些优化

结合之前工作中对Es的使用来说，总结了以下关于Es的优化建议，或者说是搭建Es集群之前就应该了解的，从配置开始就做符合自身业务的配置，而不是等到搜索时出现问题再优化，这个时候其实优化的空间已经不大了。

主要从以下几个方面进行优化：

架构层面

• 合理的分配角色和每个节点的配置，在部署集群的时候，应该根据多方面的情况去评估集群需要多大规模去支撑业务。这个是需要根据在当前的硬件环境下测试数据的写入和搜索性能，然后根据你目前的业务参数来动态评估的，比如：

  • 业务数据的总量、每天的增量
  • 查询的并发以及QPS
  • 峰值的请求量

• 节点并非越多越好，会增加主节点的压力

• 分片并非越多越好，从deep pageing 的角度来说，分片越多，JVM开销越大，负载均衡（协调）节点的转发压力也越大，查询速度也越慢。单个分片也并非越大越好，一般来说单个分片大小控制在30-50GB。

• Mpping优化：

  • 优化字段的类型，关闭对业务无用的字段
  • 尽量不要使用dynamic mapping分片大小

写入性能调优：

• 增加flush时间间隔，目的是减小数据写入磁盘的频率，减小磁盘IO

• 增加refresh_interval的参数值，目的是减少segment文件的创建，减少segment的merge次数，merge是发生在jvm中的，有可能导致full GC，增加refresh会降低搜索的实时性。

• 增加Buffer大小，本质也是减小refresh的时间间隔，因为导致segment文件创建的原因不仅有时间阈值，还有buffer空间大小，写满了也会创建。 默认最小值 48MB < 默认值 堆空间的10% < 默认最大无限制

• 大批量的数据写入尽量控制在低检索请求的时间段，大批量的写入请求越集中越好。

  • 第一是减小读写之间的资源抢占，读写分离；
  • 第二，当检索请求数量很少的时候，可以减少甚至完全删除副本分片，关闭segment的自动创建以达到高效利用内存的目的，因为副本的存在会导致主从之间频繁的进行数据同步，大大增加服务器的资源占用。

• Lucene的数据的fsync是发生在OS cache的，要给OS cache预留足够的内从大小，这点有知道JVM调优的人应该比较熟悉，这个我之前写过一点经验，可以参考。垃圾回收及JVM调优

• 通用最小化算法，能用更小的字段类型就用更小的，keyword类型比int更快，

• ignore_above：字段保留的长度，越小越好

• 调整_source字段，通过include和exclude过滤

• store：开辟另一块存储空间，可以节省带宽

  注意：source设置为false，则不存储元数据，可以节省磁盘，并且不影响搜索。但是禁用_source必须三思而后行：

  1. update，update_by_query和reindex不可用。

  2. 高亮失效

  3. reindex失效，原本可以修改的mapping部分参数将无法修改，并且无法升级索引

  4. 无法查看元数据和聚合搜索

  5. 影响索引的容灾能力

• 禁用_all字段：_all字段的包含所有字段分词后的Term，作用是可以在搜索时不指定特定字段，从所有字段中检索，ES 6.0之前需要手动关闭

• 关闭Norms字段：计算评分用的，如果你确定当前字段将来不需要计算评分，设置false可以节省大量的磁盘空间，有助于提升性能。常见的比如filter和agg字段，都可以设为关闭。

• 关闭index_options（谨慎使用，高端操作）：词设置用于在index time过程中哪些内容会被添加到倒排索引的文件中，例如TF，docCount、postion、offsets等，减少option的选项可以减少在创建索引时的CPU占用率，不过在实际场景中很难确定业务是否会用到这些信息，除非是在一开始就非常确定用不到，否则不建议删除

搜索速度调优

• 禁用swap
• 使用filter代替query
• 避免深度分页，避免单页数据过大，可以参考百度或者淘宝的做法。es提供两种解决方案scroll search和search after
• 注意关于index type的使用
• 避免使用稀疏数据
• 避免单索引业务重耦合
• 命名规范
• 冷热分离的架构设计
• fielddata：搜索时正排索引，doc_value为index time正排索引。
• enabled：是否创建倒排索引
• doc_values：正排索引，对于不需要聚合的字段，关闭正排索引可节省资源，提高查询速度
• 开启自适应副本选择（ARS），6.1版本支持，7.0默认开启，

硬件优化

es的默认配置是一个非常合理的默认配置，绝大多数情况下是不需要修改的，如果不理解某项配置的含义，没有经过验证就贸然修改默认配置，可能造成严重的后果。比如max_result_window这个设置，默认值是1W，这个设置是分页数据每页最大返回的数据量，冒然修改为较大值会导致OOM。ES没有银弹，不可能通过修改某个配置从而大幅提升ES的性能，通常出厂配置里大部分设置已经是最优配置，只有少数和具体的业务相关的设置，事先无法给出最好的默认配置，这些可能是需要我们手动去设置的。关于配置文件，如果你做不到彻底明白配置的含义，不要随意修改。

jvm heap分配：7.6版本默认1GB，这个值太小，很容易导致OOM。Jvm heap大小不要超过物理内存的50%，最大也不要超过32GB（compressed oop），它可用于其内部缓存的内存就越多，但可供操作系统用于文件系统缓存的内存就越少，heap过大会导致GC时间过长

• 节点：
  i.相同角色的节点，避免使用差异较大的服务器配置，
  ii.避免使用“超大杯”服务器（SS：Super Server），比如128核CPU，1 T的内存，2T的固态硬盘。这样可能会产生较大的资源浪费。
  iii.等量的配置，使用较少的物理机好于使用较多的虚拟机。比如一个一个五台4核16G的物理机，好于10甚至11台2核8G的虚拟机，这里不仅仅是虚拟机本身可能也会消耗一部分性能的问题，也涉及数据安全的问题。
  iv.避免在同一台服务器上部署多个节点，会增加集群管理的难度。

• 内存：

  根据业务量不同，内存的需求也不同，一般生产建议不要少于16G。ES是比较依赖内存的，并且对内存的消耗也很大，内存对ES的重要性甚至是高于CPU的，所以即使是数据量不大的业务，为了保证服务的稳定性，在满足业务需求的前提下，我们仍需考虑留有不少于20%的冗余性能。一般来说，按照百万级、千万级、亿级数据的索引，我们为每个节点分配的内存为16G/32G/64G就足够了，太大的内存，性价比就不是那么高了。

• 磁盘：

  对于ES来说，磁盘可能是最重要的了，因为数据都是存储在磁盘上的，当然这里说的磁盘指的是磁盘的性能。磁盘性能往往是硬件性能的瓶颈，木桶效应中的最短板。ES应用可能要面临不间断的大量的数据读取和写入。生产环境可以考虑把节点冷热分离，“热节点”使用SSD做存储，可以大幅提高系统性能；冷数据存储在机械硬盘中，降低成本。

• CPU：

  CPU对计算机而言可谓是最重要的硬件，但对于ES来说，可能不是他最依赖的配置，因为提升CPU配置可能不会像提升磁盘或者内存配置带来的性能收益更直接、显著。当然也不是说CPU的性能就不重要，只不过是说，在硬件成本预算一定的前提下，应该把更多的预算花在磁盘以及内存上面。通常来说单节点cpu 4核起步，不同角色的节点对CPU的要求也不同。服务器的CPU不需要太高的单核性能，更多的核心数和线程数意味着更高的并发处理能力。现在PC的配置8核都已经普及了，更不用说服务器了。

• 网络：

  ES是天生自带分布式属性的，并且ES的分布式系统是基于对等网络的，节点与节点之间的通信十分的频繁，延迟对于ES的用户体验是致命的，所以对于ES来说，低延迟的网络是非常有必要的。因此，使用扩地域的多个数据中心的方案是非常不可取的，ES可以容忍集群夸多个机房，可以有多个内网环境，支持跨AZ部署，但是不能接受多个机房跨地域构建集群，一旦发生了网络故障，集群可能直接GG，即使能够保证服务正常运行，维护这样（跨地域单个集群）的集群带来的额外成本可能远小于它带来的额外收益。

• 集群规划：没有最好的配置，只有最合适的配置。

• 在集群搭建之前，首先你要搞清楚，你ES cluster的使用目的是什么？主要应用于哪些场景，比如是用来存储事务日志，或者是站内搜索，或者是用于数据的聚合分析。针对不同的应用场景，应该指定不同的优化方案。

• 集群需要多少种配置（内存型/IO型/运算型），每种配置需要多少数量，通常需要和产品运营和运维测试商定，是业务量和服务器的承载能力而定，并留有一定的余量。

• 一个合理的ES集群配置应不少于5台服务器，避免脑裂时无法选举出新的Master节点的情况，另外可能还需要一些其他的单独的节点，比如ELK系统中的Kibana、Logstash等。

---

• ← Previous Post
• Next Post →

---

---