《Elasticsearch 源码解析与优化实战》第21章：综合应用实践

最新推荐文章于 2024-04-16 10:46:02 发布

宝哥大数据

最新推荐文章于 2024-04-16 10:46:02 发布

阅读量589

点赞数

分类专栏： # ES 文章标签： elasticsearch 源码

原文链接：https://cloud.tencent.com/developer/article/1853295?from=article.detail.1829171

版权

ES 专栏收录该内容

44 篇文章 39 订阅

订阅专栏

简介

本章回答ES应该怎么用的问题。ES被设计得简单易用，容易上手，如果只是把它当作黑盒来用，不了解内部原理，甚至没有一定的基础知识，当数据和节点规模达到一定程度的时候会面临许多问题。本章就重点问题给出使用和部署建议。

集群层

规划集群规模

在部署一个新集群时，应该根据多方面的情况评估需要多大的集群规模来支撑业务。这需要一些基础的测试数据，包括在特定的硬件下，特定业务数据样本的写入性能和搜索性能。然后根据具体业务情况来评估初始集群大小，这些信息包括：

数据总量，每天的增量
查询类型和搜索并发，QPS
SLA级别

另一方面，需要控制最大集群规模和数据总量，参考下列两个限制条件：

节点总数不应该太多，一般来说，最大集群规模最好控制在100个节点左右。我们曾经测试过上千个节点集群，在这种规模下，节点间的连接数和通信量倍增，主节点管理压力比较大。
单个分片不要超过50GB，最大集群分片总数控制在几十万的级别。太多分片同样增加了主节点的管理负担，而且集群重启恢复时间会很长。

建议为集群配置较好的硬件，而不是普通的PC，搜索对CPU、内存、磁盘的性能要求都很高，要达到比较低的延迟就需要较好的硬件资源。另外，如果使用不同配置的服务器混合部署，则搜索速度可能会取决于最慢的那个节点，产生长尾效应。

单节点还是多节点部署

ES不建议为JVM配置超过32GB的内存，超过32GB时，Java内存指针压缩失效，浪费一些内存，降低了CPU性能，GC压力也较大。因此推荐设置为31GB：-Xmx31g -Xms31g

确保堆内存最小值(Xms)与最大值(Xmx)大小相同，防止程序在运行时动态改变堆内存大小，这是很耗系统资源的过程。

当物理主机内存在64GB以上，并且拥有多个数据盘，不做raid的情况下，部署ES节点时有多种选择：

部署单个节点，JVM内存配置不超过32GB，配置全部数据盘。这种部署模式的缺点是多余的物理内存只能被cache使用，而且只要存在一个坏盘，节点重启会无法启动。.
部署单个节点，JVM内存配置超过32GB，配置全部数据盘。接受指针压缩失效和更长时间的GC等负面影响。
有多少个数据盘就部署多少个节点，每个节点配置单个数据路径。优点是可以统一配置，缺点是节点数较多，集群管理负担大，只适用于集群规模较小的场景。
使用内存大小除以64GB来确定要部署的节点数，每个节点配置一部分数据盘，优点是利用率最高，缺点是部署复杂。

官方的建议是方案4，但是为了管理和维护的简便，也可以使用方案1和3。这两种部署模式在我们的集群中都在使用，集群规模较小时可以考虑使用多节点方式部署，例如，只有3台物理机。当集群规模较大时，建议单节点方式部署，例如，物理机达到100台以上。

移除节点

当由于坏盘、维护等故障需要下线一个节点时，我们需要先将该节点的数据迁移，这可以通过分配过滤器实现。例如，我们将node-1下线：

PUT _cluster/settings
{
    "transient" : {
        "cluster.routing.allocation.exclude._name" : "node-1"
    }
}

PUT _cluster/settings
{
  "transient": {
    "cluster.routing.allocation.exclude._ip": "10.3.18.136"
  }
}

执行命令后，分片开始迁移，我们可以通过_cat/shard API来查看该节点的分片是否迁移完毕。当节点维护完毕，重新上线之后，需要取消排除设置，以便后续的分片可以分配到node-1 节点上。

PUT _cluster/settings 
{
    "transient": { 
        "cluster.routing.allocation.exclude.name":"" 
    }
}

完整的分配过滤器使用方式请参考官方手册: http://www.elastic.co/guide/en/elasticsearch/ reference/current/allocation-filtering.html。

独立部署主节点

将主节点和数据节点分离部署最大的好处是Master切换过程可以迅速完成，有机会跳过gateway和分片重新分配的过程。例如，有3台具备Master资格的节点独立部署，然后关闭当前活跃的主节点，新主当选后由于内存中持有最新的集群状态，因此可以跳过gateway的恢复过程，并且由于主节点没有存储数据，所以旧的Master离线不会产生未分配状态的分片。新主当选后集群状态可以迅速变为Green。

