ES性能调优权威指南（篇三）

原文地址：https://qbox.io/blog/authoritative-guide-elasticsearch-performance-tuning-part-3
注：本文是ES性能调优权威指南三篇中的第三篇，第一篇和第二篇参考这里。
http://blog.csdn.net/kimichen123/article/details/77477812

http://blog.csdn.net/kimichen123/article/details/77478024

    这篇文章主要关注于优化ES以得实现的最大索引吞吐量和降低监控和管理负载。
   ES提供了分片和复制的推荐方法用于扩展和增加索引的可用性。分配稍多一点的分片是好的，但是大量的分片是不好的。很难定义什么是太多的分片，因为这取决于它们的大小以及它们是如何被使用的。不常使用的100个分片可能很好，而两个使用非常频繁的分片可能太多了。监视你的节点以确保它们有足够的空闲能力来处理异常情况。
   这篇文章我们将使用Qbox.io的ES，你可以通过launch
your cluster here登记，或者点击头部导航的 "Get Started" 。如果你需要设置的帮助，请参考这篇"Provisioning
a Qbox Elasticsearch Cluster"

    扩展应该分阶段进行。构造足够的容量来进入下一个阶段。一旦进入下一个阶段，你就有时间去考虑你需要做的改变来达到这个阶段。您还可以从改变索引请求ES的优化方式中获得很多好处——比如，您是否需要为每个文档发送单独的请求?或者，您是否可以使用单个批量API对缓冲的多个文档索引?

    我们之前研究了索引性能指标和设置，如刷新（refresh）、刷新（flushing）、段合并和自动节流。本教程将列出一组想法，以增加ES索引吞吐量，并参考分片和复制、请求、客户端和存储。

    

扩展集群

    ES天生可扩展。在你的机器或者拥有几百个节点的集群的体验是相同的。小集群成为大集群的过程几乎是纯自动和无痛的。大集群到超大集群需要一些规划和设计，但任然不很很痛苦。

教程: Auto-Scaling Kubernetes on DigitalOcean
with Supergiant

    ES的默认设置会花费你很长一段时间，但是为了获得最大的收益，你需要考虑清楚数据如果流转。它可以是基于时间的数据（日志事件、社交网络流、最近相关性）或者是基于用户的数据（由用户或客户来划分大型大型的文档集合）。

    create index API允许实例化一个索引。ES提供了跨索引的多索引的操作支持。每个索引的创建都可以指定特定设置，分片数一旦确定就不能再改。如果你不知道有多少数据，那应该考虑多分配一些分片（但不要太多，分片不是免费的）作为备用。而索引的副本在未来是可用改变的。

curl -XPUT 'localhost:9200/my_index -d '{
"settings" : {
"index" : {
"number_of_shards" : 3,
"number_of_replicas" : 2
}
}
}'

    别名是另外一种扩展索引的方法（有限制）。别名API允许为索引指定名称，之后所有API自动将别名转为实际的索引名称。别名可用匹配多个索引，当指定时，别名会自动扩展到别名索引。一个别名也可以与一个过滤器关联，过滤器在搜索和路由时会自动被应用。别名不能具有与索引相同的名称。

    下面是一个将别名alias1与索引test1关联起来的示例。

curl -XPOST 'localhost:9200/_aliases' -d '{
"actions" : [
{ "add" : { "index" : "test1", "alias" : "alias1" } }
]
}'

移除别名：

curl -XPOST 'localhost:9200/_aliases' -d '{
"actions" : [
{ "remove" : { "index" : "test1", "alias" : "alias1" } }
]
}'

重命名别名就是一个先删后加的操作。这个操作是原子的，无需担心在短时间内别名指定不了索引。

curl -XPOST 'localhost:9200/_aliases' -d '{
"actions" : [
{ "remove" : { "index" : "test1", "alias" : "alias1" } },
{ "add" : { "index" : "test2", "alias" : "alias1" } }
]
}'

副本

副本重要的原因有：

分片和节点失败时提供高可用。需要注意的是，副本从未在原始/主分片相同的节点上分配。

 它允许扩展搜索量/吞吐量，因为搜索可以在所有副本上并行执行。

    副本是处理失败的重要特性，但如果副本越多，索引就会越大。因此对原始索引吞吐量而言最好没有副本。幸运的是与分片数量不同的是你可以随时更改副本数量。

    在比如初始化新索引时，或者数据迁移到新索引中，没有副本可能会很有用，而在完成了关键的初始化后再添加副本。

    可以通过更新索引API更新副本数量：

curl -XPUT 'localhost:9200/my_index/_settings' -d '{
"index" : {
"number_of_replicas" : 0
}
}'

一旦索引操作完成，副本数可以在之后设置。

使用专用数据节点

   数据节点持有我们索引中的文档。数据节点处理例如CRUD、搜索和聚合登数据类的操作。这些操作是IO、内存、CPU密集型的。监控资源很重要并且在负载过重时需要加载更多的数据节点。拥有专用数据节点的主要好处是主数据和数据角色的分离。

  创建一个独立的数据节点：

