Elasticsearch 分片与副本配置：不同业务场景下的最佳实践

你好，我是你们的 Elasticsearch 技术顾问，老王。

今天咱们来聊聊 Elasticsearch (ES) 里一个至关重要，却又常常让人头疼的问题：分片和副本的配置。这玩意儿配置得好，你的集群跑得又快又稳；配置不好，轻则性能下降，重则数据丢失，那可就真让人“头秃”了。

很多刚接触 ES 的朋友，或者用了 ES 一段时间但没深入研究过的朋友，经常会问我：“老王，我这个场景应该怎么配分片和副本啊？”。这个问题，其实没有一个放之四海而皆准的答案。因为不同的业务场景，对 ES 的需求是不一样的，分片和副本的配置自然也就不一样。今天，我就结合几个常见的业务场景，来给大家详细讲讲，到底应该怎么配置分片和副本，才能让你的 ES 集群发挥出最大的效能。

1. 什么是分片和副本？

在深入讨论之前，咱们先来复习一下分片和副本的概念，确保咱们在同一个频道上。

1.1 分片 (Shard)

想象一下，你有一个巨大的图书馆，里面藏了数不清的书。如果把所有的书都堆在一个房间里，找起来肯定非常费劲。怎么办呢？聪明的图书管理员会把书分成不同的类别，放在不同的书架上，甚至不同的房间里。这样，你就可以根据书的类别，快速找到你想要的书。

ES 的分片，就相当于图书馆里的这些不同的书架或者房间。ES 会把你的索引数据分成多个分片，每个分片存储一部分数据。这样做的好处显而易见：

• 水平扩展： 当你的数据量不断增长时，你可以通过增加分片数量，把数据分散到更多的节点上，从而提高整个集群的存储和处理能力。
• 提高性能： 查询数据时，ES 可以并行地在多个分片上进行搜索，大大提高了查询速度。

1.2 副本 (Replica)

还是拿图书馆举例子。如果某个房间里的书架坏了，或者书被损坏了，怎么办呢？为了防止这种情况发生，图书管理员会把重要的书复制几份，放在不同的地方。这样，即使一份书出了问题，还有其他的备份可以用。

ES 的副本，就相当于这些书籍的备份。每个分片都可以有多个副本，这些副本存储着和主分片完全相同的数据。副本的主要作用是：

• 高可用性： 当某个节点发生故障，导致主分片不可用时，ES 会自动把副本分片提升为主分片，保证服务的持续可用。
• 提高读取性能： ES 可以从主分片或副本分片上读取数据，多个副本可以分担读取压力，提高查询性能。

2. 分片和副本配置的常见误区

在讲具体的配置策略之前，我先来纠正几个常见的误区：

2.1 分片越多越好？

错！分片数量并不是越多越好。每个分片都会占用一定的系统资源，比如文件句柄、内存、CPU 等。如果分片数量过多，会导致集群的元数据管理负担加重，反而会降低性能。过多的分片还会增加跨分片查询的开销。

2.2 副本越多越好？

同样错！副本虽然可以提高可用性和读取性能，但也会占用更多的存储空间。而且，写入数据时，ES 需要把数据同步到所有副本上，副本越多，写入性能就会越低。

2.3 分片和副本随便配？

更错！分片和副本的配置，需要根据你的业务场景、数据量、硬件资源等因素综合考虑。随便配置，很可能会导致集群性能低下，甚至数据丢失。

3. 不同业务场景下的分片和副本配置策略

接下来，我们就来看看几个常见业务场景下的分片和副本配置策略。

3.1 日志分析场景

日志分析是 ES 最常见的应用场景之一。比如，你可能需要收集和分析服务器的访问日志、应用程序的错误日志、安全审计日志等等。这类场景通常有以下特点：

• 数据量大： 日志数据通常会源源不断地产生，数据量会随着时间的推移不断增长。
• 写入频繁： 日志数据需要实时写入 ES。
• 查询模式多样： 你可能需要根据时间范围、关键字、错误码等多种条件来查询日志。
• 对数据丢失的容忍度较低： 日志数据通常用于故障排查、安全审计等重要用途，丢失数据可能会造成严重后果。

针对日志分析场景，我建议你采用以下配置策略：

