Easticsearch性能优化之索引优化

对于性能优化，Elasticsearch（以下简称ES）的索引优化是提高性能的关键因素之一。合理的设计索引，合理的分片和副本以及合理的缓存设置等，都有利于提升ES的索引性能和查询效率。

一、合理的索引设计

合理的索引设计是确保 ES 高效运行的关键因素之一。以下是一些设计ES索引时应考虑的最佳实践：

1. 理解数据和查询需求

数据特性：了解数据的类型（文本、数字、地理位置等）、大小和复杂性。
查询模式：明确你的查询需求，包括查询的频率、类型（全文搜索、精确匹配、范围查询等）以及期望的响应时间。

2. 索引结构优化

合理使用字段类型：根据数据的性质选择合适的字段类型，如text、keyword、date等。
控制索引映射：通过显式定义索引映射来控制字段的索引方式和格式化。
避免过度索引：不要索引那些永远不会被搜索的字段，可以在映射中将其设置为false。

3. 利用别名和索引模板

索引别名：使用索引别名可以更灵活地管理索引，如无缝切换索引或实现索引的滚动升级。
索引模板：利用索引模板可以自动应用预定义的设置和映射到新创建的索引，简化管理工作。

4. 考虑数据生命周期管理

使用ILM（Index Lifecycle Management）：Elasticsearch提供了索引生命周期管理功能，允许你基于索引的大小或年龄自动执行优化、滚动升级和删除操作。

二、合理的分片和副本

合理设置Elasticsearch中的分片和副本是确保高效性能和数据可靠性的关键。它是一个需要根据具体情况不断调整和优化的过程，没有一成不变的规则。理解自己的数据特性和业务需求，做出选择，这里提供一些指导原则和建议：

1. 分片 (Shards)
分片是Elasticsearch进行数据分布和并行处理的基本单位，一个索引可以被分成多个分片。合理设置分片数量对于优化存储、查询性能和扩展性至关重要。

分片大小：理想的分片大小通常在几GB到几十GB之间。太大的分片会增加恢复时间和降低某些操作的速度，而太小的分片则可能浪费资源并增加集群的管理开销，这会严重影响搜索性能。
默认分片数：Elasticsearch 7.x版本以后，默认创建的索引有1个主分片。主分片的设置需要结合集群节点规模、全部数据量和日增数据等维度综合考量才给出的值，一般建议设置为数据节点的1~3倍。
预估数据量：在确定分片数量时，考虑预期的数据增长。可以通过预估总数据量除以理想的分片大小来计算理想的分片数量。
扩展性：分片一旦被创建，其数量就不能更改（除非重新索引）。如果预计数据量会显著增长，应该规划额外的分片以便未来扩展。

2. 副本 (Replicas)
副本是分片的拷贝，用于提供数据冗余、提高查询吞吐量和提升系统的容错能力。

副本数量：至少设置一个副本是一个好习惯，这样即使失去一个节点也不会丢失数据。更多的副本可以提高读取性能，但会占用更多的硬盘空间和资源。Elasticsearch 7.x版本以后，默认创建的索引有1个副分片。对于一般的非高可用场景，一个副本基本足够。
读写比例：如果读请求远多于写请求，增加副本数量可以提高读取性能，因为查询可以在多个副本上并行执行。
资源和性能权衡：增加副本会提高查询性能，但同时也会增加索引和更新操作的开销，因为所有的写操作都必须在所有副本上执行。增加副本前，要考虑磁盘存储空间的容量上限和磁盘警戒水位线，其本质还是以空间换时间。
动态调整：副本数量可以根据需要动态调整，不会影响现有数据的完整性或可用性。

3. 实践建议

使用Index Templates：通过索引模板自动应用分片和副本的设置，以确保新索引遵循最佳实践。
监控和调整：利用Elasticsearch提供的监控工具，如Elasticsearch自身的监控API和Kibana，定期检查分片和副本的状态，并根据需要进行调整。
测试和评估：在生产环境部署前，通过测试来评估不同分片和副本配置下的性能表现，找到最适合自己数据和查询特性的设置。

三、合理的索引设置

1. 合理调整堆内存的索引缓冲区大小
堆内存中，索引缓冲区用于存储新索引的文档。填满后，缓冲区中的文档将最终写入磁盘上的某个段。索引缓冲的设置可以控制多少内存分配给索引进程。这是一个全局配置，会应用于一个节点上所有不同的分片上。 index_buffer_size的默认值为堆内存的10%，如下：

indices.memory.index_buffer_size: 10%