节点层

控制线程池的队列大小

不要为bulk和search分配过大的队列，队列并非越大越好，队列缓存的数据越多，GC压力越大，默认的队列大小基本够用了，即使在压力测试的场景中，默认队列大小也足以支持。

除非在一些特别的情况下，例如，每个请求的数据量都非常小，可能需要增加队列大小。但是我们推荐写数据时组合较大的bulk请求。

为系统cache保留一半物理内存

搜索操作很依赖对系统cache的命中，标准的建议是把50%的可用内存作为ES的堆内存，为Lucene保留剩下的50%，用作系统cache。

系统层

关闭swap

在个人PC上，交换分区或许有用，如果物理内存不够，则交换分区可以让系统缓慢运行。但是在服务器系统上，无论物理内存多么小，哪怕只有1GB，都应该关闭交换分区。当服务程序在交换分区上缓慢运行时，往往会产生更多不可预期的错误，因此当一个申请内存的操作如果真的遇到物理内存不足时，宁可让它直接失败。

一般在安装操作系统的时候直接关闭交换分区，或者通过swapoff命令来关闭。

配置Linux OOM Killer

现在讨论的OOM并非JVM的OOM，而是Linux操作系统的OOM。在Linux下，进程申请的内存并不会立刻为进程分配真实大小的内存，因为进程申请的内存不一定全部使用，内核在利用这些空闲内存时采取过度分配的策略,假如物理内存为1GB，则两个进程都可以申请1GB的内存，这超过了系统的实际内存大小。当应用程序实际消耗完内存的时候，怎么办?系统需要“杀掉”一些进程来保障系统正常运行。这就触发了OOM Killer，通过一些策略给每个进程打分，根据分值高低决定“杀掉"哪些进程。默认情况下，占用内存最多的进程被“杀掉”。

如果ES与其他服务混合部署，当系统产生OOM的时候，ES有可能会无辜被“杀”。为了避免这种情况，我们可以在用户态调节一些进程参数来让某些进程不容易被OOM Killer “杀掉”。例如，我们不希望ES进程被“杀”，可以设置进程的oom_score_adj 参数为-17 (越小越不容易被杀)：

$jps
1849 Elasticsearch
$cat /proc/1849/oom_score_adj
0
$sudo echo -17 > /proc/1849/oom_score_adj

可以将这个信息写到ES的启动脚本中自动执行。

优化内核参数

在生产环境上，我们可以根据自己的场景调节内核参数，让搜索服务更有效率地运行。例如，ES集群中的节点一般处于同一个子网，也就是在同一个局域网，Linux 默认的TCP选项不一定完全合适，因为它需要考虑在互联网上传输时可能出现的更大的延迟和丢包率。因此我们可以调节一些TCP选项，让TCP协议在局域网上更高效。

调节内核参数可以通过两种方式：

临时设置，系统重启后失效。通过sysctl -W来设置，例如: sysctl -w net.ipv4.tcp_timestamps=1，命令执行后该参数立即生效。
永久设置，将参数写入配置文件/etc/sysctl.conf，然后执行sysctl -p使其生效。

可以通过sysctl -A配合grep查看某个参数的当前值。

下面给出一些比较通用的内核参数设置建议，这些参数的默认值以CentOS7.2为参考，在其他系统上可能会有些差异。

1. TCP相关参数

net.ipv4.tcp_syn_retries

默认值为6，参考值为2。主机作为客户端，对外发起TCP连接时，即三次握手的第一步，内核发送SYN报文的重试次数，超过这个次数后放弃连接。内网环境通信良好，因此可以适度降低此值。

net.ipv4.tcp_synack_retries

默认值为5，参考值为2。主机作为服务端，接受TCP连接时，在三次握手的第二步，向客户端发送SYN+ACK报文的重试次数，超过这个次数后放弃连接。内网环境中可适度降低此值。

net.ipv4.tcp_timestamps

默认值为1，参考值为1。是否开启时间戳，开启后可以更精确地计算RTT，一些其他特性也依赖时间戳字段。

net.ipv4.tcp_tw_reuse

默认值为0，建议值为1。是否允许将处于TIME_WAIT 状态的socket用于新的TCP连接。这对于降低TIME_WAIT数据很有效。该参数只有在开启tcp_timestamps 的情况下才会生效。

net.ipv4.tcp_tw_recycle

