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