• 基于时间创建索引： 按天、周或月创建索引，例如 logstash-2023.10.26、logstash-2023.10、logstash-2023。
• 分片数量： 每个索引的分片数量，可以根据你的数据量和硬件资源来确定。一般来说，建议每个分片的大小控制在 20GB-50GB 之间。你可以根据每天的数据量，估算出需要的总分片数量，然后除以节点数量，得到每个节点的分片数量。尽量保持每个节点上的分片数量大致相等。
• 副本数量： 为了保证高可用性，建议至少配置 1 个副本。如果你的数据非常重要，或者你的集群节点数量较少，可以考虑配置 2 个或更多副本。但要注意，副本越多，写入性能会越低。
• 使用 ILM (Index Lifecycle Management)： ES 的 ILM 功能可以帮助你自动化管理索引的生命周期，例如定期创建新索引、滚动旧索引、删除过期索引等。这对于日志分析场景非常有用。
• Hot-Warm-Cold 架构： 对于日志数据，你通常只需要查询最近一段时间的数据，而较早的数据访问频率较低。可以采用 Hot-Warm-Cold 架构，把热数据（最近的数据）存储在高性能的 SSD 硬盘上，温数据和冷数据存储在容量更大、成本更低的 HDD 硬盘上。这样可以兼顾性能和成本。

举个例子：

假设你每天产生 100GB 的日志数据，你有 3 个节点，每个节点配置了 1TB 的 SSD 硬盘。你可以这样配置：

• 按天创建索引，每个索引 5 个分片，1 个副本。
• 使用 ILM，每天滚动一次索引，保留最近 7 天的数据。
• 3 个节点都配置为 Hot 节点，存储最近 7 天的数据。

3.2 电商搜索场景

电商搜索是 ES 的另一个典型应用场景。用户可以通过关键词、分类、品牌等多种条件来搜索商品。这类场景通常有以下特点：

• 数据量相对较小： 相比于日志数据，商品数据的数量通常要少得多。
• 读取频繁： 用户会频繁地搜索商品，对查询性能要求很高。
• 写入相对较少： 商品信息通常不会频繁更新。
• 对数据一致性要求高： 商品信息必须准确无误，不能出现数据丢失或不一致的情况。

针对电商搜索场景，我建议你采用以下配置策略：

• 索引数量： 通常只需要创建一个索引，或者根据商品类别创建少量索引。
• 分片数量： 由于数据量相对较小，分片数量不需要太多。可以根据你的商品数量和节点数量来确定。一般来说，每个节点的分片数量不宜过多，建议控制在几十个以内。如果你的商品数量很少，甚至可以只使用一个分片。
• 副本数量： 为了保证高可用性和读取性能，建议至少配置 1 个副本。如果你的集群节点数量较少，或者你的搜索请求非常频繁，可以考虑配置 2 个或更多副本。
• 优化查询性能： 电商搜索对查询性能要求很高，你可以通过以下方式来优化：
  • 使用合适的分析器，对商品名称、描述等字段进行分词。
  • 使用过滤器缓存，缓存常用的过滤条件。
  • 使用路由 (Routing)，把相关的商品数据存储在同一个分片上，减少跨分片查询的开销。

举个例子：

假设你有 100 万个商品，你有 3 个节点，每个节点配置了 500GB 的 SSD 硬盘。你可以这样配置：

• 创建一个索引，10 个分片，2 个副本。
• 使用 IK 中文分词器，对商品名称和描述进行分词。
• 使用过滤器缓存，缓存常用的品牌、分类等过滤条件。

3.3 其他场景

除了日志分析和电商搜索，ES 还可以应用于很多其他场景，例如：

• 安全分析： 收集和分析安全事件日志，检测潜在的安全威胁。
• 指标监控： 收集和分析服务器、应用程序的性能指标，监控系统的运行状态。
• 地理位置搜索： 根据地理位置信息，搜索附近的商家、地点等。

这些场景的分片和副本配置策略，可以参考日志分析和电商搜索的思路，根据具体的需求进行调整。

4. 总结和建议

总的来说，ES 的分片和副本配置，没有一成不变的规则，需要根据你的业务场景、数据量、硬件资源等因素综合考虑。我建议你遵循以下原则：

• 理解你的需求： 在配置之前，先搞清楚你的业务场景是什么，对 ES 的性能、可用性、数据一致性等方面的要求是什么。
• 从小规模开始： 不要一开始就配置过多的分片和副本。可以先从小规模开始，然后根据实际情况逐步调整。
• 监控你的集群： 配置完成后，要密切监控你的集群的运行状态，包括 CPU 使用率、内存使用率、磁盘 I/O、查询延迟等指标。如果发现性能瓶颈，及时进行调整。
• 持续优化： ES 的配置不是一劳永逸的，需要根据你的业务发展和数据变化，持续进行优化。 记住：没有最好，只有最合适。

希望今天的分享对你有所帮助。如果你还有其他关于 ES 的问题，欢迎随时向我提问。咱们下期再见！