Elasticsearch在大数据和AI等相关应用场景的使用被更多人关注，但相关资料较少、排查问题困难，运维难点难以突破。本文作者将结合某行日志平台Elasticsearch集群时的实战经验，对Elasticsearch运维相关知识进行总结分享，希望能够为提行提供参考和帮助，欢迎大家持续关注。

　　【作者】搁浅沉默 某金融行业技术研发专员

　　一、引言

　　笔者从业多年，亦解决过许多Elasticsearch相关方面的问题，由于早期国内大多数Elasticsearch的使用场景为日志模块，相对整体系统来讲，属于较为侧面的模块，因此早期关注度并不高，笔者也经历过早期Elasticsearch资料较少、排查问题困难的阶段，着实让人头大，现将自身对Elasticsearch的了解情况，结合之前规划搭建某行日志平台Elasticsearch集群时的实战经验，将Elasticsearch运维相关的知识进行简单的总结，此为基础篇，先介绍一下Elasticsearch的核心概念，以及这些基础点可能会产生的影响，以便对读者有一定帮助。

　　二、Elasticsearch核心概念

　　2.1 节点（Node）

　　在Elasticsearch中，节点是一个独立的服务器实例或进程，它是集群的一部分，用于存储数据并参与集群的索引和搜索功能。每个节点都可以运行在集群中的任何一台机器上，并通过与其他节点通信来协同工作，共同组成一个Elasticsearch集群。每个节点都有自己的名称、角色和职责，例如数据节点、主节点或协调节点。节点可以配置为按集群名称加入特定集群，默认情况下，每个节点都设置为加入一个名为“elasticsearch”的集群。

　　2.1.1 节点角色介绍

　　Master Node：主节点负责管理集群的整体状态和执行一些关键的集群级别的操作。主节点负责分配分片到数据节点、维护集群的状态信息、决定哪些节点是集群的一部分等。主节点本身不负责存储实际的数据，这有助于降低主节点的负载。

　　Data Node：数据节点负责存储实际的数据。它们管理索引的分片，并处理与数据相关的操作，如搜索、索引和删除。数据节点存储索引的一部分，并通过将数据分布在多个节点上来实现水平扩展。

　　Coordinating Node：协调节点是可选的节点类型，主要用于处理搜索请求的协调工作。它们不存储实际的数据，但是负责接收来自客户端的搜索请求，并将这些请求转发给数据节点。协调节点有助于分散搜索请求的负载，特别是在大规模集群中。

　　Ingest Node：预处理节点，Ingest节点负责数据的预处理，如数据的转换和附加处理。这允许在将数据索引到Elasticsearch之前对数据进行修改或过滤。Ingest节点通常用于日志处理和数据管道中。

　　Machine Learning Node：如果在集群中启用了Elasticsearch的机器学习功能，那么可能存在专门的机器学习节点，用于执行与机器学习相关的任务，如异常检测或趋势分析。

　　Remote-eligible Node：远程合格节点，拥有远程集群客户端角色，可以充当远程客户端，默认情况下，集群内任意节点都可以作为跨集群的客户端连接到远程集群。

　　Transform节点：用于执行数据转换操作，例如从一个索引中提取数据并将其转换为另一个索引，以便在数据仓库和分析方面进行使用。

　　2.2 索引（Index）

　　在Elasticsearch中，索引是一个逻辑存储，用来存储管理相关数据，可以类比为关系型数据库中的“表”的概念，数据以JSON格式存储在索引的基本单元-文档（Document）。

　　2.3 副本（Replica）

　　在Elasticsearch中，"副本"（Replica）是指索引的一个复制。每个索引可以被配置为具有零个或多个副本。副本可以提高集群的可用性和容错性，以及提高搜索性能。

　　每个索引被划分为一个或多个主分片。主分片负责存储索引的一部分数据，以及处理搜索和写入请求。为了提高可用性和容错性，每个主分片可以有零个或多个副本。

　　每个索引的副本数量是可以配置的。在创建索引时，可以指定副本的数量。副本数量的选择取决于对可用性和性能的需求。

　　2.4 分片（Shard）

　　在Elasticsearch中，一条索引的数据往往会被分为多个分片进行存储，每个分片是一个独立的存储单元，底层为一个Lucene索引，可以在集群中的不同节点上分布，以提供高可用性和负载均衡。

　　2.4.1 分片的目的

　　设想，一条索引的数据量很大，达到了TB级别或者几百GB，此时，就需要极大的存储空间来存储这一条索引，也不利于数据检索，分片的主要目的就是允许索引水平分割和分布存储。每个分片都是一个独立的、可被分配到不同节点上的工作单元，从而实现数据和负载的分布。

　　2.4.2 分片数的设置

　　创建索引时，可以指定主分片的数量。这个数量在索引创建后不能被更改。合理设置主分片的数量对于集群的性能和伸缩性至关重要。通常，每个主分片的大小应该适中，以便在集群中的各个节点上均匀分布负载，也有利于数据的快速查询。

　　2.4.3 主分片

　　每个索引都可以被分为一个或多个主分片。主分片存储索引的一部分数据，并负责处理搜索和查询操作，主分片的数量设置在索引创建时便被定义，无法进行动态修改，故而在进行主分片数量设置时，需按照实际应用场景谨慎评估。