默认值为0，参考值为0。是否开启TIME_WAIT套接字的快速回收，这是比tcp_tw_reuse更激进的一种方式，它同样依赖tcp_ timestamps 选项。强烈建议不要开启tcp_tw_recycle，原因有两点,一是TIME_WAIT是十分必要的状态,避免关闭中的连接与新建连接之间的数据混淆，二是tcp_tw_recycle选项在NAT环境下会导致一些新建连接被拒绝，因为NAT下每个主机存在时差，这体现在套接字中的时间戳字段，服务端会发现某个IP.上的本应递增的时间戳出现降低的情况，时间戳相对降低的报文将被丢弃。

net.core.somaxconn

默认值为128，参考值为2048。定义了系统中每一个端口上最大的监听队列的长度。当服务端监听了某个端口时，操作系统内部完成对客户端连接请求的三次握手。这些已建立的连接存储在一个队列中，等待accept调用取走。本选项就是定义这个队列的长度。该队列实际大小取决于listen 调用传入的第二个参数: backlog 和本选项的最小值: min(backlog,somaxconn)。 ES需要建立许多连接，当集群节点数比较大，集群完全重启时可能会在瞬间建立大量连接，默认的连接队列长度可能不够用，因此适当提高此值。

net.ipv4.tcp_max_syn_backlog

默认值为128，参考值为8192。内核会服务端的连接建立两个队列：

已完成三次握手，连接已建立，等待accept的队列，全局长度由somaxconn定义。
三次握手执行到第二步，等待客户端返回ACK，这些未完成的连接单独放到一个队列中，由tcp_max_syn_backlog 定义队列大小。

由于可能会有较多的连接数，我们适度增加“未完成连接”的队列大小。.

net.ipv4.tcp_max_tw_buckets

默认值为4096，参考值为180000。定义系统同时保持TIME_WAIT 套接字的最大数量，如果超过这个数，则TIME_WAIT套接字将立刻被清除并打印警告信息。如果系统被TIME_WAIT过多问题困扰，则可以调节tcp_max_tw_buckets.tcp_tw_reuse 、tcp_timestamps三个选项来缓解。TIME_WAIT状态产生在TCP会话关闭时主动关闭的一端，如果想从根本上解决问题，则让客户端主动关闭连接，而非服务端。

net.ipv4.tcp_max_orphans

默认值为4096，参考值为262144。定义最大孤儿套接字(未附加到任何用户文件句柄的套接字)数量。如果孤儿套接字数量超过此值，则这些连接立即“reset”，并显示警告信息。该值可以简单地抵御DOS攻击，但不能通过降低此值来抵御DOS。为了应对高负载，应该提高此值。

2. TCP的接收窗口(RWND)

TCP采用两个基本原则决定何时发送及发送多少数据：

流量控制，为了确保接收者可以接收数据。
拥塞控制，为了管理网络带宽。

流量控制通过在接收方指定接收窗口大小来实现。接收窗口用于接收端告诉发送端，自己还有多大的缓冲区可以接收数据。发送端参考这个值来发送数据，就不会导致客户端处理不过来。

接收窗口的大小可以通过内核参数来调整，其理想值是BDP ( bandwidth-delay product)：服务端可以发出的未被客户端确认的数据量，也就是在网络上缓存的数据量。

网络连接通常以管道为模型，BDP是带宽与RTT的乘积，表示需要多少数据填充管道。下图展示了BDP的基本概念。

在这里插入图片描述

例如，在千兆的网络上，RTT为10毫秒，那么BDP= (1000/8) X0.01s=1.25MB。在这种情况下，如果想最大限度地提升TCP吞吐量，则RWND大小不应小于1.25MB。

可以通过下面的选项调整RWND：

net.ipv4.tcp_rmem = <MIN> <DEFAULT> <MAX>

默认情况下，系统会在最大值和最小值之间自动调整缓冲区大小，是否自动调整通过tcp_moderate_rcvbuf 选项来决定。在开启缓冲自动调整的情况下，可以把最大值设置为BDP。

TCP使用2个字节记录窗口大小，因此最大值为64KB，如果超过这个值，则需要使用tcp_window_scaling 机制，通过下面的设置开启(默认启用)：

net.ipv4.tcp_window_scaling = 1

RWND和CWND可能是让系统达到最大吞吐量的两个限制因素，接下来我们讨论CWND。

3. TCP的拥塞窗口(CWND)

TCP的滑动窗口机制依据接收端的能力来进行流控，并不能感知网络延迟等网络因素。拥塞控制机制会评估网络能承受的负荷，避免过量数据发送到网络中，拥塞程度会涉及主机、路由器等网络上的所有因素。

拥塞控制由发送方实现，发送方会将它传输的数据量限制为CWND和RWND的最小值。CWND会随着时间和对端的ACK增长，如果检测到网络拥塞，则缩小CWND。拥塞控制主要有4种算法：慢启动、拥塞避免、快速重传和快速恢复。

