回复
干货 | 中小企业选型 Elasticsearch 避坑指南
love374
发布于 2023-5-19 17:33
浏览
0收藏
1、线上常见问题
在我线下对接企业或线上交流的时候，经常会遇到各种业务场景不同的问题。
比如，常见问题归类如下：
- 常见问题1：ES 适合场景及架构选型问题。
公司的核心业务是做企业员工健康管理，数据来自电子化后的员工体检报告以及各种健康数据采集设备，均存储在关系型数据库中。
先计划搞健康大数据分析，比如某企业内按部门，年龄段等对现有数据对比分析等。请问ES适合这个场景使用吗？如果适合，大致的架构是怎样的？
- 常见问题2：节点偶然下线问题。
运输数据场景，批量写入导致 ES 宕机，集群偶然下线后导致无法上线，怎么解决？
- 常见问题3：数据不一致问题。
在原有的集群规模的数据非常大的基础上，要删除接近2/3的数据。这时候，两个集群出现了数据不一致的情况，如何排查？
- 常见问题4：集群重启时间超过20小时以上。
超过8小时的时候，没有引起重视，后面起不起来了，才发现是大问题。
实地环境排查及大量沟通发现，这些后期出现的问题或者“坑”，前期规避的话，成本会更低。
2、发现的潜在的“坑”
如下的坑，都是中小型企业现场环境排查、腾讯会议交流等发现的。
提前声明：对于一些大型企业、大厂不见得适用，毕竟场景不同，得具体问题具体分析。
（1）没有选择相对新的8.X版本，而是选择了 6.X版本。
原因：对接 API 方便。
（2）一台高配物理机（如：256GB内存，64核CPU）部署一个节点，资源利用率非常低。
（3）不熟悉 Linux，集群部署依然基于 Windows 服务器。
（4）数据同步工具自己开发“另起炉灶”，关键功能和性能尚不如 Logstash等成熟工具。
（5）主分片设定未考虑集群未来的可横向扩展性。
（6）批量写入不考虑集群性能上限，直至节点宕机脱离集群。
（7）不借助可视化工具：Kibana monitoring 监控集群，甚至 head 插件也没有用起来，出现问题不知道如何排查。
（8）命令行 DSL 仍然借助 Postman 等工具实现。
（9）Wildcard 模糊匹配召回结果符合预期，就大量不计后果的使用。
（10）查询细节参数不了解，能用起来就不关心其他。
3、Elasticsearch 常见认知“误区”
- 认知误区1：Elasticsearch 是关系型数据库。
实际上，Elasticsearch是非关系型数据库，不支持严格的关系数据模型，而是采用文档型存储。
探究 | Elasticsearch 与传统数据库界限
- 认知误区2：Elasticsearch 只适用于搜索。
Elasticsearch不仅适用于搜索，还支持聚合、分析等功能。
- 认知误区3：Elasticsearch 无需预处理数据。
Elasticsearch需要预处理数据，并对数据结构有严格的要求，否则可能导致检索效果不佳。
- 认知误区4：Elasticsearch 可以无限扩展。
（1）纵向扩展得看机器是否支持动态扩内存、CPU等资源，取决于硬件。
（2）横向扩展得看多节点集群规模能否适配性能指标，不见得是机器越多越好。
- 认知误区5：Elasticsearch 安全性很高。
Elasticsearch 本身 7.1 之前不提供严格的安全性，需要通过相关的插件或配置来实现安全性。7.1（含）之后 xpack 基础功能免费，8.X 之后安全成为必选项！
- 认知误区6：Elasticsearch 无需维护。
不止要维护，Elasticsearch 需要定期维护，包括数据备份（借助快照和恢复功能）、性能优化、安全更新等。
4、避坑方案探讨
4.1 Elasticsearch 版本及架构选型避坑
关于版本选型，Elastic 官方工程师如是说：“我完全理解稳定性是最重要的问题。在那种情况下，我们不应该选择最新版本的 Elasticsearch。作为参考，所有当前和过去的版本都可以在此页面上找到......作为一种模式，我建议比最新版本早发布 4 到 6 个月的版本”。——来自阮一鸣老师和ES官方的讨论帖。
关于版本选型，张超老师说“对稳定性要求比较高的生产，不要用最新的版本，谁不也知道有没有严重 bug，往前推一些，看看社区反馈没有大问题的版本，修正版本号用最高的”。
如下几点要谨慎考虑：
- 考虑功能要求：选择支持我们需要的功能的版本，比如：xpack 功能7.1之后才免费，ilm功能 6.7 版本才推出。
- 考虑兼容性：确保您选择的版本与正在使用的其他软件和工具兼容，比如：java、python客户端的选择。
- 考虑数据量: Elasticsearch是否能够满足数据存储和处理的要求？
- 考虑硬件资源：使用Elasticsearch需要充足的硬件资源，包括内存，硬盘，带宽等。
- 考虑集群架构：要根据业务需求选择合适的集群架构，并考虑到集群的可用性和扩展性。
历史版本下载地址：
https://www.elastic.co/cn/downloads/past-releases#ela...
- Elasticsearch架构选型指南——不止是搜索引擎，还有......
- 干货 | Elasticsearch方案选型必须了解的10件事！
- 干货 | Elasticsearch Java 客户端演进历史和选型指南
4.2 Elasticsearch 常用工具避坑
“工欲善其事必先利其器”，没有工具，效率无从谈起。
推荐优先级：Kibana > Head / cerebro > Postman。
学会使用：Kibana Dev Tool，并用好 ctrl + i 快捷键。
学会使用：Kibana monitor 监控可视化工具。
更多推荐：
4.3 Elasticsearch 集群避坑
结合集群能承载的总数据量、每日的增量，在有预留的前提下，给出集群规模的评估。避免“拍脑袋”，要理性计算给出实际参考依据。
布局好节点角色，早期版本叫节点类型。要知道节点角色更为便捷。
确定是否需要冷热集群架构，区分：热节点、温节点、冷节点。冷热集群架构是 ILM 的前提，没有它，ILM无从谈起。
更多推荐：
探究 | Elasticsearch集群规模和容量规划的底层逻辑
干货 | Elasticsearch 8.X 节点角色划分深入详解
4.4 Elasticsearch 索引避坑
确定是否需要 ILM 索引生命周期管理，而不是仅适用 rollover + 脚本自己维护方式或借助 curator 实现。用好 Kibana 可视化管理好 ILM。
考虑索引承载数据上限和大索引可能带来的风险，提前做好业务层面的布局，不同业务使用不同索引，不要混用。
能用模板 template 的就不要单独使用 index。
能支持 datastream 数据流（智能别名）就大胆使用。
模板和别名搭配、索引和别名搭配，干活不累。
定期备份集群索引数据，尤其业务索引，并准备恢复方案，以防数据丢失。
数据迁移需要认真计划，以防迁移不当可能导致数据丢失或损坏问题。
更多推荐：
- Elasticsearch ILM 索引生命周期管理常见坑及避坑指南
- 干货 | Elasticsearch 索引生命周期管理 ILM 实战指南
- Elasticsearch 7.X data stream 深入详解
- Elasticsearch 快照生命周期管理 (SLM) 实战指南
- 干货 | Elasitcsearch7.X集群/索引备份与恢复实战
4.5 Elasticsearch 分片避坑
由于路由机制原因，不同于副本分片支持 update 动态更新，Elasticsearch 主分片数一旦设定就不能动态更新，除非 reindex。
分片设置要不仅满足当下集群的需求，也要考虑集群的未来可扩展性。
单分片大小参见官方的 30GB-50GB的优化建议（因场景而异，可能微调）。
更多推荐：
4.6 Elasticsearch 同步工具避坑
能借助 Ingest 预处理功能解决的，就不要使用 logstash。
能使用 logstash 解决基于时间递增和基于id递增同步的，就不要自己开发。
衡量好 Kafka_connector 和 logstash 的性能和适用场景。
阿里的 canal 工具在同步删除和更新操作时，要优先选择，因为 logstash 不支持同步更新和删除操作。
更多推荐：
- Elasticsearch的ETL利器——Ingest节点
- Elasticsearch 预处理没有奇技淫巧，请先用好这一招！
- 从一个线上问题看 Elasticsearch 数据清洗方式
- 实战 | canal 实现Mysql到Elasticsearch实时增量同步
- 干货 | Logstash Grok数据结构化ETL实战
4.7 Elasticsearch 检索选型避坑
如果查询语句不正确，可能导致查询性能下降，例如查询条件过于复杂、数据量过大等。
首先，建立起 ES 支持的检索类型的全局认知。
其次：
- 区分好：什么是召回率？什么是精准率？
- 区分好：什么是精准匹配，什么是全文检索？
- 区分好：哪些需要评分？哪些不需要评分？
- 区分好：什么叫 query？什么叫filter？
最后：选型成功后，做充分的验证，再部署到线上环境。
涉及性能相关的，要做足检索并发性能测试。
PS：如果所有的已经存在的检索都无法达到业务指标，得考虑分词处下功夫，得考虑空间换时间。
推荐阅读：
- Elasticsearch 8.X 如何实现更精准的检索？
- 实战 | Elasticsearch自定义评分的N种方法
- 干货 | Elasticsearch 检索类型选型指南
- JMeter 如何实现 Elasticsearch 8.X 性能测试？
- esrally 如何进行简单的自定义性能测试？
4.8 Elasticsearch 数据建模避坑
Elasticsearch要求数据结构符合其特定 Mapping 格式，如果数据结构不合适，可能导致数据存储不完整，后续检索可能会非常复杂。
建模问题的核心在于，前期不会发现，往往项目的中后期才会发现。但，一旦发现，返工的概率就会极大，带来了整体工期的延长和效率的降低。
所以，建议设计初期做足准备。
做什么准备呢？
（1）业务层面：不同索引可能跨索引检索，字段的一致性必要性尤为凸显。
（2）能“宽表”就不要或少用 Nested 嵌套字段、Join 多表关联数据类型。
（3）避免字段爆炸，设置 strict 最为严谨，设置dynamic：false相对谨慎，设置默认的 dynamic：true 要慎之又慎，评估好风险。
更多推荐：
- 干货 | Elasticsearch 数据建模指南
- 干货 | Elasticsearch多表关联设计指南
- Elasticsearch 8.X 防止 Mapping “爆炸”的三种方案
4.9 Elasticsearch 运维避坑
不要等出了问题采取看监控，而是动态更新监控指标数据，考虑将集群各节点的健康状态，以定时任务的形式发送到邮箱等。
定期监控集群健康状态，并及时解决任何问题，以保证集群稳定运行。
用好运维监控工具。Kibana monitor、grafana 均可。
日志建议再归集到一个独立的小ES集群，通过 kibana 可视化展示，并对于 Warn 及以上级别日志及时预警。
推荐如下：
（1）使用Elasticsearch的内置监控工具：如Node Stats API和Cluster Stats API，可用于监控节点和集群的性能。
（2）使用 Kibana Monitoring：提供了全面的监控功能，包括集群监控、节点监控、索引监控等。
（3）定期评估集群健康：使用Elasticsearch的Cluster Health API评估集群的健康状况，以检测性能问题。
（4）记录并分析日志：记录并分析Elasticsearch的日志，以诊断性能问题。
（5）设置告警：设置告警，以提醒您有关性能问题的变化。建议和监控工具（如：Zabbix）结合。
更多推荐：
- MetricBeat + Elasticsearch + Kibana 实现监控指标可视化
- 干货 | Elasticsearch Top10 监控指标
- 干货 | Elasticsearch 运维实战常用命令清单
- 干货 | Elasticsearch 集群健康值红色终极解决方案
4.10 Elasticsearch 安全避坑
安全无小事，早期版本（1.X、2.X、5.X、6.X、7.X）“luo奔”导致的安全事故依然屡见不鲜。8.X 的版本已经全线支持默认安全机制，用起来是王道。
如果非要早期版本（5.X、6.X、7.X），建议一定至少加上 xpack 安全机制，至少设置好密码。如果更早版本（1.X、2.X），建议不要开放外网权限，切记！
更多推荐：
5、小结
“坑”是成长过程中的财富，提前关注“坑”能提高开发效率。
欢迎大家就使用 Elasticsearch 过程中遇到的坑留言交流。
文章转载自公众号： 铭毅天下Elasticsearch
分类
已于2023-5-19 17:33:06修改
赞
收藏
回复
相关推荐
