Elasticsearch 开发运维实战核心 Tips

本篇内容来自于死磕 Elasticsearch 知识星球的一个做业题目：

Elasticsearch基础但很是重要的功能还有哪些？

0,有安全比裸奔重要！

1,模板template比mapping重要。

2,显式映射 strict mapping比隐式mapping重要！

3,别名重要！

4,结合业务选择甚至自定义分词器比使用默认重要！

请留言写下您的思考。

https://t.zsxq.com/MrjQrfM
有20多人参与，你们把本身架构、开发、运维实战中遇到的核心问题和建议都一股脑写出来了。

我作了扩展梳理，相信对架构、开发、运维都有必定的帮助！

一、集群规划层面
注意评估节点的硬盘空间。
结合esrally等第三方工具评估集群资源的写入、检索的吞吐率等指标。
合理配置每一个索引的分片数。
二、数据预处理层面
数据进 Elasticsearch 前要作清洗。
Elasticsearch 擅长的是检索和不复杂的聚合，其余活给关系型数据库或者第三方大数据开源库如：clickhouse 等。
三、数据建模层面
比起严格模式，我更喜欢动态mapping，经过字段名字的前缀映射类型，自从用了这套规则，字段冲突致使的kibana没法做报表的问题一扫而光啊，真的是不要太香了 。
是否须要打分，是否须要排序、聚合、过滤,若是不须要则(doc_values(dvm、dvd) norm(nvd、nvm))属性须要关闭等等。
模板 template 比 mapping 更灵活，推荐结合别名多使用动态模板，尤为数据量每日增量巨大的业务场景。
字段很是明确固定、且将来不会新增字段，考虑mapping建立时设置："dynamic": "strict", 以严格控制Mapping泛滥。
结合业务选择分词器甚至自定义分词器。
四、检索层面
若是须要考虑查询速度的优化，且排序字段基本固定，则能够考虑把 indexSort 配上，查询时会提早中断。
indexSort能经过预排序有效避免全局扫描，提早中断查询，提高查询性能，对于查询时按照某列排序（注意不适合相关性排序）的场景很是适合。

查询根据业务实际考虑，建议最好把 Wildcard 模糊查询、.等会致使数据量大的查询作限制。
限制limit +offset，限制query_string等文本查询的长度，限制term长度，随时关注慢查询日志。es是很强大，可是取决你怎么使用，你永远不知道会怎么调你的接口…
五、硬件资源层面
5.1 磁盘层面
磁盘大小是否充足，压缩格式使用默认speed Compression? 仍是 Best Compression?
5.2 内存层面
采用默认NIOFS 仍是MMAP，采用MMAP哪些须要预缓存到堆外。
六、集群管理层面
记得配置延时分片 index.unassigned.node_left.delayed_timeout。
refresh、flush时间根据的实际业务需求调整。
对集群的性能监控越全面越好, 及时发现慢查询，尽量全面的根据业务评估使用量, 并能在瓶颈期发现和升级配置。
多节点集群，合理划分节点角色，尤为要分离：主节点、数据节点、协调节点。
七、安全及灾备层面
禁用批量删除索引比默认的随意删除重要。
按期或者增量备份比无备份重要(条件容许的状况下)。
安全问题是必须的，咱们是在日志清晰的时候作的核心字段加密，elk 整个技术栈都只容许内网访问，对外的服务接口也是要软 token 的。
将 ES 提供给业务研发去使用，更多的是须要考虑控制权限，下降门槛，最好是封装一层网管提供给业务研发使用，而后再去多分享培训，提升业务侧研发对ES的认知。
八、性能优化层面
关闭系统swap。
若是数据量大，尽量使用bulk 批量操做。
（1）写入层面bulk操做，包含但不限于：bulk API 执行批量写入、更新、删除多文档操做。

（2）检索层面bulk操做，包含但不限于：Multi Get（mget）， Scorll， MultiSearch。

建议根据业务需求较早的设置开启慢查询日志。
堆内存大小不要超过32GB。
使用script 脚本时，要考虑可能带来的慢、安全风险（早期版本）等负面影响。
在必定条件下，执行强制合并segment，查询速度会提高不少。
九、小结
从各个层面列举了你们实战中关心且常忽视的Tips，不求全，但求有用。

由于 Tips 涉及内容多，没有各个点展开。更多细节欢迎留言交流。

你们有实战中更好的Tips，也欢迎留言交流一下。