比如，给JVM提供31G的内存，它将为索引缓冲区提供3.1G的内存，一般情况下足以容纳大量的数据和写入操作。如果数据量着实非常大，则建议调大该默认值，比如调整为对内存的20%。但是必须在集群中的每个数据节点上进行配置。缓冲区越大，意味着能缓存的数据量越大，相同时间内，写入磁盘的频次低、磁盘IO小，间接提升写入性能。

indices.memory.min_index_buffer_size: 48mb

如果设置的是百分比，还可以设置 min_index_buffer_size （默认 48mb）和 max_index_buffer_size（默认没有上限）。

2. 合理的调整刷新频率
为了提高索引性能，Elasticsearch 在写入数据的时候，采用延迟写入的策略，即数据先写到内存中，当超过默认1秒（index.refresh_interval）会进行一次写入操作，就是将内存中 segment 数据刷新到磁盘中，此时我们才能将数据搜索出来，所以这就是为什么 Elasticsearch 提供的是近实时搜索功能，而不是实时搜索功能。

如果我们的系统对数据延迟要求不高的话，我们可以通过延长 refresh 时间间隔，可以有效地减少 segment 合并压力，提高索引速度。比如在做全链路跟踪的过程中，我们就将 index.refresh_interval 设置为30s，减少 refresh 次数。再如，在进行全量索引时，可以将 refresh 次数临时关闭，即 index.refresh_interval 设置为-1，数据导入成功后再打开到正常模式，比如30s。命令如下：

# 写入前
PUT test
{
	"settings":{
		"refresh_interval":-1
	}
}
#写入后
{
	"settings":{
		"refresh_interval":30
	}
}

3. 修改 translog 相关的设置
一是控制数据从内存到硬盘的操作频率，以减少硬盘 IO。可将 sync_interval 的时间设置大一些。默认为5s。

index.translog.sync_interval: 5s

也可以控制 tranlog 数据块的大小，达到 threshold 大小时，才会 flush 到 lucene 索引文件。默认为512m。

index.translog.flush_threshold_size: 512mb

4. 优先使用系统自动生成的ID方式
文档ID，即_id 字段的生成有两种方式：系统自动生成ID和外部控制自增ID。不过如果使用外部控制自增ID，ES会先尝试读取原来文档的版本号，以判断是否需要更新。也就是说，使用外部控制自增ID比系统自动生成ID要多进行一次读取磁盘操作。所以，非特殊场景推荐使用系统自动生成ID的方式。

5. 注意 _all 字段及 _source 字段的使用
_all 字段及 _source 字段的使用，应该注意场景和需要，_all 字段包含了所有的索引字段，方便做全文检索，如果无此需求，可以禁用；_source 存储了原始的 document 内容，如果没有获取原始文档数据的需求，可通过设置 includes、excludes 属性来定义放入 _source 的字段。

6. 合理的配置使用 index 属性
合理的配置使用 index 属性，analyzed 和 not_analyzed，根据业务需求来控制字段是否分词或不分词。只有 groupby 需求的字段，配置时就设置成 not_analyzed，以提高查询或聚类的效率。

7. 合理使用分析器
分词器决定分词粒度，对于中文分常用的IK分词，可细分为粗粒度分词ik_smart和细粒度分词ik_max_word。从存储角度来看，基于ik_max_word分词的索引会比基于ik_smart分词的索引占据空间。而更细粒度的自定义分词Ngram会占用大量资源，并且可能减慢索引速度并显著增加索引大小。所以，要结合**检索指标(召回率和精准率)**以及写入场景进行选型。

8. 合理设置映射
实战业务场景中不推荐使用默认映射，一定要手动设置映射。比如，默认字符串类型为text，8.x后默认为text和keyword的组合类型，就不见得使用所有业务场景，要结合自己的业务场景进行设置，正文文本内容一般不需要设置keyword类型(因为不需要排序和聚合操作)。再比如，在互联网公司采集数据并存储的场景中，正文文本内容需要进行全文检索，但HTML样式的文本一般会留给前端展示用，不需要索引，因此，映射设置要果断将index设置为false。

9. 批量提交
当有大量数据提交的时候，建议采用批量提交（Bulk 操作）；此外使用 bulk 请求时，每个请求不超过几十M，因为太大会导致内存使用过大。
比如在做 ELK 过程中，Logstash indexer 提交数据到 Elasticsearch 中，batch size 就可以作为一个优化功能点。但是优化 size 大小需要根据文档大小和服务器性能而定。
像 Logstash 中提交文档大小超过 20MB，Logstash 会将一个批量请求切分为多个批量请求。
如果在提交过程中，遇到 EsRejectedExecutionException 异常的话，则说明集群的索引性能已经达到极限了。这种情况，要么提高服务器集群的资源，要么根据业务规则，减少数据收集速度，比如只收集 Warn、Error 级别以上的日志。