ElasticsearchElasticsearch 集群 运维 高性能 架构设计 高负载

Posted 2021-05-16 九师兄

1.概述

转载：干货 |《深入理解Elasticsearch》读书笔记

5.集群扩展

如何扩展集群？

5.1 垂直扩展

向Elasticsearch集群添加更多的资源。制约因素——如：JVM最大支持31GB物理内存。

5.2 水平扩展

索引多分片、多副本，集群中分散处理之。

优点：降低运行集群的成本。版本升级后（如5.X升级到6.0），确保服务仍然可用。

6.架构设计

集群架构设计考虑因素？

当你在设计架构、决定节点数量、有多少个索引以及每个索引的分片数量时，你需要把能接受的出现故障的节点数量考虑进去。

当然了，你还需要考虑性能，只不过冗余和高可用应该是进行扩展时的一个因子。

6.1 节点角色

大规模集群节点角色如何设定？

为了有一个完全容错和高可用的集群，我们应该区分节点，为每个节点一个设计好的角色，角色分类如下：

1）路由节点或查询聚合节点；
发送子查询到其他节点，收集和合并结果，以及响应发出查询的客户端。

node.master: false
node.data: false

2）数据节点；

node.master: false
node.data: true

3）候选主节点。

node.master: true
node.data: false
http.enabled: false

候选主节点禁用Http协议是为了避免意外地在这些节点上进行查询。这样候选主节点相比于数据节点和路由节点可以使用更少的资源，可以确保它们仅仅被用来处理和主节点相关的工作。

8.高负载

高负载场景Elasticsearch优化的常规建议？

8.1 建议

这里是建议，不是准则。

1. 选择正确的存储 如：选择默认的default存储类型。
2. 按需设定刷新频率 索引刷新频率定义：文档需要多长时间才能出现在搜索结果中。

正确认知：

1. 刷新频率越短，查询越慢，且索引文档的吞吐率越低。
2. 默认刷新频率：1s刷新一次。
3. 无限的增加刷新时间是没有意义的，因为超过一定的值（取决于你的数据负载和数据量）之后，性能提升变得微乎其微。

8.2 无

8.3 线程池优化

线程池优化的必要场景：你看到节点正在填充队列并且仍然有计算能力剩余，且这些计算能力可以被指定用于处理待处理的任务。

8.4 调整合并过程

index.merge.policy.mery_factory低于默认值10，会导致更少的段，更低的RAM消耗，更快的查询速度和更慢的索引速度；若大于10，导致索引由更多的分段组成，更高的RAM消耗，更慢的查询速度和更快的索引速度。

8.5 合理数据分布

高索引量的使用场景：把索引分散到多个分片上来降低服务器CPU和I/O子系统的压力。

如果你的节点无法处理查询带来的负载，你可以增加更多的ES节点，并增加副本的数量，于是主分片的物理拷贝会部署到新增节点上。这样会使得文档索引慢一些，但是会给你同时处理更多查询的能力。

9.高负载、高查询频率场景的建议

9.1 启动过滤器缓存和分片查询缓存

过滤器缓存配置：indices.cache.filter.size
分片查询缓存配置：indices.cache.query.enable

9.2 优化查询语句结构

书本中的过滤器已不再使用5.X以及更高版本。但，依然可以优化查询语句，返回核对查询同样语句返回时间，进行权衡优化。

9.3 使用路由

有着相同路由值的数据都会保存到相同的分片上。

9.4 并行查询

建议数据平均分配，多个节点可以有相同的负载。

9.5 字段数据缓存和断路

当使用聚合和排序等字段数据缓存相关操作时，遇到了内存相关的问题（内存泄漏或者GC停顿），可以考虑使用 doc value。

9.6 控制size和shard_size

主要针对聚合操作。

1. 增加size和shard_size能使得聚合结果更准确，代价是：更多的网络开销和内存使用；
2. 减少size和shard_size能使得聚合不那么精确，代价是：网络开销小和内存使用率低。

10 高负载、高索引吞吐量场景

10.1 批量索引

批量索引代替逐个索引文档。

10.2 doc values和索引速度的取舍

1. 一方面：我们只关心更高的索引速度和更大的索引吞吐量，可以考虑不适用doc values。
2. 另一方面：如果有大量的数据，为了使用聚合和排序功能而不产生内存相关问题，唯一选择——使用 doc values。

10.3 控制文档字段

方式一：_source 控制字段输出；
方式二：禁用_all。

减少文档的大小和其内文本字段的数量会让索引稍快一些。

10.4 索引的结构和副本

1. 主分片部署到所有的节点上，以便：并行的索引文档，加快索引的速度。
2. 过多的副本导致索引速度下降。

10.5 调整预写日志。

10.6 存储优化

1. 资金充足，建议购买SSD——原因：速度优势明显；
2. 资金不足，考虑ES使用多个数据路径。
3. 不要使用共享或者远程的文件系统保存索引——原因：速度慢，整体性能下降。

10.7 索引期间的内存缓存

建议给每个索引期间生效的分片分配512MB内存。
indices.memeory.index_buffer_size是设置节点的，而不是分片。

N.参考

原文链接：https://blog.csdn.net/laoyang360/article/details/78554610