分布式系统框架(V2.0) 轻松承载百亿数据,千万流量!讨论专区 - 源码下载 - 官方教程

HttpHelper爬虫框架(V2.4-含.netcore) HttpHelper官方出品,爬虫框架讨论区 - 源码下载 - 在线测试和代码生成

HttpHelper爬虫类(V2.0) 开源的爬虫类,支持多种模式和属性 源码 - 代码生成器 - 讨论区 - 教程- 例子

苏飞论坛

 找回密码
 马上注册

QQ登录

只需一步,快速开始

查看: 377|回复: 2

[Elasticsearch] Elasticsearch7.12写入速度深度优化

[复制链接]
发表于 2021-12-31 11:02:46 | 显示全部楼层 |阅读模式
开通SVIP会员,免费下载本站所有源码,不限次数据,不限时间
我们都知道Elasticsearch7.12是一个大数据框架,很多公司因为业务的需要,需要在短时间内大量的写入,或者转移数据
有时候是因为一开始的数据结构不完善,但后来为了处理数据格式从头到尾的刷数据

正常情况下我们是写一个循环,从A取写入B这样的方式,但因为数据量大会变的非常的慢

这个时候我们需要处理几点即可达到非常高的效率

第一点,设置查询缓存时间
这个简单具体的可以参加我这个文章
http://www.sufeinet.com/thread-40860-1-1.html
[C#] 纯文本查看 复制代码
index.refresh_interval: 120s


这里设置完成之后会大大的提高查询速度,只有查的快才能写的快

第二步,批量写入,这里不需要多说,没有什么可说的就是用批量写入,一次性写100条,和一次性写一条的速度基本一样,但你循环链接100次,和一次的差别就太大了,这里正常可以提高100倍以上

第三步,配置刷新硬盘的时间,就是定期更新硬盘,并不是时时的。

这里设置三个参加即可
[C#] 纯文本查看 复制代码
index.translog.durability: async 
index.translog.sync_interval: 120s 
index.translog.flush_threshold_size: 1024mb 


网上不还有不少人说其他的,但我认为其他的都是次要的,劳民伤财,效果基本上跟没有差不多,只要改进这三点速度基本上达到极限了。



 楼主| 发表于 2021-12-31 11:27:35 | 显示全部楼层
开通SVIP会员,免费下载本站所有源码,不限次数据,不限时间
补充一个思路,如果你的数据量非常大,可以写个循环比如时间每次取一天的,然后取完继续取第二天的,以此类推即可,这样可以有效的保障查询速度,
 楼主| 发表于 2021-12-31 14:46:27 | 显示全部楼层
开通SVIP会员,免费下载本站所有源码,不限次数据,不限时间
1 前言

   在集群正常运行的前提下,如果是集群首次批量导入数据时,可以将副本数设置为0,导入完毕后再将副本数调整为正常值,这样副分片就只需要复制,节约了构建索引的时间。
提升写入速度从以下几方面入手:

  • 加大translog flush间隔,目的是降低iops(iops指的是每秒的输入输出量(或读写次数),是衡量磁盘性能的主要指标之一)、writeblock。
  • 加大index refresh间隔,除了降低I/O,更重要的是降低了segment merge频率。
  • 调整bulk请求。
  • 优化磁盘间的任务均匀情况,将shard尽量均匀分布到物理主机的 各个磁盘。
  • 优化节点间的任务分布,将任务尽量均匀地发到各节点。
  • 优化Lucene层建立索引的过程,目的是降低CPU占用率及I/O,例如,禁用_all字段

   为了更好理解上述优化策略,需要再复习一下几个概念:
flush:是指触发lucene commit,也就是将缓存中的数据写入到磁盘,并清空translog日志文件。
refresh: 是指从内存到文件系统缓存的过程,这样该文档就可以被搜索到,但是该文档还没有存储到磁盘上,如果机器宕机了,数据就会丢失。

2 translog flush间隔调整2.1 index.translog.durability

   在默认设置下,translog的持久化策略为:每个请求 都“flush”。
对应配置项如下:

[C#] 纯文本查看 复制代码
index.translog.durability: request

   这是影响 ES 写入速度的最大因素。但是只有这样,写操作才有可 能是可靠的。如果系统可以接受一定概率的数据丢失(例如,数据写入 主分片成功,尚未复制到副分片时,主机断电。由于数据既没有刷到 Lucene,translog也没有刷盘,恢复时translog中没有这个数据,数据丢失,则调整translog持久化策略为周期性和一定大小的时候“flush”,例 如:

[C#] 纯文本查看 复制代码
index.translog.durability: async

   设置为async表示translog的刷盘策略按sync_interval配置指定的时间 周期进行。

[C#] 纯文本查看 复制代码
index.translog.sync_interval: 120s

   加大translog刷盘间隔时间。默认为5s,不可低于100ms。

2.2 index.translog.flush_threshold_sizeindex.translog.flush_threshold_size: 1024mb

   超过这个大小会导致refresh操作,产生新的Lucene分段。默认值为 512MB。

3 索引刷新间隔refresh_interval

   默认情况下索引的refresh_interval为1秒,这意味着数据写1秒后就 可以被搜索到,每次索引的refresh会产生一个新的Lucene段,Lucene段即为segment,segment在复合一定条件后,会自动合并,因此这会导致频繁的segment merge行为(),如果不需要这么高的搜索实时性,应该降低 索引refresh周期,例如:

  • [C#] 纯文本查看 复制代码
    index.refresh_interval: 120s

4 段合并优化

   segment merge操作对系统I/O和内存占用都比较高,从ES 2.0开始, merge行为不再由ES控制,而是由Lucene控制,调整开关:

  • [C#] 纯文本查看 复制代码
    index.merge.scheduler.max_thread_count index.merge.policy.*

   最大线程数max_thread_count的默认值如下:

  • [C#] 纯文本查看 复制代码
    Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors()/2))

   以上是一个比较理想的值,如果只有一块硬盘并且非 SSD,则应该 把它设置为1,因为在旋转存储介质上并发写,由于寻址的原因,只会 降低写入速度。
   merge策略index.merge.policy有三种:

tiered(默认策略); log_byete_size; log_doc。

   目前我们使用默认策略,但是对策略的参数进行了一些调整。 索引创建时合并策略就已确定 ,不能更改,但是可以动态更新策略参数,可以不做此项调整。如果堆栈经常有很多merge,则可以尝试调 整以下策略配置:

  • [C#] 纯文本查看 复制代码
    index.merge.policy.segments_per_tier

   该属性指定了每层分段的数量,取值越小则最终segment越少,因此需要merge的操作更多,可以考虑适当增加此值。默认为10,,其应该 大于等于index.merge.policy.max_merge_at_once。

[C#] 纯文本查看 复制代码
index.merge.policy.max_merge_at_once。  
      

    表示默认一次最多归并segment的个数,默认也为 10 个 segment。

  • [C#] 纯文本查看 复制代码
    index.merge.policy.max_merged_segment

指定了单个segment的最大容量,默认为5GB,可以考虑适当降低此值。

5 indexing buffer

    indexing buffer在为doc建立索引时使用,当缓冲满时会刷入磁盘, 生成一个新的segment,这是除refresh_interval刷新索引外,另一个生成 新segment的机会。
    每个shard有自己的indexing buffer,下面的这个buffer 大小的配置需要除以这个节点上所有shard的数量:

  • [C#] 纯文本查看 复制代码
    indices.memory.index_buffer_size 默认为整个堆空间的10%。
    [*] indices.memory.min_index_buffer_size 默认为48MB。
    [*] indices.memory.max_index_buffer_size 默认为无限制。

    在执行大量的索引操作时,indices.memory.index_buffer_size的默认 设置可能不够,这和可用堆内存、单节点上的shard数量相关,可以考虑适当增大该值,增大该值,减少segment,就会减少merge。

6 使用bulk请求

    批量写比一个索引请求只写单个文档的效率高得多,但是要注意 bulk请求的整体字节数不要太大,太大的请求可能会给集群带来内存压 力,因此每个请求最好避免超过几十兆字节,即使较大的请求看上去执 行得更好。

6.1 bulk线程池和队列

    建立索引的过程属于计算密集型任务,应该使用固定大小的线程池 配置,来不及处理的任务放入队列。线程池最大线程数量应配置为CPU 核心数+1,这也是bulk线程池的默认设置,可以避免过多的上下文切 换。队列大小可以适当增加,但一定要严格控制大小,过大的队列导致 较高的GC压力,并可能导致FGC频繁发生。

6.2 并发执行bulk请求

    bulk写请求是个长任务,为了给系统增加足够的写入压力,写入过程应该多个客户端、多线程地并行执行,如果要验证系统的极限写入能 力,那么目标就是把CPU压满。磁盘util、内存等一般都不是瓶颈。如果CPU没有压满,则应该提高写入端的并发数量。
    但是要注意bulk线 程池队列的reject情况,出现reject代表ES的bulk队列已满,客户端收到429错误(TOO_MANY_REQUESTS)。不可忽略这个异常,否则写入系 统的数据会少于预期。即使客户端正确处理了429错误,我们仍然应该尽量避免产生reject。
    因此,在评估极限的写入能力时,客户端的极限写入并发量应该控制在不产生reject前提下的最大值为宜。

7 磁盘间的任务均衡

    如果部署方案是为path.data配置多个路径来使用多块磁盘,则ES在 分配shard时,落到各磁盘上的 shard 可能并不均匀,这种不均匀可能会导致某些磁盘繁忙,利用率在较长时间内持续达到100%。这种不均匀 达到一定程度会对写入性能产生负面影响。
    ES在处理多路径时,优先将shard分配到可用空间百分比最多的磁盘上,因此短时间内创建的shard可能被集中分配到这个磁盘上,即使可用空间是99%和98%的差别。如果单一的机制不能解决所有的场景,那么至少应该为不同场景准备多种选择。
    为此,我们为ES增加了两种策略。

简单轮询:在系统初始阶段,简单轮询的效果是最均匀的。基于可用空间的动态加权轮询:以可用空间作为权重,在磁盘之间加权轮询。

8 节点间的任务均衡

    为了节点间的任务尽量均衡,数据写入客户端应该把bulk请求轮询 发送到各个节点。 当使用Java API或REST API的bulk接口发送数据时,客户端将会轮 询发送到集群节点,节点列表取决于:

使用Java API时,当设置client.transport.sniff为true(默认为false) 时,列表为所有数据节点,否则节点列表为构建客户端对象时传入的节 点列表。使用REST API时,列表为构建对象时添加进去的节点。

    在此建议使用REST API,Java API会在未来的版本中废弃,REST API有良好的版本兼容性好。理论上,Java API在序列化上有性能优 势,但是只有在吞吐量非常大时才值得考虑序列化的开销带来的影响, 通常搜索并不是高吞吐量的业务。
    要观察bulk请求在不同节点间的均衡性,可以通过cat接口观察bulk 线程池和队列情况: _cat/thread_pool

9 索引过程调整和优化9.1 自动生成doc ID

    通过ES写入流程可以看出,写入doc时如果外部指定了id,则ES会先尝试读取原来doc的版本号,以判断是否需要更新。这会涉及一次读取磁盘的操作,通过自动生成doc ID可以避免这个环节。

9.2 调整字段Mappings
  • 减少字段数量,对于不需要建立索引的字段,不写入ES。
  • 将不需要建立索引的字段index属性设置为not_analyzed或no。
    对字段不分词,或者不索引,可以减少很多运算操作,降低CPU占用。 尤其是binary类型,默认情况下占用CPU非常高,而这种类型进行分词
    通常没有什么意义。
  • 减少字段内容长度,如果原始数据的大段内容无须全部建立 索引,则可以尽量减少不必要的内容。
  • 使用不同的分析器(analyzer),不同的分析器在索引过程中 运算复杂度也有较大的差异。
9.3 调整_source字段

    _source 字段用于存储 doc 原始数据,对于部分不需要存储的字 段,可以通过 includes excludes过滤,或者将_source禁用,一般用于索 引和数据分离。 这样可以降低 I/O 的压力,不过实际场景中大多不会禁用_source,
    而即使过滤掉某些字段,对于写入速度的提升作用也不大,满负荷写入情况下,基本是 CPU先跑满了,瓶颈在于CPU。

9.4 禁用_all字段

    从ES 6.0开始,_all字段默认为不启用,而在此前的版本中,_all字 段默认是开启的。_all字段中包含所有字段分词后的关键词,作用是可以在搜索的时候不指定特定字段,从所有字段中检索。ES 6.0默认禁用 _all字段主要有以下几点原因:

  • 由于需要从其他的全部字段复制所有字段值,导致_all字段占用非常大的空间。
  • _all 字段有自己的分析器,在进行某些查询时(例如,同义词),结果不符合预期,因为没有匹配同一个分析器。
  • 由于数据重复引起的额外建立索引的开销。
  • ·想要调试时,其内容不容易检查。
  • 有些用户甚至不知道存在这个字段,导致了查询混乱。

    禁用_all字段可以明显降低对CPU和I/O的压力。

9.5 对Analyzed的字段禁用Norms

    Norms用于在搜索时计算doc的评分,如果不需要评分,则可以将其 禁用:

  • [C#] 纯文本查看 复制代码
    "title":
                     {
                             "type": "string",
                             "norms": 
                             {
                                     "enabled": false
                             }
                     }

9.6 index_options 设置

    index_options用于控制在建立倒排索引过程中,哪些内容会被添加到倒排索引,例如,doc数量、词频、positions、offsets等信息,优化这些设置可以一定程度降低索引过程中的运算任务,节省CPU占用率。 不过在实际场景中,通常很难确定业务将来会不会用到这些信息, 除非一开始方案就明确是这样设计的。


您需要登录后才可以回帖 登录 | 马上注册

本版积分规则

QQ|手机版|小黑屋|手机版|联系我们|关于我们|广告合作|苏飞论坛 ( 豫ICP备17001017号-1)

GMT+8, 2022-1-24 13:59

© 2014-2021

快速回复 返回顶部 返回列表