我的问题主要基于以下文章： https://qbox.io/blog/optimizing-elasticsearch-how-many-shards-per-index
文章建议每个节点不要有多个分片，原因有两个：
文章提倡对写入多而读取少的索引使用滚动索引。
我应该提一下，在我们的特殊情况下，只有一个 ES 节点，但当然普遍适用的答案对 SO 读者更有用。
【问题讨论】：
标签： elasticsearch lucene
在集群规模调整方面，很难说出一般的最佳做法和指南，因为它取决于很多因素。如果你问五位 ES 专家，你会得到十个不同的答案。
经过几年对 ES 的修补和摆弄，我发现最适合我的方法总是从小处着手（一个节点，您的应用需要多少个索引，每个索引一个分片），加载有代表性的数据集（理想情况下是您的完整数据集）和负载测试到死。您的负载测试场景应该代表您在高峰时段在生产环境中遇到（或预期）的实际最大负载。
增加集群的容量（添加分片、添加节点、调整旋钮等）直到通过负载测试，并确保将容量增加几个百分点，以适应未来的增长。你不希望你的生产现在很好，你希望它在一年后很好。当然，这将取决于您的数据增长速度有多快，而且您不太可能 100% 确定地预测一年后会发生什么。出于这个原因，一旦我的负载测试通过，如果我预计数据会呈指数级增长，我通常会将容量增加 50% 以上，因为我知道我必须在几个月或一年内重新访问我的集群拓扑。
所以回答你的问题：
【讨论】：
如果旧索引保持打开状态，是否会出现 Lucene 索引的资源消耗问题？
是的。
在涉及多个索引和多个分片的大时间范围内进行搜索时是否会出现争用问题？
是的。
搜索多个小索引与搜索一个大索引相比如何？
当 ES 搜索索引时，它将获取每个分片（无论是副本还是主分片）的一个副本，并要求该副本对自己的数据集运行查询。搜索分片将使用节点拥有的search 线程池中的一个线程（线程池是每个节点）。一个线程基本上意味着一个 CPU 内核。如果您的节点有 8 个核心，那么在任何给定时间，该节点都可以同时搜索 8 个分片。
假设您在该节点上有 100 个分片，您的查询将要搜索所有这些分片。 ES 将启动搜索，所有 100 个分片将竞争 8 个核心，因此一些分片将不得不等待一段时间（微秒、毫秒等）才能获得它们在这 8 个核心中的份额。拥有许多分片意味着每个分片上的文档更少，因此每个分片的响应时间可能更快。但随后发起请求的节点需要收集所有分片的响应并聚合最终结果。因此，当最慢的分片最终响应其结果集时，响应将准备就绪。
另一方面，如果您有一个大索引且分片很少，那么这些 CPU 内核就不会出现太多争用。 但是分片有很多工作需要单独完成，返回单个结果可能需要更多时间。
在选择分片数量时，需要考虑许多方面。但是，对于一些粗略的指导，是的，每个分片 30GB 是一个很好的限制。但这并不适用于每个人和每个用例，并且文章没有提到这一点。例如，如果您的索引使用父/子关系，那么每个分片 30GB 可能太多，并且单个分片的响应时间可能太慢。
您断章取意：“文章建议不要每个节点有多个分片”。不，这篇文章建议人们事先考虑构建索引分片的各个方面。这里的一个重要步骤是测试。请在决定需要多少分片之前测试您的数据。
您在帖子中提到“滚动索引”，我假设是基于时间的索引。在这种情况下，一个问题是关于保留期（您需要数据多长时间）。根据这个问题的答案，您可以确定您将拥有多少个索引。知道您将拥有多少个索引，就可以知道您将拥有的分片总数。
此外，对于滚动索引，您需要注意删除过期的索引。看看Curator这个。
【讨论】：