Elasticsearch优化

一、硬件选择

Elasticsearch的基础是 Lucene ，所有的索引和文档数据是存储在本地的磁盘中，具体的路径可在 ES 的配置文件 ../config/elasticsearch.yml 中配置，如下：

磁盘在现代服务器上通常都是瓶颈。Elasticsearch 重度使用磁盘，你的磁盘能处理的吞吐量越大， 你的节点就越稳定。

这里有一些优化磁盘 I/O 的技巧：

1.使用 SSD 。就像其他地方提过的， 他们比机械磁盘优秀多了。

2.使用 RAID 0 。条带化 RAID 会提高磁盘 I/O，代价显然就是当一块硬盘故障时整个就故障了。不要使用镜像或者奇偶校验 RAID 因为副本已经提供了这个功能。

3.另外，使用多块硬盘，并允许 Elasticsearch 通过多个 path.data 目录配置把数据条带化分配到它们上面。

4.不要使用远程挂载的存储，比如 NFS 或者 SMB/CIFS 。这个引入的延迟对性能来说完全是背道而驰的。

# ----------------------------------- Paths ------------------------------------
#
# Path to directory where to store the data (separate multiple locations by comma):
#
#path.data: /path/to/data
#
# Path to log files:
#
#path.logs: /path/to/logs

二、分片策略 2.1 合理设置分片数

分片和副本的设计为ES 提供了支持分布式和故障转移的特性，但并不意味着分片和副本是可以无限分配的。

而且索引的分片完成分配后由于索引的路由机制，我们是不能重新修改分片数的。

可能有人会说，我不知道这个索引将来会变得多大，并且过后我也不能更改索引的大小，所以为了保险起见，还是给它设为 1000 个分片吧 。

但是需要知道的是，一个分片并不是没有代价的。需要了解：

1.一个分片的底层即为一个 Lucene 索引，会消耗一定文件句柄、内存、以及 CPU 运转。

2.每一个搜索请求都需要命中索引中的每一个分片，如果每一个分片都处于不同的节点还好， 但如果多个分片都需要在同一个节点上竞争使用相同的资源就有些糟糕了。

3.用于计算相关度的词项统计信息是基于分片的。如果有许多分片，每一个都只有很少的数据会导致很低的相关度。

一个业务索引具体需要分配多少分片可能需要架构师和技术人员对业务的增长有个预先的判断，横向扩展应当分阶段进行。为下一阶段准备好足够的资源。

只有当你进入到下一个阶段，你才有时间思考需要作出哪些改变来达到这个阶段。

一般来说，我们遵循一些原则：

1.控制每个分片占用的硬盘容量不超过 ES 的最大 JVM 的堆空间设置（一般设置不超过 32G ，参考下文的 JVM 设置原则），因此，如果索引的总容量在 500G 左右，

那分片大小在 16 个左右即可；当然，最好同时考虑原则 2 。

2.考虑一下 node 数量，一般一个节点有时候就是一台物理机，如果分片数过多，大大超过了节点数，很可能会导致一个节点上存在多个分片，一旦该节点故障，

即使保持了 1 个以上的副本，同样有可能会导致数据丢失，集群无法恢复。所以， 一般都设置分片数不超过节点数的 3 倍。

3.主分片，副本和节点最大数之间数量，我们分配的时候可以参考以下关系：

节点数