如何合理规划Elasticsearch的索引｜得物技术

关注

原创 2025-04-15 10:30:00 2.3k 阅读 AI 写同款· GEO 优化 ›

一、背景

随着ES在业务场景中的使用逐渐增多，平台对ES集群的稳定性、管理、运维的压力逐渐增大，通过日常的运维情况来看，发现用户对ES的了解熟悉程度参差不齐，经常性的遇到索引创建不规范，或者参考别人索引的创建脚本进行创建索引，对索引没有一个比较清晰的认知，对索引结构的规划也寥寥无几，为此，平台使用了一些列手段来帮助用户提前合理规划模板，比如索引、模板的创建接入飞书审批流，平台侧会逐一结合业务场景和ES集群情况详细沟通确定索引或者模板结构；又比如ES内核增加业务不停服的动态扩分片能力，旨在进行不合理索引的治理提升ES集群稳定性（索引一旦创建分片是不能修改的），我们内部改动ES源码实现了不停服动态扩分片。

因此有必要从ES的索引讲起，让大家对ES的索引从概念、原理到使用有一个清晰的认知，希望日常业务场景中用到ES的同学能够抽时间读一下。当然文章避免不了存在主观的分析，大家可以在文章底部进行评论或者私聊我们，一起探讨。好了废话不多说了，现在开始介绍。

二、什么是index(索引)

下面会针对索引的组成和基本结构结合官方文档逐一介绍。

基本概念

index(索引)是索引是具有相似特征的文档（Document）集合，类似于关系型数据库中的表。每个索引都具有自己唯一的名称与_id。并且可以进行不同的参数配置与mapping映射。以适应不同的业务场景。索引中的最小单位是文档。每一条文档(doc)都是一个json格式的数据对象。包含了实际的具体数据以及该数据所对应的元数据。文档可以是结构化，半结构化或非结构化的数据。索引在elasticsearch中被用于存储，检索与分析数据。通过对索引进行搜索与聚合操作可以快速地找到相关的文档。

官方描述：The index is the fundamental unit of storage in Elasticsearch, a logical namespace for storing data that share similar characteristics. After you have Elasticsearch deployed, you’ll get started by creating an index to store your data. 翻译：索引是Elasticsearch中存储数据的基本单位，是一个逻辑命名空间，用于存储具有相似特性的数据。在部署Elasticsearch后，您将通过创建索引来存储数据。 An index is a collection of documents uniquely identified by a name or an alias. This unique name is important because it’s used to target the index in search queries and other operations. 翻译：索引是一种文档集合，通过名称或别名唯一标识。这个唯一名称非常重要，因为它用于在搜索查询和其他操作中定位索引。

三、索引结构详解

索引结构详解

创建索引结构
PUT /index_demo
{
  "aliases" : {
    "index_demo_alias" : { }
  },
  "mappings" : {
    "properties" : {
      "id" : {
        "type" : "long"
      },
      "name" : {
        "type" : "text",
        "fields" : {
          "keyword" : {
            "type" : "keyword",
            "ignore_above" : 256
          }
        }
      },
      "status" : {
        "type" : "keyword"
      },
      "createDate" : {
        "type" : "long"
      }
    }
  },
  "settings" : {
    "index" : {
      "refresh_interval" : "5s",
      "number_of_shards" : "3",
      "number_of_replicas" : "1"
    }
  }
}

ignore_above属性说明： - ignore_above的默认值通常为256个字符，这意味着任何超过256个字符的字符串将不会被索引或存储。 - 该参数仅适用于keyword类型的字段，因为这些字段主要用于过滤、排序和聚合操作，不需要进行全文搜索。 - ignore_above的值以字符为单位计算，包括英文字符和汉字。例如，一个汉字和一个英文字符都算作一个字符。 - 性能优化：通过限制字段长度，可以减少索引大小和查询时间，从而提高性能。 - 避免资源浪费：对于包含大量数据的字段，如日志文件中的长字符串，可以通过ignore_above避免不必要的存储和索引。官方描述：Strings longer than the ignore_above setting will not be indexed or stored. For arrays of strings, ignore_above will be applied for each array element separately and string elements longer than ignore_above will not be indexed or stored.

3.1 别名

别名将其生命置于群集状态内，由主节点（master node) 管理; 这意味着如果你有一个名为 xiaoming 的别名指向一个名为 potato 的索引，那么开销就是群集状态映射中的一个额外键，它将名称 xiaoming 映射到具体的索引字符串。这意味着与其他指数相比，别名的重量要轻得多; 可以维护数千个而不会对集群产生负面影响。