　　2.5 映射（Mapping）

　　在Elasticsearch中，Mapping是用于定义索引中文档结构和字段属性的概念。可以理解为关系型数据库中的Schema，可以近似的理解为“表结构”，Mapping描述了文档中的每个字段的数据类型、分词器（如果适用）、是否索引等信息，索引中的每个文档都遵循其指定的Mapping规范。

　　此外，Mapping还有一个动态Mapping的概念，当索引中的文档被插入时，Elasticsearch可以根据文档的内容自动创建Mapping，这称为动态Mapping。动态Mapping允许Elasticsearch自动适应新字段和文档结构。

　　三、Elasticsearch注意事项

　　1. 副本的注意事项

　　由于写入请求首先发送到主分片，一旦主分片成功处理写入请求，数据会被复制到所有副本。因此，在写入请求的过程中，副本数量可以对性能产生一些影响。增加副本数量会导致写入请求需要复制更多的数据，会增加写入的总时间。在高写入的场景下，副本数量的增加会影响写入性能。

　　每个副本都占用独立的存储空间，因此增加副本数量会增加整体的存储需求。

　　在集群中的节点之间复制副本可能会产生额外的网络开销，特别是在分布式环境中，节点之间的网络带宽可能成为性能瓶颈。

　　当执行搜索请求时，查询可以分发到主分片和其副本上，允许并行处理。在高并发的搜索环境中，副本的存在可以提高搜索性能，但同时也需要更多的系统资源。

　　调整副本数量可能会触发集群的Rebalance分片的操作，这可能导致性能开销，需要谨慎地调整这些配置。

　　2. 分片设置的注意事项

　　分片的数量设置得过多时，过多的分片可能有如下影响：

　　CPU，内存资源消耗过多。

　　分片间的通信开销会随着分片数量的增加而增加，可能导致网络带宽成为瓶颈，进而影响整体性能。

　　当执行查询时，Elasticsearch需要在所有分片上运行查询，并将结果合并，分片数量过多时，会导致查询性能降低。

　　分片其实数语碎片化的存储，过多的碎片化存储会导致IO性能下降。

　　节点挂掉时，Elasticsearch 需要Rebalance分片以确保每个节点上的负载均衡，故而分片过多时，集群进行Rebalance时开销会很大。

　　分片的数量设置得过少时，可能会存在如下影响：

　　集群中同时处理查询和索引操作的并行性受到限制。

　　可能导致某些节点的资源未能充分利用，降低了整个集群的吞吐量和性能。

　　可能限制了集群的伸缩性，使得在应对不断增长的数据量和负载时难以实现水平扩展。

　　可能导致查询在单个分片上运行，限制了查询操作的并行性。这可能影响查询性能，尤其是在大规模数据集上执行复杂查询时。

　　如果设置了副本，过少的分片可能导致某些节点上的副本数量有限，从而增加了数据的单点故障风险。在某个节点挂掉时，副本数量不足可能影响集群的可用性。

　　根据笔者工作中实践的经验，单个数据节点上的分片数量在1000左右为佳，3000左右为极限，超过3000后，单个数据节点的CPU以及内存使用量会维持在70%-90%之间，甚至有达到100%的情况，极度容易触发内存CPU告警以及Elasticsearch集群数据节点的Out Of Memory异常。

　　3. 映射的注意事项

　　当使用动态 Mapping 时，Elasticsearch 需要解析新插入文档的结构，并自动创建或更新 Mapping。如果数据集中有大量不同的字段，动态Mapping的开销可能增大，可能影响索引速度和系统资源的利用效率。

　　对于文本字段，分词器的选择对索引和搜索性能有影响。复杂的分析器可能会导致索引速度减缓，但可以提供更灵活和准确的搜索，需要根据实际场景权衡索引速度和搜索质量之间的需求来选择适合的分词器。

　　索引中字段的数量和类型会直接影响性能，过多的字段可能导致索引和搜索的复杂性增加，而字段类型的选择也会影响存储和检索的效率，合理设计Mapping结构可以降低这些影响，这点在实际使用场景中非常重要，可以理解为关系型数据库中的“数据表结构的设计部分”。

　　当Mapping 发生变更时，Elasticsearch可能需要重新建立索引（Reindex）已有的数据，进而导致一定的性能开销，特别是在处理大量数据时。更改Mapping时需要谨慎，可能需要考虑升级策略，以减轻对集群的影响。

　　复杂的Mapping结构和冗余的字段可能会增加存储和检索的复杂性，影响性能，在设计Mapping时，需考虑到数据的冗余性和复杂性可能会带来的性能影响。

　　四、结语

　　本次针对Elasticsearch基本概念进行了相关介绍以及构建集群时，需注意的基本事项。《老子》有云：“合抱之木，生于毫末；九层之台，起于累土”，笔者经过多年的实践发现，往往最基础的东西，可以很有效的帮助笔者发现问题，解决问题，故而此篇文章从最基础的概念进行介绍，进而延伸到这些基础知识点可能影响到的场景，一家之言，仅供参考。