node.master: falsenode.data: truenode.ingest: false

    当聚合节点处理搜索查询并需要联系数据节点时，它们会从数据节点加载数据，这样就会有更多处理索引请求的能力。

    如果你的数据节点在磁盘空间运行很慢，那久需要向集群中添加更多的数据节点。另外还需要确保索引具有足够的主分片，以便能在节点间平衡数据。

    分片分配到节点时会考虑到可用的磁盘空间，默认情况下不会向磁盘使用率超过85%的节点分配分片。

    有两种磁盘空间不足的补救方法。一种是删除集群中的过时数据，这对所有用户来说可能不是个可行的方案，但是如果你正在存储基于时间的数据，你可以将旧索引的快照备份在备用集群（off-cluster）中，并关闭索引的副本。

教程: Auto-Scaling Kubernetes Cluster
on AWS EC2 with Supergiant

    如果你仍然需要将所有数据保留在集群中，那么第二种方法也是唯一的选择：垂直或水平扩容。垂直扩容意味着需要升级硬件，而为了避免再次升级，你应该充分利用ES设计的水平扩容优势。为了更好的适应未来的增长，你最好重新索引数据并指定更多的分片。

优化批请求

     Bulk
API 使得在一个API中执行多个索引/删除操作成为可能。这可以极大的提高索引速度。每个子请求都是独立执行的，因此一个子请求的失败不会影响其他子请求的成功。如任何一个请求失败，那么顶级错误标记为true，并在相关请求下报告错误详情。

    最可能的操作是index, create, delete 和update。索引和创建要求下一行与标准索引API（例如索引将添加和替换文档，而如果具体相同索引和类型的文档已经存在，创建将失败）的操作类型参数有相同语义。删除不并要求在下一行中有一个与标准删除API有相同语义的source。更新操作要求部分文档、upsert和脚本选项在下一行被指定。
    整个批请求将请求加载到节点内存中，所有请求越大，其他请求可用的内存则越少。存在一个最优的批请求大小，在这个尺寸上性能没法提升甚至可能下降。最佳尺寸取决于硬件、文档大小和复杂度，以及索引和搜索负载。
    幸运的是，找到这个平衡点很容易:试着在索引时不断增加文档大小。当性能开始下降时，批处理规模则太大了。一个好的开头是是批量1000到5000份的文档，如果你的文档很大，则应该设置更小的量。批大小取决于数据、分析和集群配置，但是一个好的开头是每次5-15
MB。注意这是物理大小。对于批大小来说，文档数并不是一个好的度量标准。如果正在索引1000个文档，请记住：

1,000 个 1 KB的文档 总共是 1 MB.

1,000 个100 KB的文档 总共是 100 MB.

    它们大小完全相同。协调节点上需要将批请求加载到内存中，因此它的物理大小比文档数更重要。

    从5-15MB的大小开始增加直到性能无法提升。之后开始增加并发性(多线程，等等)。

    使用Marvel 监控节点，并使用 iostat, top, 和ps监测资源瓶颈。当接收到EsRejectedExecutionException，集群不能再继续了:至少有一种资源已经达到了瓶颈。要么减少并发性，要么提供更多的资源(例如从旋转磁盘切换到ssd)，或者添加更多的节点。

    当接收数据中，保证请求在所有数据节点上循环处理。不要将所有请求发送到单个节点，因为该节点在处理时需要将所有的数据存储在内存中。

存储

    如果你一直遵循正常的开发方式，那么可能你已经在本机或者小集群上玩起ES了。但是当需要将ES部署到生产环境时，则需要考虑一些建议。没有什么是硬性规定；ES被广泛用于各种各样的任务和一系列眼花缭乱的机器上。但是我们基于生产环境的经验还是推荐你先看一看。

    磁盘通常是服务器的瓶颈。ES十分依赖磁盘，索引磁盘吞吐能力月强，你的集群会越稳定。以下是一些优化磁盘IO的建议。

如果你承担的起SSD，那么比任何旋转介质都要优越。SSD在查询和索引性能上都有提升。另外如果你使用旋转介质，则应尽量获得最快的磁盘。（高性能服务器磁盘，15k RPM驱动器）

使用RAID 0。条带RAID将提升磁盘的输入/输出，驱动器异常显然会导致潜在的失败。但没有必要使用镜像或奇偶校验版本，因为ES高可用性是通过副本。使用RAID
0是一种提高磁盘速度的有效方法，对于旋转介质和SSD都是这样。
避免为了提供耐用性、共享存储和增长/收缩来达到性能成本而使用EFS。众所周知，这样的文件系统会导致了索引失败，由于ES的分布式和内置复制机制，这些服务的好处是不需要的。
不要使用远程存储，例如NFS 或者 SMB/CIFS。他们介绍的延迟与性能优化背道而驰。
如果你使用EC2，注意EBS。即使是由ssd组成的EBS选项通常也比本地实例慢。EBS在一个小型集群(1-2个节点)上运行良好，但不能承载更大的搜索和索引建设。如果使用EBS，则使用提供的IOPS以保证性能。
最后，避免网络附接存储(NAS)。人们经常声称他们的NAS解决方案比本地驱动器更快、更可靠。虽然有这些说法，但我从未见过NAS大肆宣传。NAS通常较慢，伴随较大的延迟，在平均延迟中有更大的偏差，并且是单点故障。