慢启动的意思是对于刚建立的连接，开始发送数据时，一点点提速，而不是一下子使用很大的带宽。慢启动是指数上升的过程，直到CWND≥ssthresh,进入拥塞避免算法。

本节我们讨论的问题就是调节初始拥塞窗口(INITCWND)的大小。适度增加INITCWND可以降低HTTP响应延迟，可以参考Google的论文: An Arygument for Increasing TCP’s Initial Congestion Window。

例如，HTTP要返回的内容为20K，MSS的大小为1460，整个内容需要传送15个MSS。当INITCWND为3时，服务端先发送3个MSS，1460X3-4380 字节，待客户端ACK后，根据指数增加算法，第二次发送9个MSS，1460X9=13140 字节，第三次发送3个MSS的剩余字节。整个传输过程经过了3次RTT。如果INITCWND设置为15，则只需要一次RTT就可以完成传输。

在Linux 2.6.39版本之前，INITCWND值根据MSS值来计算，参考RFC3390: http://www.rfe-editor.org/f/rfc3390.txt。以太网的MSS大小一般是1460，因此INITCWND为3,这个初始值比较小。从2.6.39版本及之后，采取了Google 的建议，把INITCWND调到了10，参考：https://kereelnewvbies.org/Linux_2_6_39#head-1d11935223b203d28a660417627514973de4e218

如果系统上的INITCWND低于10，可以使用ip命令调整。调节和测试INITCWND的具体方法可以参考: htps://www.cdnplanet.com/blog/une tcp-initcwnd- for-optimum-performance/

4. vm相关参数

文件的读和写操作都会经过操作系统的cache，读缓存是比较简单的，而写缓存相对复杂。在一般情况下，写文件的数据先到系统缓存(page cache)，再由系统定期异步地刷入磁盘，这些存储于pagecache中尚未刷盘的数据称为脏数据(或者脏页dirtypage)。写缓存可以提升I/O速度，但存在数据丢失的风险。例如，在尚未刷盘的时候主机断电。

系统当前page cache信息可以通过/proc/meminfo文件查看。下面我们讨论一下写缓存的细节和控制策略。

从page cache刷到磁盘有以下三种时机：

可用物理内存低于特定阈值时，为了给系统腾出空闲内存;
脏页驻留时间超过特定阈值时，为了避免脏页无限期驻留内存;
被用户的sync()或fsync()触发。

由系统执行的刷盘有两种写入策略：

异步执行刷盘，不阻塞用户I/O;
同步执行刷盘，用户I/O被阻塞，直到脏页低于某个阈值。

在一般情况下，系统先执行第一种策略，当脏页数据量过大，异步执行来不及完成刷盘时，切换到同步方式。我们可以通过内核参数调整脏数据的刷盘阈值：

vm.dirty_background_ratio, 默认值为10。该参数定义了一个百分比。当内存中的脏数据超过这个百分比后，系统使用异步方式刷盘。
vm.dirty_ratio，默认值为30。同样定义了一个百分比，当内存中的脏数据超过这个百分比后，系统使用同步方式刷盘，写请求被阻塞，直到脏数据低于dirty_ratio。如果还高于dirty_background_ratio，则切换到异步方式刷盘。因此dirty_ratio 应高于dirty_background_ratio。

除了通过百分比控制，还可以指定字节大小，类似的参数有：

dirty_background_bytes
dirty_bytes

vm.dirty_expire_centisecs，默认值为3000 (30秒)，单位为百分之1秒，定义脏数据的过期时间，超过这个时间后，脏数据被异步刷盘。
vm.dirty_writeback_centisecs，默认值为500 (5秒)，单位为百分之1秒，系统周期性地启动线程来检查是否需要刷盘，该选项定义这个间隔时间。

可以通过下面的命令查看系统当前的脏页数量：

cat /proc/vmstat | egrep "dirty Iwriteback"
nr_dirty 951
nr_writeback 0
nr_writeback_temp 0

输出显示有951个脏页等待写到磁盘。默认情况下每页大小为4KB。另外，也可以在/proc/meminfo文件中看到这些信息。

如果数据安全性要求没有那么高，想要多“cache”一些数据，让读取更容易命中，则可以增加脏数据占比和过期时间：

vm.dirty_background_ratio = 30
vm.dirty_ratio = 60
vm.dirty_expire_centisecs = 6000

反之则可以降低它们。如果只希望写入过程不要被系统的同步刷盘策略影响，则可以让系统多容纳脏数据，但早一些触发异步刷盘。这样也可以让I/O更平滑：

