感觉针对ES的优化可以有这么几块儿
上面的1,2,3,4之间可能之间会有交叉,比如索引设置delay_allocation 是属于索引设计的优化,同时也是集群稳定性的优化,也算是针对集群的优化。可以先按照自己的思路准备一下。
这个是偏向于集群的搭建设计,在搭建一个集群的时候。首先我们要考虑是的我们的业务场景,数据量,查询和写入的量级,根据这个来规划集群的节点数量和节点的配置。其次是集群的一些高可用的保证以及安全相关的保证(近几年很多数据泄露事件都是因为ES导致)。
在集群的资源的选择上大概有一些基础的原则
副本数最好大于等于一,来提供更高的可用性,同时也可以使用多集群的方式来提供更高的可用性,前置nginx来做代理
安全相关的设置,基于用户名和密码访问,提供更好的安全性,而且尽量不要暴露到外网当中
监控,在状态为yellow等能够报警
索引单个分片尽量不大于50G,一般20G左右差不多(因为考虑到索引混部,单个节点的内存容量)
索引的副本数>=1,提供一些冗余,如果是高读取,低写入的索引,可以增加副本的数量
配置索引的慢查询日志,并且监控
Unsigined_delay,在节点失败之后,延迟分配,这样可以降低集群的抖动,因为一般情况下我们都会监控集群的稳定性,在yellow的时候会人工check干预
使用alias来使用索引,实际底层可以在不同时刻关联不同的索引
手动设置不同的字段的mapping,关闭动态的mapping,防止脏数据插入
具体的字段设置,text字段可以使用 ik+(standard+match_phrase)
同义词插件,自定义词典
使用ssd,内存更大一些,也可以调整write_buffer
调整refresh的时间间隔
使用bulk的写入方式,同时可以叠加多线程的写入
也可以优化translog,改成异步的,但是这个会对数据的一致性造成影响
查询优化,我觉得这个要具体情况具体分析,主要可以从两个方面入手。
第一个是集群的整体负载如何,如果集群的整体负载已经比较高了cpu高,load高,那么更可能是集群资源不太够,这个时候可以对集群进行扩容,让内存磁盘比例更高一些,配置更好的磁盘ssd,cpu核数多一些。
第二种情况是,进群整体的负载并不高,这个时候我们通过slowlog来看看是哪些查询比较慢。分析这些query的结构,可以用es的profile调试,来看看查询慢在哪个环节。调整的话一般有两个途径,
可以偏向于架构和基础层面一些?