官方原话：An alias points to one or more indices or data streams. Most Elasticsearch APIs accept an alias in place of a data stream or index name. Aliases enable you to: - Query multiple indices/data streams together with a single name - Change which indices/data streams your application uses in real time - Reindex data without downtime 翻译：别名（Alias）可以指向一个或多个索引或数据流。大多数Elasticsearch API接受别名代替数据流或索引名称。别名的功能包括： - 使用单一名称查询多个索引/数据流； - 实时更改应用程序使用的索引/数据流； - 在不中断服务的情况下进行扩分片。

可以看到索引有上面三个作用，平台建议为每个索引添加别名（动态扩分片依赖别名）。添加别名可以在索引创建时和创建后再添加，即索引可以随时添加，但是平台还是建议你在创建索引时候指定别名，避免动态扩分片时候再去修改代码重新部署应用。

添加别名的几种方式

1. 创建索引时指定别名

PUT /test_index
{
    "settings" : {
        "number_of_shards" : 1,
        "number_of_replicas" : 1
    },
    "aliases":{"test_alias":{}},
    "mappings" : {
        "properties" : {
            "field1" : { 
                "type" : "text" 
            },
            "createdAt": {
                "type": "date",
                "format": "yyyy-MM-dd HH:mm:ss"
           }
        }
    }
}

2. 已存在的索引添加别名

POST /_aliases
{
  "actions": [
    {
      "add": {
        "index": "test_index", # 索引名
        "alias": "test_alias" # 别名
      }
    }
  ]
}

3. 别名更换

别名更换可以零停机进行动态扩分片。

POST /_aliases
{
  "actions": [
    {
      "add": {
        "index": "existing_index",
        "alias": "test_alias" # 别名
      },
      {
        "remove": {
          "index": "old_index",
          "alias": "old_test_alias" # 别名
        }
      }
    }
  ]
}

3.2 映射

建立索引时需要定义文档的数据结构，这种结构叫作映射。在映射中，文档的字段类型一旦设定后就不能更改。因为字段类型在定义后，elasticsearch已经针对定义的类型建立了特定的索引结构，这种结构不能更改。借助映射可以给文档新增字段。另外，elasticsearch还提供了自动映射功能，即在添加数据时，如果该字段没有定义类型，elasticsearch会根据用户提供的该字段的真实数据来猜测可能的类型，从而自动进行字段类型的定义。

3.3 字段类型

字段类型（Field Type）是定义数据格式和索引方式的重要概念，它决定了字段在索引中的存储、搜索和聚合行为。下面针对日常用到最多的三个字段类型进行解释，text、keyword、Numeric（Integer、Long）。

Text

text字段类型是Elasticsearch中用于全文搜索的核心字段类型。它通过分析器将文本拆分为单个词，并存储为倒排索引，适用于非结构化文本的搜索和分析。然而，由于其经过分析器处理，不适用于排序和聚合操作。

1. 特点

全文搜索：text字段类型主要用于存储和索引可读的文本内容，例如邮件正文、产品描述、新闻文章等。这些字段会被分析器（analyzer）处理，将字符串拆分为单个词（term），以便进行全文搜索。
分词处理：text字段支持分词器（tokenizer），可以根据语言和需求选择不同的分词策略（如标准分词器、正则表达式分词器等）。分词后的结果会存储为倒排索引，便于快速检索。
不适用于排序和聚合：由于text字段经过分析器处理，其原始字符串无法直接用于排序或聚合操作。如果需要排序或聚合，通常需要结合keyword字段类型。
支持多字段映射：可以通过多字段（multi-field）映射同时使用text和keyword类型，以满足全文搜索和精确匹配的需求。

2. 使用场景

全文搜索：适用于需要对文本内容进行模糊搜索的场景，例如搜索引擎、新闻网站、商品搜索等。
文本分析：可以结合分析器（如TF-IDF、BM25等）进行文本相似性搜索或评分计算。
日志分析：用于分析和搜索日志文件中的文本内容，提取关键信息。
内容管理：在内容管理系统中，用于存储和搜索文档、文章等内容。

3. 官方建议

Use a field as both text and keyword Sometimes it is useful to have both a full text (text) and a keyword (keyword) version of the same field: one for full text search and the other for aggregations and sorting. This can be achieved with multi-fields. 通过多字段映射同时使用text和keyword类型，可以实现全文搜索和精确匹配的双重需求。

4. 平台建议

明确业务使用场景，如果不需要进行模糊搜索的话，设置为keyword类型，来避免分词带来的存储开销，增加系统压力。

Keyword

keyword字段类型是一种用于存储和索引结构化数据的字段类型。

1. 特点

不进行分词：keyword字段类型不会对字段值进行分词处理，而是将其作为整体存储。这意味着字段值会被原样存储到倒排索引中，不会被拆分成单独的单词或短语。
精确匹配：由于字段值不进行分词，keyword字段类型非常适合用于精确匹配查询，例如查找特定的电子邮件地址、身份证号或状态码等。
tips：在term查询中可以结合case_insensitive属性，忽略大小写对值进行搜索，但不支持terms查询。
支持排序和聚合：keyword字段类型可以用于排序和聚合操作，例如按状态码统计数量或按用户ID进行分组。
存储效率高：由于不需要分词，keyword字段类型的存储开销较低，适合存储大量具有唯一性或固定值的字段。

