Elasticsearch中使用滚动索引的资源使用情况

Question

我的问题主要基于以下文章： https://qbox.io/blog/optimizing-elasticsearch-how-many-shards-per-index

本文建议不要在每个节点上使用多个分片，原因有两个：

• 每个分片本质上是一个Lucene索引，它消耗文件句柄，内存和CPU资源
• 每个搜索请求都会触及索引中每个分片的副本。当分片竞争相同的硬件资源时，会出现争用并且性能会下降

该文章主张对索引使用滚动索引，这些索引可以看到许多写入和更少的读取。

问题：

1. 如果旧指数保持开放，是否会出现Lucene指数的资源消耗问题？
2. 在涉及多个索引的大时间范围内进行搜索时会出现争用问题，因此会产生多个分片吗？
3. 如何搜索许多小指数与搜索一个大指数相比？

我应该提一下，在我们的特定情况下，只有一个ES节点，当然一般适用的答案对SO读者更有用。

Answer 1

在集群大小调整时，很难吐出一般的最佳实践和指南，因为它取决于很多因素。如果你问五位ES专家，你会得到十个不同的答案。

经过几年的修补和摆弄ES之后，我发现对我来说最有效的方法总是从小开始（一个节点，你的应用需要多少个索引，每个索引一个分片），加载代表性数据设置（理想情况下是您的完整数据集）并将测试加载到死亡。负载测试scenarii应代表您在高峰时段在生产环境中遇到（或期望）的实际最大负载。

增加群集的容量（添加分片，添加节点，调整旋钮等），直到负载测试通过，并确保将容量增加几个百分点，以便将来增长。你现在不希望自己的产品变得很好，你希望它在一年之后变好。当然，这将取决于您的数据增长速度，并且您不可能100％确定地预测一年后会发生什么。出于这个原因，一旦我的负载测试通过，如果我期望大的指数数据增长，我通常会将容量增加50％，因为我知道我将不得不在几个月或一年内重新访问我的集群拓扑。

所以回答你的问题：

1. 是的，如果旧索引保持打开状态，它们将消耗资源。
2. 是的，搜索的索引越多，浏览每个索引的每个分片所需的资源就越多。小心跨越许多滚动索引的别名（特别是在单个节点上）
3. 这太宽泛了，无法回答，因为它又取决于我们所讨论的数据量以及您发送的查询类型，是否使用聚合，排序和/或脚本等等。

Answer 2

  

如果旧指数保持开放，是否会出现Lucene指数的资源消耗问题？

是

  

搜索涉及多个索引的大时间范围并因此产生多个分片时，会出现争用问题吗？

是

  

如何搜索许多小指数与搜索一个大指数相比？

当ES搜索索引时，它将获取每个分片的一个副本（无论是副本还是主副本），并要求该副本在其自己的数据集上运行查询。搜索分片将使用该节点具有的search线程池中的一个线程（线程池是每个节点）。一个线程基本上意味着一个CPU核心。如果您的节点有8个核心，那么在任何给定时间该节点可以同时搜索8个分片。

想象一下，您在该节点上有100个分片，并且您的查询将要搜索所有分片。 ES将启动搜索，所有100个分片将竞争8个核心，因此一些分片将需要等待一段时间（微秒，毫秒等）才能获得这8个核心的份额。拥有多个分片意味着每个分片上的文档更少，因此每个分片的响应时间可能更快。但是，发起请求的节点需要收集所有分片的响应并聚合最终结果。因此，当最慢的分片最终以其结果集响应时，响应将准备就绪。

另一方面，如果你有一个只有很少分片的大索引，那么这些CPU内核的争用就不那么多了。 但分片需要花费大量时间单独完成，可能需要更多时间才能返回单个结果。

在选择分片数时，需要考虑许多方面。但是，对于一些粗略的指导是，每个碎片30GB是一个很好的限制。但这对每个人和每个用例都不起作用，文章也没有提到这一点。例如，如果您的索引使用父/子关系，那么每个分片30GB可能太多，并且单个分片的响应时间可能太慢。

你从上下文中取出了这个：“文章建议不要每个节点有多个分片”。不，这篇文章建议人们先考虑构建索引分片的各个方面。这里的一个重要步骤是测试。请在决定您需要多少分片之前测试您的数据。

您在帖子“滚动索引”中提到过，我假设基于时间的索引。在这种情况下，一个问题是关于保留期（您需要多长时间的数据）。根据这个问题的答案，您可以确定您将拥有多少指数。知道你将拥有多少个指数就可以得到你将拥有的碎片总数。

此外，对于滚动指数，您需要处理删除过期的索引。为此，请查看Curator。