Elasticsearch 读写性能优化

通用且成本高的方案 - hot warm架构

在资源充足的情况下，使用高性能服务器（CPU充足和SSD磁盘）作为hot节点，数据首先写入hot节点，将基本不再有写入和读取的索引放在warm节点（CPU和磁盘性能较低）

节点角色独立

拆分专属角色

• master 仅作为matser节点，管理集群元数据，不负责请求转发和数据存储
• client 仅负责接受客户端请求，并分发至数据节点并汇总数据
• data 仅作为数据存储节点，不直接接受客户端请求

合理设置索引分片

• 将索引的分片在集群各个数据节点分布均衡
• 合理设置分片数，按照但分片10G的大小分布，不建议单分片超过50G

系统参数

• 禁用swap
• 句柄数

其他解决方案：

数据写入

1.合理定义mapping
根据需求，进行数据写入时，减少磁盘写入数据，比如

PUT test1
{
  "mappings": {
    "properties": {
      "name":{
        "type": "keyword"
      },
      "age":{
        "type": "integer"
      },
      "sex":{
        "type": "keyword"
      }
    }
  }
}

实际查询场景下，不需要根据sex作为索引条件，只需要在返回字段中包含即可,将mapping中的该字段index属性设为false

PUT test1
{
  "mappings": {
    "properties": {
      "name":{
        "type": "keyword"
      },
      "age":{
        "type": "integer"
      },
      "sex":{
        "type": "keyword",
        "index": false
        
      }
    }
  }
}

类型为keyword时默认不分词，

2 当对数据可见的时效性不高的场景下
增大index.refresh_interval（默认为1s）

3 尽可能使用ES生成的id

4 提高 translog flush，减少刷盘操作，降低IO压力

5 批量写入优于单条写入，设置合理的批量数

6 bulk线程池和队列大小
线程数量配置为 1 + # of available processors
队列根据集群实际情况，适当调整默认为50

数据读取

1 ES作为Hbase的二级索引的使用场景中
ES需要返回的数据保证能拼接成Hbase的rowkey，可以减少source字段的返回，或者将ES 的id作为Hbase的rowkey情况下，不需要返回source，只返回id,减少ES读取数据压力，也提高接口性能。

2 精确匹配场景下使用filter ，屏蔽评分机制，使用cache

3 search线程池和队列大小
线程数量配置为 int((# of available_processors * 3) / 2) + 1
队列根据集群实际情况，适当调整默认为1000

4 forcemerge索引，段合并