2. 使用场景

精确查询：适用于需要精确匹配的场景，例如查找特定的电子邮件地址、身份证号、状态码等。
排序和聚合：当需要对数据进行排序或聚合时，keyword字段类型是理想选择。例如，按用户ID排序或按状态统计数量。
标签和分类：用于存储标签、分类等结构化数据，例如用户画像标签（学生、IT、教师等）。
唯一性字符串：适用于存储具有唯一性的字符串，如SpuId、货号、得物订单号等。

Numeric

数值类型，包含long、interger、short、byte、double、float等数字类型。

1. 特点

整数类型：适用于范围查询、排序和聚合操作。由于整数类型占用空间较小，推荐优先使用范围较小的类型（如 integer 或 long）以提高索引和搜索效率。
浮点类型：适用于需要高精度的计算场景。如果数据范围较大或精度要求不高，可以使用 scaled_float 类型并设置合适的 scale 值。
选择合适的类型：在满足需求的前提下，尽量选择范围较小的类型以节约存储空间和提升性能。

tips 如果确定业务使用场景，建议keyword代替数值类型字段，如果不确定则采用多字段，keyword在term查询中性能更佳。

3.4 针对字段类型选择的几条建议

针对Text和数值类型场景的字段，尽量改成keyword字段类型，来提升查询速度。
在不确定业务查询有哪些需求的情况下，设置多字段类型keyword。
枚举字段没有特殊业务场景下，统一使用keyword字段类型。
业务不需要范围查询的话，使用keyword字段类型（支持聚合和排序的）。
对keyword字段类型进行模糊查询会性能较差，使用多字段类型wildcard来模糊查询性能更高。
尽量不要使用聚合查询，text的fielddata会加大对内存的占用，如有需求使用，建议使用keyword。
需要中文分词的话，不要使用默认分词器，推荐使用ik_smart，ik_max_word会生成更多的分词，其中含有重复的内容，需谨慎使用。
时间字段不要使用keyword，除非点查，推荐使用date/long类型，支持范围查询，建议精确到分钟，会提高查询效率。
keyword字段类型不适用于模糊wildcard查询，建议使用wildcard字段类型。

10. 日期的查询条件为now时，并不能有效利用缓存，尽量换成绝对时间值。

11. ES默认字段个数最大1000，但建议不要超过100，对于不需要建立索引的字段，不写入ES。

12. 将不需要建立索引的字段index数据设置为false，对字段不分词，不索引可以减少很多运算操作。

13. 不建议或者禁止每次写入后立马进行显示的refresh，refresh会带来较高的磁盘IO，和CPU消耗，甚至有可能导致ES宕机.

14. 持续补充......

3.5 索引结构与关系性数据库对比

4.1 什么是Shard

基本概念

分片是管理文档的一个数据单元，分片是Elasticsearch中逻辑概念。ES内部把索引中文档进行按照一定路由规则（文档_id的hash值与分片数取余）进行路由到不同的存储数据单元，存储数据单元就是分片。你可以理解为MySQL的分表。

ElS的逻辑分片就是一个Lucene索引，一个ES索引是分哦的集合，当ES在索引中搜索的时候，他发送查询到每一个属于索引的分片（Lucene索引）进行检索，最后合并每个分片的结果得到一个全局的结果集。

分片划分

分片分为primary shard(主分片)和replicate shard(副本分片)。

主分片：索引的基本数据存储单元，每个索引被水平拆分为多个主分片，每个分片都是互相独立的。包含一部分索引的数据与索引的结构(segement)。每个分片都可以在集群中不同的节点上进行移动与复制。以提高数据的可用性与容错性。
副本分片：主分片的完整拷贝，用于冗余存储和容灾，副本分片和主分片在ES节点数足够的情况下不会同时存在一个ES节点。

注意：单分片的记录条数不要超过上限2,147,483,519。

主副分片分布示意图

分片的功能

1. 主分片

数据存储与写入：所有文档通过路由算法（如 hash(_id) % num_primary_shards（主分片数））分配到主分片，主分片负责处理索引、更新、删除等写操作。
扩展性：通过增加节点和分片分布，实现数据的水平扩展。
不可变性：主分片数量在索引创建时通过 number_of_shards 参数设定，创建后无法修改（需重建索引）。

2. 副本分片

高可用性：当主分片所在节点宕机时，副本分片自动升级为主分片（和对应的主分片不在一个节点），避免数据丢失和服务中断。
读取负载均衡：副本分片可并行处理查询请求，提升读吞吐量。
动态调整：副本分片数量通过 number_of_replicas 参数动态配置，支持按需扩展或缩减。

