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设计的水平扩容优势。为了更好的适应未来的增长，你最好重新索引数据并指定更多的分片。
优化批请求
-
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通常较慢，伴随较大的延迟，在平均延迟中有更大的偏差，并且是单点故障。