Elasticsearch是一把梭，用起来再说？！

来自运维球友讨论的真实线上吐槽问题总结：

问题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；最大值：节点数-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个理由。

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