vm.dirty_background_ratio = 5
vm.dirty_ratio = 60

5. 禁用透明大页(Transparent Hugepages)

透明大页是Linux的一个内核特性，它通过更有效地使用处理器的内存映射硬件来提高性能，默认情况下是启用的。禁用透明大页能略微提升程序性能，但是也可能对程序产生负面影响，甚至是严重的内存泄漏。为了避免这些问题，我们应该禁用它(许多项目都建议禁用透明大页，例如，MongoDB、 Oracle)。可以通过下面的命令检查其是否开启：

cat/sys/kernel/mm/transparent_hugepage/enabled
[always] madvise never

always代表开启，通过下面的命令将其禁用( 系统重启后失效)：

echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled

关于透明大页对应用程序的具体影响可以参考一篇分析文章: htp://blog.nelhage.com/post/transparent-hugepages/

更多的内核参数信息可以参考htps:/ww.kermel.org/oc/Documnentation/networking/ip-sysctl.txt和https://www.kernel.org/doc/Documentation/sysctl/

索引层

使用全局模板

从ES 5.x开始，索引级别的配置需要写到模板中，而不是elasticsearch.yml配置文件，但是我们需要一些索引级别的全局设置信息，例如，translog 的刷盘方式等，因此我们可以将这些设置编写到一个模板中，并让这个模板匹配全部索引“*”，这个模板我们称为全局模板，例如:

{
    "template": "*",
    "order" : 0,
    "settings": {
        "index.number_of_replicas" : "1",
        "index.number_of_shards" : "24"
    }
}

order为0代表该模板有最小的优先级。当索引创建时，ES判断都匹配到哪些模板，如果匹配到多个模板，则将模板中的参数进行合并。当遇到冲突的设置项时，根据模板优先级orde来决定谁的配置会生效。我们为全局模板设置最低的优先级，任何其他索引自定义的模板都可以覆盖它的设置。

索引轮转

如果有一个索引每天都有新增内容，那么不要让这个索引持续增大，建议使用日期等规则按一定频率生成索引。同时将索引设置写入模板，让模板匹配这一系列的索引，还可以为索引生成一个别名关联部分索引。我们一般按天生成索引，例如，要新增一个名为dns_log 的索引，我们先创建模板，在模板中描述该索引的设置和mapping信息：

{
    "template": "dns_log-*",
    "settings": {
        "index. refresh_interval": "120s"
     },
    "mappings": {
        "dns_log": {
            "dynamic": false,
            "properties": {
                "field1": { "type": "text"},
                "field2": { "type": "integer", "doc_values": false }
            }
        }
    }
}

该模块会匹配dns_log-*规则的索引，对匹配规则的索引应用模板设置。写入程序每天生成一个索引，例如，dns_ log20180614。在该索引中只写入当天的数据。在搜索时，可以使用索引前缀dns_log-*进行搜索。当需要删除旧数据时，可以按日期删除索引的旧数据，删除索引会立即删除磁盘文件，释放存储空间。而如果不这么做，只删除部分doc，则依赖Lucene分段的合并过程才能释放空间。

避免热索引分片不均

默认情况下，ES的分片均衡策略是尽量保持各个节点分片数量大致相同。但是当集群扩容时，新加入集群的节点没有分片，此时新创建的索引分片会集中在新节点上，这导致新节点拥有太多热点数据，该节点可能会面临巨大的写入压力。因此，对于一个索引的全部分片，我们需要控制单个节点上存储的该索引的分片总数，使索引分片在节点上分布得更均匀一些。

例如，10 个节点的集群，索引主分片数为5，副本数量为1，那么平均下来每个节点应该

有(5X2) /10=1个分片，考虑到节点故障、分片迁移的情况，可以设置节点分片总数为2:

curl -X PUT http://127.0.0.1:9200/myindex/_settings -d '{
    "index": { "routing.allocation.total_shards_per_node" : "2" }
}'

通常，我们会把index.routing,allocation.total_shards_per_node与索引主分片数、副本数等信息统一写到索引模板中。

副本数选择

由于搜索使用较好的硬件配置，硬件故障的概率相对较低。在大部分场景下，将副本数number_of_replicas设置为1即可。这样每个分片存在两个副本。如果对搜索请求的吞吐量要求较高，则可以适当增加副本数量，让搜索操作可以利用更多的节点。如果在项目初始阶段不知道多少副本数够用，则可以先设置为1，后期再动态调整。对副本数的调整只会涉及数据复制和网络传输，不会重建索引，因此代价较小。

Force Merge

对冷索引执行ForceMerge会有许多好处，我们在之前的章节中曾多次提到：

