Elasticsearch开发运维实战核心Tips都有哪些,相信很多没有经验的人对此束手无策,为此本文总结了问题出现的原因和解决方法,通过这篇文章希望你能解决这个问题。
1、集群规划层面
注意评估节点的硬盘空间。 结合esrally等第三方工具评估集群资源的写入、检索的吞吐率等指标。 合理配置每个索引的分片数。
2、数据预处理层面
3、数据建模层面
比起严格模式,我更喜欢动态mapping,通过字段名字的前缀映射类型,自从用了这套规则,字段冲突导致的kibana无法作报表的问题一扫而光啊,真的是不要太香了 。 是否需要打分,是否需要排序、聚合、过滤,如果不需要则(doc_values(dvm、dvd) norm(nvd、nvm))属性需要关闭等等。 模板 template 比 mapping 更灵活,推荐结合别名多使用动态模板,尤其数据量每日增量巨大的业务场景。 字段非常明确固定、且未来不会新增字段,考虑mapping创建时设置:"dynamic": "strict", 以严格控制Mapping泛滥。 结合业务选择分词器甚至自定义分词器。
4、检索层面
indexSort能通过预排序有效避免全局扫描,提前中断查询,提升查询性能,对于查询时按照某列排序(注意不适合相关性排序)的场景非常适合。
查询根据业务实际考虑,建议最好把 Wildcard 模糊查询、*.*等会导致数据量大的查询做限制。 限制limit +offset,限制query_string等文本查询的长度,限制term长度,随时关注慢查询日志。es是很强大,但是取决你怎么使用,你永远不知道会怎么调你的接口…
5、硬件资源层面
5.1 磁盘层面
磁盘大小是否充足,压缩格式使用默认speed Compression? 还是 Best Compression?
5.2 内存层面
采用默认NIOFS 还是MMAP,采用MMAP哪些需要预缓存到堆外。
6、集群管理层面
记得配置延时分片 index.unassigned.node_left.delayed_timeout。 refresh、flush时间根据的实际业务需求调整。 对集群的性能监控越全面越好, 及时发现慢查询,尽可能全面的根据业务评估使用量, 并能在瓶颈期发现和升级配置。 多节点集群,合理划分节点角色,尤其要分离:主节点、数据节点、协调节点。
7、安全及灾备层面
禁用批量删除索引比默认的随意删除重要。 定期或者增量备份比无备份重要(条件允许的情况下)。 安全问题是必须的,我们是在日志清晰的时候做的核心字段加密,elk 整个技术栈都只允许内网访问,对外的服务接口也是要软 token 的。 将 ES 提供给业务研发去使用,更多的是需要考虑控制权限,降低门槛,最好是封装一层网管提供给业务研发使用,然后再去多分享培训,提高业务侧研发对ES的认知。
8、性能优化层面
关闭系统swap。 如果数据量大,尽可能使用bulk 批量操作。
(1)写入层面bulk操作,包含但不限于:bulk API 执行批量写入、更新、删除多文档操作。
(2)检索层面bulk操作,包含但不限于:Multi Get(mget), Scorll, MultiSearch。
看完上述内容,你们掌握Elasticsearch开发运维实战核心Tips都有哪些的方法了吗?如果还想学到更多技能或想了解更多相关内容,欢迎关注编程之家行业资讯频道,感谢各位的阅读!
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。