【Elasticsearch】索引性能优化
引言
在当今数字化信息爆炸的时代，数据量呈现出指数级的增长态势。无论是电商平台的海量商品信息、社交媒体的用户动态，还是企业的业务数据，都需要高效的存储和快速的查询。Elasticsearch 作为一款开源的分布式搜索和分析引擎，凭借其强大的全文搜索、实时数据分析等功能，成为了众多开发者处理大规模数据的首选工具。
在使用 Elasticsearch 构建数据存储和查询系统时，索引的性能直接影响着整个系统的响应速度和处理能力。一个优化良好的索引可以显著提高查询效率，减少响应时间，为用户提供流畅的使用体验；而一个性能不佳的索引则可能导致查询缓慢、系统负载过高，甚至影响业务的正常运行。
在 Java 开发中，我们常常会使用 Elasticsearch 的 Java API 来与 Elasticsearch 集群进行交互。然而，仅仅将数据存储到 Elasticsearch 中是远远不够的，我们还需要对索引进行精心的优化，以充分发挥 Elasticsearch 的性能优势。索引优化涉及到多个方面，包括合理设置索引的分片数与副本数、优化索引的映射设计以及掌握索引的刷新、合并与优化操作的时机与策略等。
合理设置分片数与副本数是 Elasticsearch 索引优化的基础。分片是 Elasticsearch 中数据的基本存储单元，副本则是分片的复制，用于提高数据的可用性和容错性。不同的数据量、集群节点数量以及查询并发量对分片数与副本数的要求各不相同。如果设置不当，可能会导致数据分布不均衡，影响查询性能。
优化索引的映射设计同样至关重要。映射定义了索引中字段的类型、存储方式和索引方式等信息。一个过度复杂或冗余的映射结构会增加索引的创建和查询开销，而合理的映射设计可以减少不必要的字段索引与存储，提高索引的创建与查询效率。
此外，掌握索引的刷新、合并与优化操作的时机与策略，可以定期对索引进行维护与优化，减少索引碎片，进一步提高查询性能。
本文将深入探讨 Elasticsearch 索引优化的各个方面，帮助开发者全面掌握索引优化的技巧，提升 Elasticsearch 系统的性能。
一、Elasticsearch 索引基础概念
1.1 索引的定义
在 Elasticsearch 中，索引（Index）是一个逻辑命名空间，用于存储具有相似特征的文档。可以将索引类比为关系型数据库中的数据库，它是文档的集合。每个索引都有一个唯一的名称，通过这个名称可以对索引进行各种操作，如创建、删除、查询等。
例如，在一个电商系统中，我们可以创建一个名为 products 的索引，用于存储所有商品的信息。每个商品信息就是一个文档，这些文档都存储在 products 索引中。
1.2 分片与副本
1.2.1 分片（Shard）
分片是 Elasticsearch 中数据的基本存储单元。一个索引可以被分割成多个分片，每个分片是一个独立的 Lucene 索引。将索引分片的主要目的是为了实现数据的分布式存储和并行处理。
当数据量非常大时，单个节点可能无法存储所有的数据，通过将索引分片，可以将数据分散存储在多个节点上，提高系统的可扩展性。同时，在进行查询操作时，多个分片可以并行处理，提高查询性能。
例如，一个包含 1000 万条文档的索引，如果只使用一个分片，查询时所有的查询请求都需要在这个分片中进行处理，可能会导致性能瓶颈。而将这个索引分成 5 个分片，每个分片存储 200 万条文档，查询时可以并行在 5 个分片中进行处理，大大提高了查询效率。
1.2.2 副本（Replica）
副本是分片的复制，每个分片可以有零个或多个副本。副本的主要作用是提高数据的可用性和容错性。当某个节点出现故障时，其对应的副本可以接替工作，保证系统的正常运行。
同时，副本也可以用于提高查询性能。在进行查询操作时，查询请求可以同时发送到主分片和副本分片，并行处理，进一步提高查询效率。
例如，一个包含 5 个分片的索引，每个分片有 1 个副本，那么整个索引就有 5 个主分片和 5 个副本分片，总共 10 个分片。当进行查询时，查询请求可以同时在这 10 个分片中进行处理。
1.3 映射（Mapping）
映射定义了索引中字段的类型、存储方式和索引方式等信息。它类似于关系型数据库中的表结构定义。通过映射，我们可以指定字段是文本类型、数值类型、日期类型等，以及是否需要对字段进行索引和存储。
例如，在 products 索引中，我们可以定义一个 name 字段为文本类型，并设置为需要进行全文索引，这样就可以对商品名称进行全文搜索。同时，我们可以定义一个 price 字段为数值类型，用于进行数值范围查询。
{
"mappings": {
"properties": {
"name": {
"type": "text"
},
"price": {
"type": "double"
}
}
}
}
1
2
3
4
5
6
7
8
9
10
11
12
二、合理设置索引的分片数与副本数
2.1 影响分片数与副本数设置的因素
2.1.1 数据量的增长趋势
数据量是设置分片数的一个重要考虑因素。如果数据量较小，设置过多的分片会增加系统的开销，因为每个分片都需要一定的资源来维护。而如果数据量较大，设置过少的分片会导致单个分片存储的数据过多，影响查询性能。
例如，一个小型企业的日志数据，每天产生的数据量只有几百兆，设置 1 - 2 个分片就足够了。而一个大型电商平台的商品数据，每天新增的数据量可能达到数亿条，就需要设置较多的分片来存储这些数据。
在考虑数据量时，还需要考虑数据的增长趋势。如果数据量预计会快速增长，那么在设置分片数时需要预留一定的空间，避免后期频繁地进行分片调整。
2.1.2 集群节点数量
集群节点数量也会影响分片数的设置。一般来说，分片数应该根据集群节点数量进行合理分配，使得每个节点上的分片数量相对均衡。
例如，一个包含 3 个节点的集群，如果设置 9 个分片，那么每个节点上平均分配 3 个分片。这样可以充分利用每个节点的资源，提高系统的性能。
2.1.3 查询并发量
查询并发量是指在同一时间内系统需要处理的查询请求数量。如果查询并发量较高，适当增加分片数可以提高查询性能，因为多个分片可以并行处理查询请求。
例如，一个高并发的搜索系统，每秒需要处理数千个查询请求，设置较多的分片可以将查询请求分散到多个分片中进行处理，减少单个分片的负载。
2.2 动态调整分片数与副本数的 Java 代码示例
在 Java 中，我们可以使用 Elasticsearch 的 Java API 来动态调整索引的分片数与副本数。以下是一个示例代码：
import org.elasticsearch.action.admin.indices.settings.put.UpdateSettingsRequest;
import org.elasticsearch.client.RequestOptions;
import org.elasticsearch.client.RestHighLevelClient;
import org.elasticsearch.common.settings.Settings;
import java.io.IOException;
public class ShardAndReplicaAdjustment {
private RestHighLevelClient client;
public ShardAndReplicaAdjustment(RestHighLevelClient client) {
this.client = client;
}
public void adjustShardsAndReplicas(String indexName, int numberOfShards, int numberOfReplicas) throws IOException {
UpdateSettingsRequest request = new UpdateSettingsRequest(indexName);
Settings settings = Settings.builder()
.put("index.number_of_shards", numberOfShards)
.put("index.number_of_replicas", numberOfReplicas)
.build();
request.settings(settings);
client.indices().putSettings(request, RequestOptions.DEFAULT);
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
2.3 案例分析
假设我们有一个包含 10 个节点的 Elasticsearch 集群，最初创建了一个名为 logs 的索引，设置了 5 个分片和 1 个副本。随着业务的发展，数据量不断增加，查询并发量也越来越高，系统的性能开始下降。
通过分析发现，单个分片存储的数据量过大，查询时单个分片的负载过高。我们决定将分片数增加到 10 个，以分散数据存储和查询负载。同时，为了提高数据的可用性，将副本数增加到 2 个。
以下是调整分片数与副本数的 Java 代码调用示例：
import org.elasticsearch.client.RestHighLevelClient;
import org.elasticsearch.client.RestClient;
import org.apache.http.HttpHost;
import java.io.IOException;
public class Main {
public static void main(String[] args) {
RestHighLevelClient client = new RestHighLevelClient(
RestClient.builder(new HttpHost("localhost", 9200, "http")));
ShardAndReplicaAdjustment adjustment = new ShardAndReplicaAdjustment(client);
try {
adjustment.adjustShardsAndReplicas("logs", 10, 2);
} catch (IOException e) {
e.printStackTrace();
} finally {
try {
client.close();
} catch (IOException e) {
e.printStackTrace();
}
}
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
调整后，系统的查询性能得到了显著提升，数据的可用性也得到了增强。
三、优化索引的映射设计
3.1 避免过度复杂或冗余的映射结构
3.1.1 过度复杂映射结构的问题
过度复杂的映射结构会增加索引的创建和查询开销。例如，如果在映射中定义了过多的嵌套字段或复杂的数据类型，Elasticsearch 在处理这些字段时需要进行更多的计算和处理，导致性能下降。
例如，在一个用户信息索引中，如果将用户的地址信息定义为多层嵌套结构，如下所示：
{
"mappings": {
"properties": {
"user": {
"properties": {
"address": {
"properties": {
"street": {
"type": "text"
},
"city": {
"type": "text"
},
"state": {
"type": "text"
}
}
}
}
}
}
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
这样的结构在查询时会增加额外的开销，因为需要逐层解析嵌套字段。
3.1.2 冗余映射结构的问题
冗余的映射结构会浪费存储空间，并且可能导致数据不一致。例如，如果在多个字段中定义了相同的信息，当数据更新时，需要同时更新多个字段，增加了维护的难度。
3.2 减少不必要的字段索引与存储
3.2.1 字段索引的原理
在 Elasticsearch 中，字段索引是为了提高查询效率。当一个字段被索引后，Elasticsearch 会为该字段创建一个倒排索引，通过倒排索引可以快速定位包含该字段值的文档。
然而，并不是所有的字段都需要进行索引。例如，一些用于展示的字段，如商品的图片链接，通常不需要进行索引，因为我们不会根据图片链接来进行查询。
3.2.2 减少不必要的字段索引的 Java 代码示例
以下是一个在 Java 中创建索引并设置字段不进行索引的示例代码：
import org.elasticsearch.action.admin.indices.create.CreateIndexRequest;
import org.elasticsearch.action.admin.indices.create.CreateIndexResponse;
import org.elasticsearch.client.RequestOptions;
import org.elasticsearch.client.RestHighLevelClient;
import org.elasticsearch.common.xcontent.XContentType;
import java.io.IOException;
public class MappingOptimization {
private RestHighLevelClient client;
public MappingOptimization(RestHighLevelClient client) {
this.client = client;
}
public void createIndexWithOptimizedMapping(String indexName) throws IOException {
CreateIndexRequest request = new CreateIndexRequest(indexName);
String mapping = "{" +
" \"mappings\": {" +
" \"properties\": {" +
" \"name\": {" +
" \"type\": \"text\"" +
" }," +
" \"image_url\": {" +
" \"type\": \"keyword\"," +
" \"index\": false" +
" }" +
" }" +
" }" +
"}";
request.source(mapping, XContentType.JSON);
CreateIndexResponse response = client.indices().create(request, RequestOptions.DEFAULT);
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
3.3 提高索引的创建与查询效率
3.3.1 合理选择字段类型
不同的字段类型在索引和查询时的性能不同。例如，text 类型适用于全文搜索，而 keyword 类型适用于精确匹配。在设计映射时，需要根据实际的查询需求合理选择字段类型。
例如，在一个商品索引中，商品名称通常使用 text 类型，以便进行全文搜索；而商品的 SKU 编号通常使用 keyword 类型，以便进行精确匹配。
3.3.2 优化日期字段的映射
日期字段在 Elasticsearch 中是一种特殊的字段类型。合理设置日期字段的映射可以提高日期范围查询的性能。
例如，将日期字段的格式设置为 strict_date_optional_time，可以让 Elasticsearch 更高效地处理日期数据。
{
"mappings": {
"properties": {
"create_date": {
"type": "date",
"format": "strict_date_optional_time"
}
}
}
}
1
2
3
4
5
6
7
8
9
10
四、掌握索引的刷新、合并与优化操作
4.1 索引的刷新（Refresh）操作
4.1.1 刷新操作的原理
在 Elasticsearch 中，当文档被写入索引后，并不会立即对查询可见。文档首先会被写入到内存缓冲区中，只有当执行刷新操作后，文档才会从内存缓冲区写入到磁盘上的段（Segment）中，此时文档才对查询可见。
刷新操作的默认间隔时间是 1 秒，也就是说，新写入的文档最多需要等待 1 秒才能被查询到。
4.1.2 刷新操作的时机与策略
在一些对实时性要求较高的场景中，我们可以缩短刷新间隔时间，以减少文档的可见延迟。例如，在一个实时搜索系统中，我们可以将刷新间隔时间设置为 500 毫秒。
在 Java 中，我们可以通过以下代码来设置刷新间隔时间：
import org.elasticsearch.action.admin.indices.settings.put.UpdateSettingsRequest;
import org.elasticsearch.client.RequestOptions;
import org.elasticsearch.client.RestHighLevelClient;
import org.elasticsearch.common.settings.Settings;
import java.io.IOException;
public class RefreshOperation {
private RestHighLevelClient client;
public RefreshOperation(RestHighLevelClient client) {
this.client = client;
}
public void setRefreshInterval(String indexName, String interval) throws IOException {
UpdateSettingsRequest request = new UpdateSettingsRequest(indexName);
Settings settings = Settings.builder()
.put("index.refresh_interval", interval)
.build();
request.settings(settings);
client.indices().putSettings(request, RequestOptions.DEFAULT);
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
4.2 索引的合并（Merge）操作
4.2.1 合并操作的原理
随着文档的不断写入和删除，索引中的段数量会不断增加。过多的段会影响查询性能，因为查询时需要在多个段中进行搜索。合并操作的目的是将多个小的段合并成一个大的段，减少段的数量，提高查询性能。
4.2.2 合并操作的时机与策略
Elasticsearch 会自动触发合并操作，但我们也可以手动触发合并操作。在一些低峰期，我们可以手动触发合并操作，以减少对系统性能的影响。
在 Java 中，我们可以通过以下代码来手动触发合并操作：
import org.elasticsearch.action.admin.indices.forcemerge.ForceMergeRequest;
import org.elasticsearch.action.admin.indices.forcemerge.ForceMergeResponse;
import org.elasticsearch.client.RequestOptions;
import org.elasticsearch.client.RestHighLevelClient;
import java.io.IOException;
public class MergeOperation {
private RestHighLevelClient client;
public MergeOperation(RestHighLevelClient client) {
this.client = client;
}
public void forceMergeIndex(String indexName) throws IOException {
ForceMergeRequest request = new ForceMergeRequest(indexName);
ForceMergeResponse response = client.indices().forcemerge(request, RequestOptions.DEFAULT);
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
4.3 索引的优化（Optimize）操作
在 Elasticsearch 中，索引优化操作曾经是一个用于合并段并减少索引碎片的重要手段。不过在较新的版本中，optimize API 已被弃用，取而代之的是 forcemerge API，它能更精准地控制段合并过程，以达到优化索引的目的。
4.3.1 forcemerge 操作原理
forcemerge 操作的核心目标是将索引中的多个段合并成较少的段。在 Elasticsearch 里，数据写入时会先存储在内存缓冲区，当缓冲区满或者达到一定时间间隔后，数据会被刷新到磁盘形成一个新的段。随着时间推移和数据的不断写入，索引中会产生大量小的段，这会增加磁盘 I/O 开销和查询时的文件句柄数量，进而影响查询性能。forcemerge 操作通过合并这些小的段，减少段的数量，从而降低磁盘 I/O 开销，提高查询性能。
优化操作是一个比较耗时的操作，因此应该谨慎使用。一般来说，在索引数据不再发生变化或者需要进行大规模数据清理时，可以考虑进行优化操作。
4.3.2 forcemerge 操作的使用
可以使用 Elasticsearch 的 REST API 来执行 forcemerge 操作。以下是一个使用 curl 命令执行 forcemerge 操作的示例：
curl -X POST "localhost:9200/my_index/_forcemerge?max_num_segments=1"
1
上述命令将 my_index 索引中的段合并为最多 1 个段。max_num_segments 参数指定了合并后段的最大数量，值越小，段合并得越彻底，但合并操作所需的时间和资源也会越多。
在 Java 代码中执行 forcemerge 操作的示例如下：
import org.elasticsearch.action.admin.indices.forcemerge.ForceMergeRequest;
import org.elasticsearch.action.admin.indices.forcemerge.ForceMergeResponse;
import org.elasticsearch.client.RequestOptions;
import org.elasticsearch.client.RestHighLevelClient;
import org.elasticsearch.client.indices.GetIndexRequest;
import org.elasticsearch.client.indices.GetIndexResponse;
import java.io.IOException;
public class IndexForceMergeExample {
private RestHighLevelClient client;
public IndexForceMergeExample(RestHighLevelClient client) {
this.client = client;
}
public void forceMergeIndex(String indexName, int maxNumSegments) throws IOException {
ForceMergeRequest request = new ForceMergeRequest(indexName);
request.maxNumSegments(maxNumSegments);
ForceMergeResponse response = client.indices().forcemerge(request, RequestOptions.DEFAULT);
if (response.isShardsAcknowledged()) {
System.out.println("Force merge operation completed successfully for index: " + indexName);
} else {
System.out.println("Force merge operation failed for index: " + indexName);
}
}
public static void main(String[] args) {
// 假设已经创建了 RestHighLevelClient 实例
RestHighLevelClient client = null;
IndexForceMergeExample example = new IndexForceMergeExample(client);
try {
example.forceMergeIndex("my_index", 1);
} catch (IOException e) {
e.printStackTrace();
}
}
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
4.3.3 forcemerge 操作的注意事项
资源消耗：forcemerge 操作是一个资源密集型操作，会占用大量的磁盘 I/O 和 CPU 资源。因此，建议在业务低峰期执行该操作，以免影响正常的业务查询。
数据更新：在执行 forcemerge 操作期间，索引的写入操作会被阻塞。如果在操作过程中有新的数据需要写入，建议等待操作完成后再进行写入，否则可能会导致合并操作失败或者产生新的碎片。
段数量设置：max_num_segments 参数的值需要根据实际情况进行设置。如果设置得太小，合并操作会非常耗时；如果设置得太大，可能无法达到优化索引的目的。一般来说，对于只读索引，可以将其设置为 1，以达到最佳的查询性能。
4.4 监控与调优
为了确保索引优化策略的有效性，需要对 Elasticsearch 集群进行持续的监控，并根据监控结果进行调优。
4.4.1 监控指标
段数量：通过监控索引中的段数量，可以了解索引的碎片化程度。如果段数量过多，说明需要进行段合并操作。可以使用以下 REST API 查看索引的段信息：
curl -X GET "localhost:9200/my_index/_segments"
1
查询性能：监控查询的响应时间和吞吐量，了解索引优化对查询性能的影响。可以使用 Elasticsearch 的慢查询日志功能，记录查询时间超过一定阈值的查询语句，以便进行分析和优化。
磁盘 I/O 使用率：监控磁盘 I/O 使用率，了解索引优化操作对磁盘 I/O 的影响。如果磁盘 I/O 使用率过高，可能会影响查询性能，需要调整优化策略。
4.4.2 基于监控结果的调优
调整分片数与副本数：如果发现某些分片的查询性能较差，或者磁盘 I/O 使用率过高，可以考虑调整分片数与副本数，以平衡数据分布和查询负载。
优化映射设计：根据查询日志分析，发现某些字段的索引使用率较低或者存在冗余字段，可以对映射设计进行优化，减少不必要的字段索引与存储。
调整刷新、合并与优化操作的时机与策略：根据监控结果，调整刷新、合并与优化操作的时间间隔和参数设置，以达到最佳的索引性能。
4.5 总结
通过合理设置索引的分片数与副本数、优化索引的映射设计以及掌握索引的刷新、合并与优化操作的时机与策略，可以显著提高 Elasticsearch 索引的创建与查询效率。同时，持续的监控与调优是确保索引性能稳定的关键。在实际应用中，需要根据业务需求和数据特点，灵活调整优化策略，以满足不同场景下的性能要求。
以上内容进一步完善了关于 Elasticsearch 索引优化的相关知识，希望对你有所帮助。
最后关注灵活就业新动态，了解更多行业资讯、前沿技术请关注公众号：贤才宝（贤才宝https://www.51xcbw.com）
有没有软件行业离职或者失业状态的，公司招标需要可以给个人上基本社保，费用由公司承担，有需要的联系我，真实需求——拜托非诚勿扰，大家的时间都宝贵。
徐女士13331180327
浙公网安备 33010602011771号