【Elasticsearch】索引性能优化

🧑 博主简介：CSDN博客专家 ，历代文学网 （PC端可以访问：https://literature.sinhy.com/#/?__c=1000，移动端可微信小程序搜索"历代文学 "）总架构师，15年工作经验，精通Java编程，高并发设计，Springboot和微服务，熟悉Linux，ESXI虚拟化以及云原生Docker和K8s，热衷于探索科技的边界，并将理论知识转化为实际应用。保持对新技术的好奇心，乐于分享所学，希望通过我的实践经历和见解，启发他人的创新思维。在这里，我希望能与志同道合的朋友交流探讨，共同进步，一起在技术的世界里不断学习成长。
技术合作 请加本人wx（注明来自csdn ）：foreast_sea

---

【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"
            }
        }
    }
}

二、合理设置索引的分片数与副本数

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);
    }
}

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();
            }
        }
    }
}

调整后，系统的查询性能得到了显著提升，数据的可用性也得到了增强。

三、优化索引的映射设计

3.1 避免过度复杂或冗余的映射结构

3.1.1 过度复杂映射结构的问题

过度复杂的映射结构会增加索引的创建和查询开销。例如，如果在映射中定义了过多的嵌套字段或复杂的数据类型，Elasticsearch 在处理这些字段时需要进行更多的计算和处理，导致性能下降。

例如，在一个用户信息索引中，如果将用户的地址信息定义为多层嵌套结构，如下所示：

{
    "mappings": {
        "properties": {
            "user": {
                "properties": {
                    "address": {
                        "properties": {
                            "street": {
                                "type": "text"
                            },
                            "city": {
                                "type": "text"
                            },
                            "state": {
                                "type": "text"
                            }
                        }
                    }
                }
            }
        }
    }
}

这样的结构在查询时会增加额外的开销，因为需要逐层解析嵌套字段。

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);
    }
}

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"
            }
        }
    }
}

四、掌握索引的刷新、合并与优化操作

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);
    }
}

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);
    }
}

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"

上述命令将 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();
        }
    }
}

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"

• 查询性能：监控查询的响应时间和吞吐量，了解索引优化对查询性能的影响。可以使用 Elasticsearch 的慢查询日志功能，记录查询时间超过一定阈值的查询语句，以便进行分析和优化。
• 磁盘 I/O 使用率：监控磁盘 I/O 使用率，了解索引优化操作对磁盘 I/O 的影响。如果磁盘 I/O 使用率过高，可能会影响查询性能，需要调整优化策略。

4.4.2 基于监控结果的调优

• 调整分片数与副本数：如果发现某些分片的查询性能较差，或者磁盘 I/O 使用率过高，可以考虑调整分片数与副本数，以平衡数据分布和查询负载。
• 优化映射设计：根据查询日志分析，发现某些字段的索引使用率较低或者存在冗余字段，可以对映射设计进行优化，减少不必要的字段索引与存储。
• 调整刷新、合并与优化操作的时机与策略：根据监控结果，调整刷新、合并与优化操作的时间间隔和参数设置，以达到最佳的索引性能。

4.5 总结

通过合理设置索引的分片数与副本数、优化索引的映射设计以及掌握索引的刷新、合并与优化操作的时机与策略，可以显著提高 Elasticsearch 索引的创建与查询效率。同时，持续的监控与调优是确保索引性能稳定的关键。在实际应用中，需要根据业务需求和数据特点，灵活调整优化策略，以满足不同场景下的性能要求。

以上内容进一步完善了关于 Elasticsearch 索引优化的相关知识，希望对你有所帮助。