4.2 分片数规划

分片的基本概念和功能咱们咱们已经了解，在日常ES运维过程中发现不少同学对分片和数量的设置没有什么概念，照搬其他同学的比较多，这是严重错误的。咱们在实际的业务场景中也要做好分片（主副）数量的规划，来避免慢查、数据倾斜、磁盘容量浪费等问题。当索引分片数量过多时，可能会对ES性能产生不利影响。因为每个分片都需要一定量的内存来存储索引数据和缓存，从而导致内存消耗增加。另外当查询或写入数据涉及多个分片时，ES需要在节点之间进行传输和协调数据，从而增加网络开销，这也会导致查询和写入性能的降低。可见分片数量的选择需要慎重考虑。

索引在不同场景中，其分片分设置是不一样的，接下来咱们会在下面四个场景中来进行阐述。

读场景

索引单分片20g~40g，尽量减少分片数，可以降低热点，因为当分片数过多时，就容易出现长尾子请求，即有可能部分子请求因ES集群节点异常、Old GC、网络抖动等延迟响应，导致整个请求响应缓慢。另一方面，拆分过多的子请求无法提升数据节点请求吞吐，不能充分利用 CPU。在尽量减少主分片数的情况下，同时也可以适当增加副本数，从而提升查询吞吐。

写场景

索引单分片10g~20g，小分片更有利于数据写入。小分片维护的segment数量远低于大分片，在数据刷新落盘与段合并上更有优势。由于单分片数据量更少，在写入时数据可以更快地缓存至内存中并通过refresh参数更快的持久化至磁盘中。

日志存储场景

需要考虑每日写入集群的数据总量大小。通过过数据量与数据节点数评估索引分片数量。
在日志存储后是否需要兼顾查询与聚合性能。合理大小的分片数据量能够提高查询效率。
根据日志持久化策略，采用按月/周/天的策略生成索引。并使用ILM(索引生命周期管理策略)动态对日志索引进行完整生命周期的管理。
建议副本数设置为0来减少磁盘容量成本。

小数据量索引业务场景

对于数据量比较小的索引，增加索引分片数并不一定会带来性能提升，反而可能会带来一些负面影响。

首先，增加索引分片数会增加集群的管理开销，包括维护分片的状态、备份和恢复分片等。如果索引数据量比较小，这种开销可能会超过性能提升带来的收益。

其次，增加索引分片数可能会导致数据分布不均衡，从而影响查询性能。具体来说，如果某些分片中的数据量过小，可能会导致这些分片的查询性能比其他分片差。此外，如果查询涉及到多个分片，数据的合并操作也会增加查询时间。

因此，对于数据量比较小的索引，在查询场景下，通常建议将分片数设置为1或2，以避免不必要的开销和性能问题。如果需要提高查询性能，可以考虑配置索引副本，优化查询语句或使用缓存。

通用场景

根据实际业务场景提前规划预算索引数据量，做好分片数量规划（索引一旦创建无法修改分片数）。
分片数量：推荐公式：主分片数 ≈ 总数据量 / 单分片容量上限（官方建议单分片10-50GB，单个分片文档数在1亿条以内，日志场景可放宽至50-100GB）。

注意：分片数量平台强烈建议或者要求设置为ES data节点角色的整数倍。

副本数量：增加副本数可提升读性能，但会降低写入速度（需同步更多副本），因此在读场景可以酌情考虑。
如果索引是时序类，或者数据过大，单分片几百G，可以结合生命周期和索引模板进行索引滚动管理。
平台不建议使用自动移routing值进行分片，默认使用文档_id就好。

原因：使用自定义routing值进行路由分片的话很容易产生数据倾斜，另外ES内部会多一些计算逻辑来如何进行分片路由，在写入较高的场景下也会有一定的性能损耗。

控制分片数量，分片数不是越多越好，过多分分片，也会造成ES集群元数据管理的压力，降低系统的性能损耗。
设置total_shards_per_node，将索引压力分摊至多个节点。
index.routing.allocation.total_shards_per_node参数可以限制每个节点上的shard数量，从而将索引的压力分摊到多个节点，这样可以提高集群性能和可用性，避免某个节点过载导致整个集群出现问题。
index.routing.allocation.total_shards_per_node是一个索引级别设置（创建索引和对已有索引进行设置），语法如下：

PUT <index_name>/_settings
{
    "index.routing.allocation.total_shards_per_node":<number_of_shards>
}
<index_name>为索引名字，<number_of_shards>表示每个节点上该索引的分片数量。

持续调整索分片

对于集群分片的调整，通常不是一蹴而就的。随着业务的发展，不断新增的子业务或原有子业务规模发生突变，都需要持续调整分片数量。