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在裸奔吗?

官方文档: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. 提升检索的高可用性;

  2. 读操作并行,分担集群压力。

副本数量要可受控。

理想最小值: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迁移数据都会花费您很长时间。

干货 | 论Elasticsearch数据建模的重要性

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个理由。

不尽兴,欢迎留言讨论您实战中遇到的坑。也欢迎交流您的"一把梭"用法!


推荐:

重磅 | 死磕Elasticsearch方法论认知清单(2019国庆更新版)

elastic.blog.csdn.net


发布了365 篇原创文章 · 获赞 2844 · 访问量 340万+
展开阅读全文

没有更多推荐了,返回首页

©️2019 CSDN 皮肤主题: 代码科技 设计师: Amelia_0503

分享到微信朋友圈

×

扫一扫,手机浏览