笔者从业多年,亦解决过许多 Elasticsearch 相关方面的问题,由于早期国内大多数 Elasticsearch 的使用场景为日志模块,相对整体系统来讲,属于较为侧面的模块,因此早期关注度并不高,笔者也经历过早期 Elasticsearch 资料较少,排查问题困难的阶段,着实让人头大,现将自身对 Elasticsearch 的了解情况,结合之前规划搭建某行日志平台 Elasticsearch 集群时的实战经验,将 Elasticsearch 运维相关的知识进行简单的总结,此为基础篇,先介绍一下 Elasticsearch 的核心概念,以及这些基础点可能会产生的影响,以便对读者有一定帮助。
在 Elasticsearch 中,节点是一个独立的服务器实例或进程,它是集群的一部分,用于存储数据并参与集群的索引和搜索功能。每个节点都可以运行在集群中的任何一台机器上,并通过与其他节点通信来协同工作,共同组成一个 Elasticsearch 集群。每个节点都有自己的名称、角色和职责,例如数据节点、主节点或协调节点。节点可以配置为按集群名称加入特定集群,默认情况下,每个节点都设置为加入一个名为 “elasticsearch” 的集群。
Transform 节点:用于执行数据转换操作,例如从一个索引中提取数据并将其转换为另一个索引,以便在数据仓库和分析方面进行使用。
在 Elasticsearch 中,索引是一个逻辑存储,用来存储管理相关数据,可以类比为关系型数据库中的“表”的概念,数据以 JSON 格式存储在索引的基本单元 - 文档( Document )。
在 Elasticsearch 中, " 副本 " ( Replica )是指索引的一个复制。每个索引可以被配置为具有零个或多个副本。副本可以提高集群的可用性和容错性,以及提高搜索性能。
每个索引被划分为一个或多个主分片。主分片负责存储索引的一部分数据,以及处理搜索和写入请求。为了提高可用性和容错性,每个主分片可以有零个或多个副本。
每个索引的副本数量是可以配置的。在创建索引时,可以指定副本的数量。副本数量的选择取决于对可用性和性能的需求。
在 Elasticsearch 中,一条索引的数据往往会被分为多个分片进行存储,每个分片是一个独立的存储单元,底层为一个 Lucene 索引,可以在集群中的不同节点上分布,以提供高可用性和负载均衡。
设想,一条索引的数据量很大,达到了 TB 级别或者几百 GB ,此时,就需要极大的存储空间来存储这一条索引,也不利于数据检索,分片的主要目的就是允许索引水平分割和分布存储。每个分片都是一个独立的、可被分配到不同节点上的工作单元,从而实现数据和负载的分布。
创建索引时,可以指定主分片的数量。这个数量在索引创建后不能被更改。合理设置主分片的数量对于集群的性能和伸缩性至关重要。通常,每个主分片的大小应该适中,以便在集群中的各个节点上均匀分布负载,也有利于数据的快速查询。
每个索引都可以被分为一个或多个主分片。主分片存储索引的一部分数据,并负责处理搜索和查询操作,主分片的数量设置在索引创建时便被定义,无法进行动态修改,故而在进行主分片数量设置时,需按照实际应用场景谨慎评估。
在 Elasticsearch 中, Mapping 是用于定义索引中文档结构和字段属性的概念。可以理解为关系型数据库中的 Schema ,可以近似的理解为“表结构”, Mapping 描述了文档中的每个字段的数据类型、分词器(如果适用)、是否索引等信息。索引中的每个文档都遵循其指定的 Mapping 规范,如下示例:
1. PUT /example_index
2. {
3. "mappings": {
4. "properties": {
5. "title": {
6. "type": "text",
7. "analyzer": "standard"
8. },
9. "author": {
10. "type": "keyword"
11. },
12. "publish_date": {
13. "type": "date"
14. },
15. "views": {
16. "type": "integer"
17. },
18. "tags": {
19. "type": "keyword"
20. }
21. }
22. }
23. }
在这个示例中,我们创建了一个名为 "example_index" 的索引,并在其中定义了不同类型的字段:
tags 是一个关键字字段,用于存储标签信息。
此外, Mapping 还有一个动态 Mapping 的概念,当索引中的文档被插入时, Elasticsearch 可以根据文档的内容自动创建 Mapping ,这称为动态 Mapping 。动态 Mapping 允许 Elasticsearch 自动适应新字段和文档结构。
调整副本数量可能会触发集群的 Rebalance 分片的操作,这可能导致性能开销,需要谨慎地调整这些配置。
分片的数量设置得过多时,过多的分片可能有如下影响:
如果设置了副本,过少的分片可能导致某些节点上的副本数量有限,从而增加了数据的单点故障风险。在某个节点挂掉时,副本数量不足可能影响集群的可用性。
根据笔者工作中实践的经验,单个数据节点上的分片数量在 1000 左右为最佳, 3000 左右为极限,超过 3000 后,单个数据节点的 CPU 以及内存使用量会维持在 70%-90% 之间,甚至有达到 100% 的情况,极度容易触发内存 CPU 告警以及 Elasticsearch 集群数据节点的 Out Of Memory 异常。
复杂的 Mapping 结构和冗余的字段可能会增加存储和检索的复杂性,影响性能,在设计 Mapping 时,需考虑到数据的冗余性和复杂性可能会带来的性能影响。
本次针对 Elasticsearch 基本概念进行了相关介绍以及构建集群时,需注意的基本事项。《老子》有云:“合抱之木,生于毫末;九层之台,起于累土”,笔者经过多年的实践发现,往往最基础的东西,可以很有效的帮助笔者发现问题,解决问题,故而此篇文章从最基础的概念进行介绍,进而延伸到这些基础知识点可能影响到的场景,一家之言,仅供参考。
如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!
赞2
添加新评论6 条评论
2024-02-29 09:56
2024-02-28 15:40
2024-02-27 15:46
2024-02-26 12:14
2024-02-22 15:45
2024-02-22 15:29