干货 | 中小企业选型 Elasticsearch 避坑指南
Posted 铭毅天下
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了干货 | 中小企业选型 Elasticsearch 避坑指南相关的知识，希望对你有一定的参考价值。
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是非关系型数据库，不支持严格的关系数据模型，而是采用文档型存储。
认知误区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...
https://blog.csdn.net/u013613428/article/details/103317806
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 数据流（智能别名）就大胆使用。
定期备份集群索引数据，尤其业务索引，并准备恢复方案，以防数据丢失。
数据迁移需要认真计划，以防迁移不当可能导致数据丢失或损坏问题。
更多推荐：
4.5 Elasticsearch 分片避坑
由于路由机制原因，不同于副本分片支持 update 动态更新，Elasticsearch 主分片数一旦设定就不能动态更新，除非 reindex。
分片设置要不仅满足当下集群的需求，也要考虑集群的未来可扩展性。
单分片大小参见官方的 30GB-50GB的优化建议（因场景而异，可能微调）。
更多推荐：
4.6 Elasticsearch 同步工具避坑
能借助 Ingest 预处理功能解决的，就不要使用 logstash。
能使用 logstash 解决基于时间递增和基于id递增同步的，就不要自己开发。
衡量好 Kafka_connector 和 logstash 的性能和适用场景。
阿里的 canal 工具在同步删除和更新操作时，要优先选择，因为 logstash 不支持同步更新和删除操作。
更多推荐：
4.7 Elasticsearch 检索选型避坑
如果查询语句不正确，可能导致查询性能下降，例如查询条件过于复杂、数据量过大等。
首先，建立起 ES 支持的检索类型的全局认知。
其次：
区分好：什么是召回率？什么是精准率？
区分好：什么是精准匹配，什么是全文检索？
区分好：哪些需要评分？哪些不需要评分？
区分好：什么叫 query？什么叫 filter？
最后：选型成功后，做充分的验证，再部署到线上环境。
涉及性能相关的，要做足检索并发性能测试。
PS：如果所有的已经存在的检索都无法达到业务指标，得考虑分词处下功夫，得考虑空间换时间。
推荐阅读：
4.8 Elasticsearch 数据建模避坑
Elasticsearch要求数据结构符合其特定 Mapping 格式，如果数据结构不合适，可能导致数据存储不完整，后续检索可能会非常复杂。
建模问题的核心在于，前期不会发现，往往项目的中后期才会发现。但，一旦发现，返工的概率就会极大，带来了整体工期的延长和效率的降低。
所以，建议设计初期做足准备。
做什么准备呢？
（1）业务层面：不同索引可能跨索引检索，字段的一致性必要性尤为凸显。
（2）能“宽表”就不要或少用 Nested 嵌套字段、Join 多表关联数据类型。
（3）避免字段爆炸，设置 strict 最为严谨，设置dynamic：false相对谨慎，设置默认的 dynamic：true 要慎之又慎，评估好风险。
更多推荐：
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）结合。
更多推荐：
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 过程中遇到的坑留言交流。
5、参考
https://articles.zsxq.com/id_oo0h8a5b6b8a.html
https://wx.zsxq.com/dweb2/index/search/%E4%BC%81%E4%B8%9A/alltopics?groupId=225224548581
https://t.zsxq.com/0bUYswMJn
推荐阅读
更短时间更快习得更多干货！
和全球 1800+ Elastic 爱好者一起精进！
比同事抢先一步学习进阶干货！
以上是关于干货 | 中小企业选型 Elasticsearch 避坑指南的主要内容，如果未能解决你的问题，请参考以下文章
干货 | Elasticsearch Java 客户端演进历史和选型指南
干货 | Elasticsearch Java 客户端演进历史和选型指南