概述

我曾经使用Elasticsearch（以下简称为ES）来进行日志可视化，并在Kibana上进行查看。然而，有一次ES发生超时，导致无法查看日志。原因是ES的分片数量。本文将解释ES的基础知识和导致超时的分片问题，以及相应的解决方案。

Elasticsearch是什么？

这是一个分布式的搜索和分析引擎，可以通过Elasticsearch发送日志并通过Kibana进行可视化，也可以作为全文搜索引擎或APM使用，非常适用于各种广泛的用途。

Elasticsearch的组成要素

节点

可以等同于一个 Elasticsearch 进程。也可以在同一台服务器上启动多个节点。

簇

可以将多个节点作为一个Elasticsearch实例运行，并将这些节点集合称为集群。
通过组成集群，可以将大量数据分散保存在多个节点上。
此外，为了提高可用性和搜索性能，还可以在集群内部拥有副本。

索引

在Elasticsearch中，基本上是以索引为单位来管理数据的，索引是文档集合的表示。相当于关系型数据库中的数据库。通过将索引分散并存储在集群节点上，可以处理大量的数据。用于将索引分散到节点上的单位称为分片。

文件

以下是中文的同义句：Elasticsearch处理数据的最小单元，相当于关系数据库管理系统的一条记录。由于Elasticsearch是无模式的，因此每个文档可以具有不同的结构。

类型

为了在索引中对注册的文档进行逻辑分类的功能。通过使用类型，可以轻松管理索引中保存的各种类型的文档。

碎片

将索引分割为小单元，这个小单元被称为分片。Elasticsearch通过将这些分片分配给集群中的每个节点来分散数据。分片数是可以分散数据的上限数量。

本题：导致Elasticsearch超时的原因。

我之前在概述中提到，Elasticsearch超时的原因是由于上述所讲的分片数量增加。

根据上图所示，JVM内存负载和CPU使用率都很高。关于磁盘容量，问题不大，因为20GB中只使用了10GB。Elasticsearch将索引保存在文件中，在每次搜索时都会访问这些文件。为了高效进行文件访问，官方建议给操作系统配置足够的内存。由于分片数量太多，所使用的内存超过了推荐值，导致搜索效率下降并发生了超时问题。

根据经验，每个节点的碎片数量应该保持在每个堆的GB未超过20以下。

解决方法 (対策)

应对措施 (対策)

应对策略 (対策)

对策 (対策)

方案 (対策)

我发现增加索引数量导致了超时问题，所以我打算通过减少索引数量来解决这个问题。

减少索引的方法

第二种方法的缺点是，通过减少每个索引的分片数来减少分布化的数量，因此性能较差。
关于第四种方法，尽管会增加成本，但可以在不改变当前设置的情况下进行适应。
由于这次问题发生在开发环境的Elasticsearch上，所以通过删除索引可以暂时解决这个问题。

总结

我們從Elasticsearch的基本知識開始，解釋了造成Elasticsearch超時的原因以及對應的解決方法。Elasticsearch通過將數據分散保存在多個節點中，以節點為單位實現了高速搜索，而這種數據分散保存的單位被稱為分片。通過調整索引設置、增加節點數量和提高性能，我們可以確保適當的內存空間，從而建立高效的分析基礎。

请参考

https://www.elastic.co/guide/jp/elasticsearch/reference/current/gs-search-api.html
应该将Elasticsearch集群的分片数设置为多少？
弹性搜索索引模板
重建索引的介绍！
数据分析基础架构入门