乐趣区

关于elasticsearch:ES性能调优与其它特性

一,写优化

  1. 批量提交。每次提交的数据量为多大能力达到最优,受文件大小,数据类型,网络状况,集群状态等因素影响,一般来说一次批处理的数据大小应从 5M-15M 开始逐步减少直到没有性能提花为止。
  2. 优化存储设置。尽量应用固态硬盘(solid state disk)
  3. 正当应用段合并。段合并的计算宏大,会耗费大量的 I /O,为了避免因段合并影响搜寻性能,咱们须要管制正当的合并速度,可通过参考进行配置
  4. 缩小 refresh 次数。这个须要依据理论状况来看,如果咱们对搜寻的时效性不高,则能够减少提早 refresh 的工夫,这样还能够缩小段合并的数量。
  5. 缩小 flush 的次数。这个同样须要结合实际状况来看,当 translog 的数量达到 512M 或 30 分钟时,会触发一次 flush,磁盘长久化比拟耗资源,咱们能够通过参考设置正当的值
  6. 缩小正本数。ES 正本数能够保障集群可用性,也能够减少搜寻的并发数,但却会重大升高写索引的效率,因为在写索引时须要把整个文档的内容都发给正本节点,而所有的正本节点都须要把索引过程反复进行一遍。所以正本数不可过多。

二,读优化

  1. 防止大后果集和深翻页。如果有 N 个分片,协同节点须要收集每个分片的前 from+size 条数据,而后将收集到的 Nx(from+size)条数据合并后再进行一次排序,最初从 from+ 1 开始返回 size 条数据。只有 N,from,size 其中有个值很大,这样的查问会耗费很多 CPU,效率低下。为解决这类问题,ES 提供了 scroll 和 scroll-scan 这两种形式。
    1) scroll 形式。与 search 申请每次返回一页数据不同,scroll 是为检索大量的后果(甚至所有的后果)而设计的,比方,咱们有一个批量查问的需要,要查问 1~100 页的数据,每页有 100 条数据,如果用 search 查问,则每次都要在每个分片上查问得分最高的 from+size 条数据,而后协同节点把收集到的 n×(from+size)条数据合并起来再进行一次排序。接着从 from+ 1 开始返回 size 条数据,并且要反复 100 次,随着 from 的增大,查问的速度越来越慢。
    但 scroll 的思路是:在各个分片上一次查问 10000 条数据,协同节点收集 n×10000 条数据,而后合并、排序,将排名前 10000 的后果以快照模式存储,最初应用相似数据库游标的模式逐次取得局部数据。这种做法的益处是缩小了查问和排序的次数。scroll 在第一次查问时除了返回查问到的后果外,还会返回一个 scroll_id,它是下次申请的参数。scroll 也分 query,fetch 两个阶段,第一阶段 query 先将所有符合条件的 doc_id 查问并暂存;第二阶段 fetch 依据 doc_id 与 scroll_id 以游标的形式获取文档。须要留神的是 scroll 会应用快照的模式暂存数据,后续一段时间内数据如果有批改是感知不到的,所以它不适宜实时性要求高的场景
    2) scroll-scan 形式。scroll 在首次查问时须要进行文本类似度计算和排序,这个过程也比拟耗时,scroll-scan 则敞开了这一过程。scroll-scan 的特点是不做文本类似度计算;不反对聚合
  2. 抉择适合路由
    在多分片的 ES 集群下,查问大抵分如下两种。
    1) 查问条件中蕴含了 routing 信息。查问时能够依据 routing 间接定位到其中的一个分片,而不须要查问所有分片,再通过协调节点二次排序。
    2) 如果查问条件不蕴含 routing,整个查问过程就分 scatter 与 gather 两个过程。
    scatter(散发):在申请达到协调节点后,协调节点将查问申请散发到每个分片上
    gather(聚合):协调节点收集在每个分片上实现的搜寻后果,再将收集的后果集进行从新排序,返回给用户。

三,堆大小的设置

ES 默认的堆内存大小是 1GB,因为 ES 是比拟耗内存的利用,咱们能够将这个值调大一点。-Xms 与 -Xmx 设置一样。内存调配还有两个准则:

  1. 最好不要超过物理内存的 50%。ES 底层是 lucene 实现的,因为 lucene 段的不变性,所以咱们不必思考数据的变动,这对缓存十分敌对,操作系统能够将这些文件缓存在操作系统的文件缓存零碎 (filesystem cache) 中而非堆内存中,如果超过物理内存过多,则留给文件缓存零碎就不多了
  2. 堆内存最好不要超过 32G。这是因为在 64 位操作系统中,指针自身会变大,会有更大的空间节约在指针自身上。

性能调优就写到这里,上面看下 ES 里的一些个性,比方主节点选举,如何防止脑裂。

  1. 角色隔离
    因为节点默认的是 node.master 和 node.data 都为 true,所以咱们往往会让 Master 节点也担当了 Data 节点的角色。Elasticsearch 集群中的 Data 节点负责对数据进行增、删、改、查和聚合等操作,所以对 CPU、内存和 I / O 的耗费很大,有可能会对 Master 节点造成影响,从而影响整个集群的状态。

在搭建集群时,特地是比拟大的集群时,咱们应该对 Elasticsearch 集群中的节点做角色上的划分和隔离。咱们通常应用几个配置比拟低的虚拟机来搭建一个专门的 Master 集群。在集群中做角色隔离是一件非常简单的事件,只需在节点的配置文件中增加如下配置信息即可。

候选主节点:

node.master =true

node.data=false

数据节点:

node.master =false

node.data=true
  1. master 选举
    前提条件:
    1) 只有是候选主节点 (master:true) 的节点能力成为主节点
    2) 最小主节点数(min_master_nodes) 的目标是避免脑裂
    ES 的选举是 ZenDiscovery 模块负责的,次要蕴含 Ping(节点之间通过这个 RPC 来发现彼此)和 Unicast(单播模块蕴含一个主机列表以管制哪些节点须要 ping 通)这两局部。选举流程大抵如下:
    第一步:确认候选主节点数是否达标
    第二步:对所有候选主节点依据 nodeId 字典排序,每次选举每个节点都将本人所晓得节点排一秩序,而后选出第一个 (第 0 位) 节点,暂且认为它是 master 节点
    第三步:如果对某个节点的投票数达到肯定的值(候选主节点数 /2+1)并且节点本人也选举本人,那这个节点就是 master。否则从新进行直到满足下面条件。
  2. 防止脑裂
    脑裂是因为网络起因导致在集群中选举出了多个 master,最初导致一个集群被决裂为多个集群。了为避免脑裂,咱们须要在在 Master 集群节点的配置文件中增加参数 discovery.zen.minimum_master_nodes,该参数示意在选举主节点时须要参加选举的候选主节点的节点数(默认值是 1)。咱们通常应该把这个值设置成(master_ eligible_nodes/2)+1,其中 master_eligible_nodes 为 Master 集群中的节点数。这样做既能避免脑裂的景象呈现,也能最大限度地晋升集群的高可用性,因为只有不少于 discovery.zen.minimum_ master_nodes 个候选节点存活,选举工作就能够顺利进行。

参考文章:elasticsearch scroll 查问的原理没太懂
Elasticsearch 之 SearchScroll 原理分析和性能及稳定性优化

退出移动版