单一的分段比众多分段占用的磁盘空间更小一些;
可以大幅减少进程需要打开的文件fd;
可以加快搜索过程，因为搜索需要检索全部分段;
单个分段加载到内存时也比多个分段更节省内存占用;
可以加快索引恢复速度。

可以选择在系统的空闲时间段对不再更新的只读索引执行ForceMerge：

curl -X POST "localhost:9200/twitter/_forcemerge"

该命令将分段合并为单个分段，执行成功后会自行“flush”。

Shrink Index

需要密切注意集群分片总数，分片数越多集群压力越大。在创建索引时，为索引分配了较多的分片，但可能实际数据量并没有多大，例如，按日期轮询生成的索引，可能有些日子里数据量并不大，对这种索引可以执行Shrink 操作来降低索引分片数量。Shrink 的例子可以参考Shrink分析一章。

我们可以为ShrinkIndex和上一节的ForceMerge编写自动运行脚本，通过crontab选择在凌晨的某个时间对索引进行优化，编写crontab文件内容如下：

$cat escron
0 2 * * *  es  /home/es/software/elasticsearch/bin/index.sh

然后将定时任务添加到普通用户的定时任务中：

crontab escron

我们通常会为部署集群编写部署脚本，这些工作都可以放到部署脚本中。

close索引

如果有些索引暂时不使用，则不会再有新增数据，也不会有对它的查询操作，但是可能以后会用而不能删除，那么可以把这些索引关闭，在需要时再打开。关闭的索引除存储空间外不占用其他资源。

通过下面的命令关闭或打-一个索引：

curl -X POST "localhost:9200/my_index/_close"
curl -X POST "localhost:9200/my_index/_open"

延迟分配分片

当一个节点由于某些原因离开集群时，默认情况下ES会重新确定主分片，并立即重新分配缺失的副分片。但是，一般来说节点离线是常态，可能因为网络问题、主机断电、进程退出等因素是我们经常面对节点离线的情况，而重新分配副分片的操作代价是很大的，该节点上存储的数据需要在集群上重新分配，复制这些数据需要大量带宽和时间，因此我们调整节点离线后分片重新分配的延迟时间：

“index.unassigned.node_left.delayed_timeout” : “5d”

这个索引级的设置写到模板的全局设置信息中，节点离线一般是暂时的，如果因为硬件故障，则修复时间一般是可以预期的，根据实际情况来调节这个延迟时间。

小心地使用fielddata

聚合时，ES 通过doc_values 获取字段值，但是text类型不支持doc_values。当在text 类型字段上聚合时，就会依赖fielddata数据结构，但fielddata默认关闭。因为它会消耗很多堆空间，并且在text类型字段上聚合通常没有什么意义。

doc_values 在索引文档时就会创建，而fielddata 是在聚合、排序，或者脚本中根据需要动态创建的。其读取每个分段中的整个倒排索引，反转term和doc的关系，将结果存储到JVM堆空间，这是非常昂贵的过程，会让用户感到明显的延迟。

fielddata所占用的大小默认没有上限，可以通过indices.fielddata.cache.size来控制，该选项设置一个堆内存的百分比，超过这个百分后，使用LRU算法将老数据淘汰。

客户端

使用REST API而非Java API

我们在第1章讨论过，由于Java API引起版本兼容性问题，以及微弱到可以忽略的性能提升, Java API将在未来的版本中废弃，客户端最好选择REST API作为客户端，而不是Java API。

注意429状态码

bulk请求被放入ES的队列，当队列满时，新请求被拒绝，并给客户端返回429的状态码。客户端需要处理这个状态码，并在稍后重发请求。此刻客户端需要处理bulk请求中部分成功、部分失败的情况。这种情况产生在协调节点转发基于分片的请求到数据节点时，有可能因为对方的bulk队列满而拒绝写操作，而其他数据节点正常处理，于是客户端的bulk请求部分写入成功、部分写入失败。客户端需要将返回429的对应数据重试写入，而不是全部数据，否则写入的内容就会存在重复。

产生429错误是因为ES来不及处理，一般是由于写入端的并发过大导致的，建议适当降低写入并发。

curl的HEAD请求

我们经常使用curl作为客户端进行一些日常操作。但是需要注意curl发送HEAD请求的方式并非我们预想的那样，例如，通过HEAD请求检查doc是否存在，官网的这个例子就是错误的：

curl -X HEAD "localhost:9200/twitter/_doc/0"

curl -X HEAD只是将HTTP头部的方法设置为HEAD，还会等待服务器返回body，所以现象就是curl命令阻塞在那里。正确的方式应该是使用-I参数：

curl -I "localhost:9200/twitter/_doc/0"

