Elasticsearch是一把梭,用起来再说?!

标签: | 发表时间:2019-12-25 13:59 | 作者:
出处:https://mp.weixin.qq.com

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] 推荐:

[译]elasticsearch mapping

- - an74520的专栏
es的mapping设置很关键,mapping设置不到位可能导致索引重建. 请看下面各个类型介绍^_^. 每一个JSON字段可以被映射到一个特定的核心类型. JSON本身已经为我们提供了一些输入,支持 string,  integer/ long,  float/ double,  boolean, and  null..

Elasticsearch as Database - taowen - SegmentFault

- -
【北京上地】滴滴出行基础平台部招聘 Elasticsearch 与 Mysql binlog databus 开发工程师. 内推简历投递给: [email protected]. 推销Elasticsearch. 时间序列数据库的秘密(1)—— 介绍. 时间序列数据库的秘密(2)——索引.

ElasticSearch 2 的节点调优(ElasticSearch性能)

- - 行业应用 - ITeye博客
一个ElasticSearch集群需要多少个节点很难用一种明确的方式回答,但是,我们可以将问题细化成一下几个,以便帮助我们更好的了解,如何去设计ElasticSearch节点的数目:. 打算建立多少索引,支持多少应用. elasticsearch版本: elasticsearch-2.x. 需要回答的问题远不止以上这些,但是第五个问题往往是容易被我们忽视的,因为单个ElasticSearch集群有能力支持多索引,也就能支持多个不同应用的使用.

Elasticsearch:使用 Elasticsearch 进行语义搜索

- - 掘金 后端
在数字时代,搜索引擎在通过浏览互联网上的大量可用信息来检索数据方面发挥着重要作用. 此方法涉及用户在搜索栏中输入特定术语或短语,期望搜索引擎返回与这些确切关键字匹配的结果. 虽然关键字搜索对于简化信息检索非常有价值,但它也有其局限性. 主要缺点之一在于它对词汇匹配的依赖. 关键字搜索将查询中的每个单词视为独立的实体,通常会导致结果可能与用户的意图不完全一致.

elasticsearch的javaAPI之query

- - CSDN博客云计算推荐文章
elasticsearch的javaAPI之query API. the Search API允许执行一个搜索查询,返回一个与查询匹配的结果(hits). 它可以在跨一个或多个index上执行, 或者一个或多个types. 查询可以使用提供的 query Java API 或filter Java API.

Elasticsearch基础教程

- - 开源软件 - ITeye博客
转自:http://blog.csdn.net/cnweike/article/details/33736429.     Elasticsearch有几个核心概念. 从一开始理解这些概念会对整个学习过程有莫大的帮助.     接近实时(NRT).         Elasticsearch是一个接近实时的搜索平台.

ElasticSearch索引优化

- - 行业应用 - ITeye博客
ES索引的过程到相对Lucene的索引过程多了分布式数据的扩展,而这ES主要是用tranlog进行各节点之间的数据平衡. 所以从上我可以通过索引的settings进行第一优化:. 这两个参数第一是到tranlog数据达到多少条进行平衡,默认为5000,而这个过程相对而言是比较浪费时间和资源的. 所以我们可以将这个值调大一些还是设为-1关闭,进而手动进行tranlog平衡.

elasticsearch集群搭建

- - zzm
之前对于CDN的日志处理模型是从 . logstash agent==>>redis==>>logstash index==>>elasticsearch==>>kibana3,对于elasticsearch集群搭建,可以把索引进行分片存储,一个索引可以分成若干个片,分别存储到集群里面,而对于集群里面的负载均衡,副本分配,索引动态均衡(根据节点的增加或者减少)都是elasticsearch自己内部完成的,一有情况就会重新进行分配.

Elasticsearch集群入门

- - 编程语言 - ITeye博客
欢迎来到Elasticsearch的奇妙世界,它是优秀的全文检索和分析引擎. 不管你对Elasticsearch和全文检索有没有经验,都不要紧. 我们希望你可以通过这本书,学习并扩展Elasticsearch的知识. 由于这本书也是为初学者准备的,我们决定先简单介绍一般性的全文检索概念,接着再简要概述Elasticsearch.

Elasticsearch 学习笔记

- - 研发管理 - ITeye博客
安装  Elasticsearch. 1:解压下载的安装包 elasticsearch-1.7.2.zip. 修改  node.name: es(集群状态名字一致). 2:在https://github.com/elasticsearch/elasticsearch-servicewrapper下载该插件后,解压缩.