Elasticsearch是一把梭,用起来再说?!
0、题记
Elastic中文社区和各种Elastic爱好者交流群中会遇到形形色色的问题。
来自运维球友讨论的真实线上吐槽问题总结:
问题1:开发不规范。
我们这边es 都是我们在推,很多开发不会用或者用的不规范!
问题2:不管性能,用起来再说!
场景1:我们这边开发只要work,管他wildcard,能模糊就好,管他内存,windows size死命地设,不管多少页都让它翻。
问题3:不评估可行性和高可用性,先搞起来。
场景1, 我们还在2.x,这些开发的大爷可以把size给你堆几万!
场景2, 那你叫产品看百度嘛,你搜个东西,前几页就有你想要的,会不会翻到10页以后?
场景3, 对嘛,好多公司都是后台开发用ES,也许是为了缓解MySQL其他库的查询压力就不管ES这边的性能效率了,几万条数据都往回吐。
如下图,某公司26岁的程序员王某的Elasitcsearch一把梭用法,能很形象的说出了问题产生的根因。
这里引发大家思考:Elasticsearch到底是不是一把梭,用起来再说?!还是有更好的方式?
快速部署、快速增删改查、快速上线就完了吗?遇到问题怎么办?
我把常见问题总结为常见的坑,希望您实战中能避免踩坑。
1、坑1:不重视安全。
2019年12月初安全事件《Elasticsearch27亿数据泄露,10亿明文,波及中国大厂》。看到类似自媒体标题就很容易让人恐慌。社区小伙伴真实中招案例如下:
根因:用起来再说,没有考虑安全,端口直接暴露公网,机器相当于裸奔。
社区创始人Medcl大神说: 不要等到出事了才想起做基本的安全配置!
社区主席刘征老师比喻恰如其分:
-
1,es集群像是一套房子,有门也有锁,以前大家不舍得买这把锁,结果小偷推门就进去了,用户被盗极大的影响使用体验,现在锁也免费了随房屋附送了,请大家谨记上班出门的时候一定锁好门,es也一样,没升级的赶紧升级,没加锁,也没用锁门习惯的赶紧养成好习惯
-
2,送的锁可能需要拆盒安装一下,这个动作用户需要知道,房子里的财产的估值决定了你是否做这个动作!!很形象的比喻。
安全咱们多次强调了:
干货 | Elasticsearch7.X X-Pack基础安全实操详解
官方文档:Elasticsearch安全功能使您可以轻松保护集群。您可以用密码保护数据,并实施更高级的安全措施,例如加密通信,基于角色的访问控制,IP过滤和审核。
https://www.elastic.co/guide/en/elasticsearch/reference/7.5/configuring-security.html
2、坑2:不规划集群,出了问题再说。
实战问题:
.....当时建的时候没考虑好,按默认的建了5个分片,版本是6.0.0. 之前是用mysql的,刚迁过来,没想到数据量非常大,基本每天增长1.5G左右。原来计划数据至少要保存一年。.....知识星球讨论
建议:不要等数据量大了、磁盘满了、性能出问题、并行写入被拒绝了等再考虑规划集群。
实战部署之前建议思考问题:
0、站在巨人的肩上,不闭门造车,查各种资料,总结思考别人如何规划集群的?
1、一共要存储多少全量数据?
2、存储周期是多长?
3、每天增量数据是多少?
4、客户期望的QPS/TPS指标是多少?
5、需要几个节点,如何划分节点角色?
6、是否有冷热数据之分?
7、业务层面分几个索引?
8、每个索引分几个分片?
9、单分片最大支持的数据量?
10、要不要删除历史数据,如何删除等?
注意:任何别人的建议都是基于特定的场景,特定的物理环境,特定的ES版本及特定的集群规模等实施的,如果在规划前自己拿不准,建议通过esrally等测试工具验证一下。
集群规划推荐:
探究 | Elasticsearch集群规模和容量规划的底层逻辑
3、坑3:不设置副本、数据不备份,导致数据丢失。
业务场景不同,自行决定数据是否需要副本和备份。
但是相对高可用的场景,建议副本数至少设置为1。
设置副本好处:
-
提升检索的高可用性;
-
读操作并行,分担集群压力。
副本数量要可受控。
理想最小值:1;最大值:节点数-1。
平衡点:增量基准测试是一种很好的缩小范围的方法。逐步添加副本,并测量每个新副本的性能改进。如果改进不明显,副本数可能不适宜调太高。
参考:
https://bonsai.io/blog/ideal-elasticsearch-cluster/
如上截图的极限情况会造成数据丢失的。
高可用的场景除了设置副本,建议定期做增量快照,确保数据丢失后可恢复,不影响线上业务。
4、坑4:不考虑建模,导致性能问题。
数据建模的重要性,无需赘述。
1、使用模板和别名规划索引,必要时结合Ingest。
2、尽量自己显示定义Mapping,不采用动态生成的Mapping。
3、根据业务场景,选择适合自己业务场景的分词器。
4、Mysql的多表关联,在ES中对应选择:宽表存储、nested存储(子文档更新不频繁)、join父子文档(子文档更新频繁)。
5、根据实际业务需要选定合适的字段,以最大化优化存储。如:是否分词、是否聚合、是否存储等。
上面截图也展示了keyword较数值型的性能优势,选型时也需要斟酌提前考虑。
这些问题先写入数据,后考虑可以不?
可以,但, 不专业。
如果是海量数据,reindex迁移数据都会花费您很长时间。
5、坑5:不重视官网基础,自认为一切在掌控之中。
坑 5.1:多集群一台机器部署,相同的path.data路径,无异于自杀。
血淋淋的线上教训:详见如下:群友真实案例。大家多注意!
以后多注意:
- 1,数据目录:path.data不要多集群共享。
- 2,最好一个机器一个集群节点,如果机器配置高可以考虑分虚拟机或者docker虚拟化或者其他,但path.data切记不要一样。
坑 5.2:参数配置不合理导致脑裂。
6.x 版本,2节点,minimum_master_nodes最小主机节点数设置1,运行很长一段时间未知原因导致脑裂。
剖析原因:没有按照官方文档配置。最小主力节点数=候选主机节点/2+1,应该配置2才可能不脑裂。
6.X官方明确说明:To avoid a split brain, this setting should be set to a quorum of master-eligible nodes: (master_eligible_nodes / 2) + 1
我现在用7.X了,还要考虑吗?
注意:在 Elasticsearch 7.0 中,重新设计并重建了集群协调子系统:移除了 minimum_master_nodes 设置,让 Elasticsearch 自己选择可以形成法定数量的节点。
- 好处1:用户无需设置最小主节点个数了,集群层面给解决了。
- 好处2:避免用户配置错误导致出现脑裂问题。
- 好处3:选主更快了。
视频demo 演示:
https://discuss.elastic.co/t/avoid-split-brain-with-new-elasticsearch-7-0-after-discovery-zen-minimum-master-nodes-removal/176877
https://www.elastic.co/cn/blog/a-new-era-for-cluster-coordination-in-elasticsearch
https://www.elastic.co/guide/en/elasticsearch/reference/6.8/discovery-settings.html
坑 5.3:堆内存不合理设置
群友反馈:线上环境:集群节点内存大小为64GB,堆内存设置4g。
出现问题:es启动前后内存比例太大,堆被打满。
复盘:问题很明显了 堆设置不合理。
建议:min(机器内存/2,32GB)
https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html
坑 5.4:磁盘使用NAS 导致拒绝请求
各位好,请教一个问题:挂载nas-SSD的es(docker)集群,1个master,2个协调,18个data节点,每个16核32g。大量查询时会出现拒绝请求的情况,nas的数据是每秒1.2g,延迟5ms。会出现rejected的情况。微信群讨论
导致的原因估计是宿主机的io在异常时95+,不确定是主机瓶颈还是网络或者nas的瓶颈。各位有什么方案或建议吗?
已经在业务和参数做了一些优化了。我现在想到的是:
- 1.换物理机挂本地磁盘
- 2.现在path.data都是挂一个nas,换成多个path.data,目前还不清楚负载是否均衡
回复:nas官方不推荐,会有性能问题。
官方文档 提示:
- 避免使用网络附加存储(NAS)。人们常声称他们的 NAS 解决方案比本地驱动器更快更可靠。
- 除却这些声称, 我们从没看到 NAS 能配得上它的大肆宣传。NAS 常常很慢,显露出更大的延时和更宽的平均延时方差,而且它是单点故障的。
Always use local storage, remote filesystems such as NFS or SMB should be avoided. Also beware of virtualized storage such as Amazon’s Elastic Block Storage.
官网地址:
https://www.elastic.co/guide/en/elasticsearch/reference/7.x/tune-for-indexing-speed.html
https://www.elastic.co/guide/cn/elasticsearch/guide/current/hardware.html
6、 我知道了这些坑又如何,怎么破?
以上坑都值得我们开发、运维实际方案选型、可行性分析、方案评估、业务实战中反思。避免类似问题发生。
了解和掌握中间隔了十万八千里(包括我自己也存在 认知问题)。
6.1、重视官方文档同时多调研
一定要优先核对官方文档。比如:wildcard前缀匹配少用或者不用。
你习得别人分享的 坑,就是你业务中需要避免的点。
类似的坑,性能分析的文章,都会有提示。
6.2、别着急动手,先预研实践一把
摸着石头先过河,主要看水多深,能不能过去。
比如:深度翻页,from size. 要不要翻页100页之后,甚至1000页之后。
业务产品经理就这么要求怎么办?
给出测试时间数据,让架构层参与一起评估。
同时:给出scroll scroll after slice等解决方案。
6.3、在前期就要考虑性能
- 1, 准备多少台服务器?
硬件配置 cpu 内存 磁盘,堆内存等都得考虑。
- 2,业务层面支持多少并发?写入速率?查询返回时间的要求指标?
都是需要关注的点。运维考虑我需要哪些硬件资源、优化配置以提供支撑?
开发考虑:我怎么优化查询、优化业务细节。多考虑、多考虑、多考虑。
- 3, 提前避免导致慢查询、gc相关的操作。
包含不限于:优化配值、预热缓存机制、冷热架构集群机制、合理控制分片、按时间规划切分索引、模板、别名、静态mapping、最优检索等等。
6.4,切记Elasticsearch不是一把梭,快了就是慢了!
的确,数据量不大,部署、数据导入、增删改查搞定的瞬间,感觉ES“不就那么回事吗?有什么难的?”
这么想的时候,就是可能危险的时候!
用就得好好用,参考 第一手资料官方文档。而不是各种网上搜到的片段。
6.5 考虑版本升级
群友还有1.X,2.X,5.X的不少钉子户存在,碍于各种原因(jie kou),不能升级。
不升级,体会不到性能优势和新功能点(尤其)。
现在不升级,时间长了徒伤悲。
后面会相对更麻烦。推荐看下升级7.x的10个理由。
不尽兴,欢迎留言讨论您实战中遇到的坑。也欢迎交流您的"一把梭"用法!