使用-I参数curl会将HTTP方法设置为HEAD，并在收到服务器返回的HTTP头部信息后关闭TCP连接。

了解你的搜索计划

就像在执行一条SQL语句时，需要了解其执行计划一样，我们需要知道一个搜索操作可能会命中多少分片，它执行的任务复杂性有多大，聚合范围有多大等情况。只有了解了搜索指令的执行代价，才能更好地使用ES进行搜索。例如，搜索应该只让尽量少的分片参与工作，如果只需要检索当天的内容，则在按天生成的索引中，只搜索当天的单个索引即可。通过日期范围查询会让其他天的索引不必要地执行一次搜索。

除了人为评估查询语句，还可以使用Profile API分析会命中哪些分片，每个分片执行的查询时间等细节。

为读写请求设置比较长的超时时间

读写操作都有可能是比较长的操作，例如，写一个比较大的bulk数据，或者执行较大范围的聚合。此时客户端为请求设置的超时时间应该尽量长，因为即使客户端断开连接，ES仍然会在后台将请求处理完，如果超时设置比较短，则在密集的请求时会对ES造成非常大的压力。

读写

避免搜索操作返回巨大的结果集

我们在搜索流程中讨论过，由于协调节点的合并压力，所有的搜索系统都会限制返回的结果集大小，如果确实需要很大的结果集，则应该使用Scroll API。

避免索引巨大的文档

http.max_context_length的默认值为100MB, ES会拒绝索引超过此大小的文档，可以增加这个值，但Lucene仍然有大约2GB的限制。

即使不考虑这些限制，大型文档通常也不实用。大型文档给网络、内存和磁盘造成了更大的压力。即使搜索操作设置为不返回_source， ES总要获取_id，对于大型文档来说，获取这个字段的代价是很大的，这是由于操作系统的cache 机制决定的。索引一个文档需要一些内存，所需内存大小是原始文档大小的几倍。邻近(Proximity) 搜索(例如，短语查询)和高亮也会变得更加昂贵，因为它们的成本直接取决于原始文档大小。

因此可能要重新考虑信息的单位，例如，想要为一本书建立索引使之可以被搜索，这并不意味着把整本书的内容作为单个文档进行索引。最好使用章节或段落作为文档，然后在文档中加一个属性标识它们属于哪本书。这样不仅避免了大文档的问题，还使搜索的体验更好。

避免使用多个_type .

_type本来是用于区分存储到同一个索引中的不同格式的数据，但是实际上面对这种情况应该用不同的索引解决，而不是在同一个索引中使用不同的_type。因为不能通过type 来删除数据，这和通过id删除数据没什么区别。而且还容易给初学者造成“index就像数据库，type就像表”的误解。_type 是完全没必要存在的。

从ES 6.0开始，索引只允许存在一个_type，7.0 版本之后将完全废弃了_type 的概念。

避免使用_all字段

在写入速度优化中讨论过all使用字段带来的负面影响，从ES 6.0开始，all 字段默认被禁用，并且不建议使用。此类需求可以通过mapping中的copy_to 参数创建自定义的 all 字段。

参考官方手册: htps://www.elastic .co/guide/en/elasticsearch/reference/master/copy-to.html。

避免将请求发送到同一个协调节点

无论索引文档还是执行搜索请求，客户端都应该避免将请求发送到固定的某个或少数几个节点，因为少数几个协调节点作为整个集群对外的读写节点的情况下，它们很有可能承受不了那么多的客户端请求。尤其是搜索请求，协调节点的合并及排序会占用比较高的内存和CPU，聚合会占用更多内存。因此会导致给客户端的返回慢，甚至导致节点OOM。

正确的做法是将请求轮询发送到集群所有节点，如果使用RESTAPI，则可以在构建客户端的客户端对象时传入全部节点列表。如果在前端或脚本中访问ES集群，则可以部署LVS，客户端使用虚IP，或者部署Nginx使用反向代理。

控制相关度

通过Painless脚本控制搜索评分

ES有多种方式控制对搜索结果的评分，如果常规方式无法得到想要的评分结果，则可以通过脚本的方式完全自己实现评分算法，以得到预期的评分结果。ES支持多种脚本语言，经历各版本演变后，从5.0版本开始实现了自己专用的语言: Painless。 Groovy 脚本已弃用。Painless是内置支持的，脚本内容通过REST接口传递给ES, ES将其保存在集群状态中。在5.x版本中可以放到config/scripts下，6.x 版本中只能通REST接口写入。

通过脚本控制评分的原理是编写一个自定义脚本，该脚本返回评分值，该分值与原分值进行加法等运算，从而完全控制了评分算法。

例如，我们有一个通讯录的名单索引user_info，为了简便说明问题，索引只有一个name字段：

