文章目录
- 优化总结
- 一、硬件选择
- 二、分片策略
- 1. 合理设置分片数
- 2. 路由选择
- 三、写入速度优化
- 3.1 批量数据提交
- 3.2 优化存储设备
- 3.3 合理使用合并
- 3.4 减少Refresh次数
- 3.5 加大Flush设置
- 3.6 减少副本数量
- 四、内存设置
- 五、重要配置
优化总结
- 采用SSD固态硬盘
- 合理分配分片数量（非越多越好）
- 按业务调整刷盘时机
- 内存不超过32G
- 采用批量插入
一、硬件选择
- 使用SSD固态硬盘
- 避免外挂存储（如NFS）
二、分片策略
1. 合理设置分片数
- 控制单分片容量不超过ES最大JVM堆空间（通常≤32G），如500G索引约需16个分片
- 分片数不超过节点数的3倍（避免单节点多分片导致故障风险）
- 数量关系参考：节点数≤主分片数×（副本数+1）
2. 路由选择
- 分片计算方式：
shard = hash(routing) % number_of_primary_shards（routing默认为文档ID，可自定义如用户ID） - 不带路由查询：请求全部分片，协调节点汇总排序后返回
- 带路由查询（如userid）：可直接定位数据所在分片
三、写入速度优化
3.1 批量数据提交
使用_bulk API，单次批量建议5-15MB（约1000-5000条文档）
3.2 优化存储设备
优先使用SSD
3.3 合理使用合并
- 设置
index.merge.policy.max_merged_segment（如5GB），避免过大段导致IO峰值 - 减少手动触发合并（_forcemerge）
3.4 减少Refresh次数
调大index.refresh_interval（如30秒或1分钟），减少刷新频率（需接受数据可见延迟）
3.5 加大Flush设置
调大index.translog.flush_threshold_size（如1GB）或index.translog.sync_interval，减少Flush次数（注意：未刷盘时节点故障可能丢失数据）
3.6 减少副本数量
临时场景（如全量导入）可将副本数设为0（number_of_replicas: 0），完成后恢复
四、内存设置
- 建议
-Xms与-Xmx值相同，为物理内存的50%且≤31GB（非越大越好）
五、重要配置
| 参数名 | 参数值 | 说明 |
|---|---|---|
| cluster.name | elasticsearch | 集群名称，建议与数据相关，同网段同名节点可自动发现 |
| node.name | node-1 | 集群内唯一节点名，可设为主机名（如node.name:${HOSTNAME}） |
| node.master | true | 是否为候选主节点（需选举确定） |
| node.data | true | 是否存储索引数据（数据操作在此类节点完成） |
| index.number_of_shards | 1 | 默认索引分片数，可创建时调整（数据量小时设为1效率高） |
| index.number_of_replicas | 1 | 默认索引副本数，副本越多可用性越好但写入同步开销越大 |
| transport.tcp.compress | true | 节点间数据传输是否压缩（默认不压缩） |
| discovery.zen.minimum_master_nodes | 1 | 选举主节点所需最少候选节点数，合理值为(master_eligible_nodes/2)+1（避免脑裂） |
| discovery.zen.ping.timeout | 3s | 节点发现时Ping超时时间，网络差时可调大（防止误判节点状态） |
