原文地址: https://www.elastic.co/guide/cn/elasticsearch/guide/current/capacity-planning.html, 版权归 www.elastic.co 所有
英文版地址: https://www.elastic.co/guide/en/elasticsearch/guide/current/capacity-planning.html
英文版地址: https://www.elastic.co/guide/en/elasticsearch/guide/current/capacity-planning.html
请注意:
本书基于 Elasticsearch 2.x 版本,有些内容可能已经过时。
本书基于 Elasticsearch 2.x 版本,有些内容可能已经过时。
容量规划edit
如果一个分片太少而 1000 个又太多,那么我怎么知道我需要多少分片呢? 一般情况下这是一个无法回答的问题。因为实在有太多相关的因素了:你使用的硬件、文档的大小和复杂度、文档的索引分析方式、运行的查询类型、执行的聚合以及你的数据模型等等。
幸运的是,在特定场景下这是一个容易回答的问题,尤其是你自己的场景:
- 基于你准备用于生产环境的硬件创建一个拥有单个节点的集群。
- 创建一个和你准备用于生产环境相同配置和分析器的索引,但让它只有一个主分片无副本分片。
- 索引实际的文档(或者尽可能接近实际)。
- 运行实际的查询和聚合(或者尽可能接近实际)。
基本来说,你需要复制真实环境的使用方式并将它们全部压缩到单个分片上直到它"挂掉"。 实际上挂掉的定义也取决于你:一些用户需要所有响应在 50 毫秒内返回;另一些则乐于等上 5 秒钟。
一旦你定义好了单个分片的容量,很容易就可以推算出整个索引的分片数。 用你需要索引的数据总数加上一部分预期的增长,除以单个分片的容量,结果就是你需要的主分片个数。
容量规划不应当作为你的第一步。
先看看有没有办法优化使用 Elasticsearch 的方式。也许你的查询效率很低,缺少足够的内存,又或者开启了 swap?
我们见过一些新手对于初始性能感到沮丧,立即就着手优化垃圾回收又或者是线程数,而不是处理简单的问题,比如去掉通配符查询。