PUT user_info
{
    "mappings":{
        "user": {
            "properties": {
                "name": {
                    "type": "keyword"
                }
            }
        }
    }
}

写入下列测试数据：

POST /user_info/_bulk
{"index" : {"_type":"user","_id":"1"}}
{"name":"高 X"}
{"index" : {"_type":"user","_id":"2"}}
{"name":"高 XX"}
{"index" : {"_type" :"user","_id":"3"}}
{"name":"X 高 X"}
{"index" : {"_type":"user","_id":"4"}}
{"name":"X 高 X"}
{"index" : {"_type":"user","_id":"5"}}
{"name":"XX 高"}
{"index" : {"_type":"user","_id":"6"}}
{"name":"高 XXX"}

我们期望的返回顺序与两个原则有关：关键词出现的位置越靠前，排序应该越靠前；字段值越短，说明匹配度越高，排序应该越靠前。

因此，理想的顺序应该是：

高 X
高 XX
高 XXX
X 高 X

下面执行搜索：

GET user_info/_search?size=20
{
    "query": {
        "query_ string" : {
            "query" : "(name: (*高*))"
        }
    }
}

实际返回结果顺序如下，每一项的得分(_score) 都是1.0。

X 高 X
高 XX
X 高 X
高 XXX
高 X
XX 高

我们编写一个简单的脚本，通过doc[‘name’].value获取文档值，然后根据位置和相似度分别计算评分，将结果乘以不同权重再相加。

double position_ score = 0;
double similarity score = 0;
int pos = doc[ ' name'].value.indexOf (params.keyword);
if (pos != -1) {
    position_score = 10 - pos;
    if (position_score < 0) {
        position_score = 0; // 出现位置大于10的忽略其重要性
    }
}
double similarity = Math.abs (1.0*doc['name'].value.length() - params.keyword.length());
similarity_score = 10 - similarity;
if (similarity_ score < 0) {
    similarity_ score = 0; //相似度差10个字符的忽略其重
}
//在下面调节各分值的权重
return position_score * 0.6 + similarity_score * 0.4;

去掉脚本中的注释，并格式化为单行（在sublime中可以通过Ctrl+A、Ctrl+J组合键实现）内容后，写入ES：

POST _scripts/user_info_score
{
    "script": {
        "lang": "painless",
        "source": "格式化为单行的脚本内容"
    }
}

我们的脚本id为user_info_score，在script_score 函数中指定脚本id，再次执行查询：

GET user info/_search?size=20
{
    "query": {
        " function_ score": {
            "query": {
                "query_ string": {
                    "query": "(name: (*高*))"
                }
            },
            "script_ score": {
                "script": {
                    "id": "user_info_score",
                    "params": {
                        "keyword": "高"
                    }
                }
            },
            "boost_ mode": "sum"
        }
    }
}

function_score查询是用来控制评分的终极武器，它允许为每个与主查询匹配的文档应用一个内置或自定义函数，以达到改变原始查询评分_score的目的。其中的script_score用于指定自定义脚本。params指定作为变量传递到脚本中的参数。

boost_mode字段用来指定新计算的分数与_score 的结合方式，取值可以是: multiply 相乘(默认)、replace 替换、_score sum相加、avg 取平均值、max 取最大值、min 取最小值。

这次查询返回了我们期望的结果：

"hits" : [
    {
        "_score" : 10.6,
        "_source" : { "name" : "高 X" }
    },
    {
        "_score" : 10.2,
        "_source" : { "name" : "高 XX" }
    },
    {
        "_score" : 9.8,
        "_source" : { "name" : "高 XXX" }
    },
    {
        "_score" : 9.6,
        "_source" : { "name" : "X 高 X" }
    },
    {
        "_score" : 9. 6,
        "_source" : { "name" : "X 高 X" }
    },
    {
        "_score" : 9.0,
        "_source" : { "name" : "XX 高" }
    }
}

关注我的公众号【宝哥大数据】，更多干货

在这里插入图片描述

宝哥大数据

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
《Elasticsearch 源码解析与优化实战》第21章：综合应用实践

文章目录简介集群层规划集群规模单节点还是多节点部署移除节点独立部署主节点节点层控制线程池的队列大小为系统cache保留一半物理内存系统层关闭swap配置Linux OOM Killer优化内核参数索引层使用全局模板索引轮转避免热索引分片不均副本数选择Force MergeShrink Indexclose索引延迟分配分片小心地使用fielddata客户端使用REST API而非Java API注意429状态码curl的HEAD请求了解你的搜索计划为读写请求设置比较长的超时时间读写避免搜索操作返回巨大的结果集
复制链接

扫一扫