elasticsearch - 如果我希望 Elasticsearch 更快，是否只需向集群添加更多节点？

对于我的一些查询，Kibana 似乎会花费 30 多秒，随后会自动取消请求。有点可惜，因为我希望一个节点，一个双主/数据节点就足够了。似乎情况并非如此，为了提高查询速度，我应该添加额外的节点（我认为是数据）来帮助更快地处理事情。

话虽如此，这对于 Kibana 7.6 来说是自然而然的事情吗？它会在 30 秒后自动取消请求，还是可以禁用？我希望暂时只有一个节点，并且节点需要时间来处理是可以的，因为我暂时只查询以监控吞吐量。

看来，如果我确实想缩短查询时间，我当然应该考虑添加一个额外的数据节点（或 2 个）来提高查询能力，但不一定是索引，因为它仍然以每 2m 个条目平稳运行5分钟。

标签： elasticsearchkibanakibana-7

编辑

您可以通过调用任务管理 API来取消搜索。Kibana 确实从7.4取消查询，如记录：

现在，当请求新搜索时，或者当用户离开页面或从仪表板中删除面板时，对 Elasticsearch 的正在进行的搜索请求将被取消。

这主要是保护单个 kibana 客户端的多个请求，而不是超时取消。如果您一直等待并且不执行其他操作，您最终可以获得搜索/聚合结果。

原帖

它会在 30 秒后自动取消请求，还是可以禁用？

ES 中的查询将运行，没有超时。Kibana 只是不会收到需要很长时间才能返回的响应。要配置此超时，kibana.yaml具有以下（默认）设置：

# Time in milliseconds to wait for responses from the back end or elasticsearch.
# This must be > 0
request_timeout: 300000

除了 kibana，您可以为您的请求编写一个 java 客户端或用于curl调用 ES REST API。通常这可以实现更长的超时。

看来，如果我确实想缩短查询时间，我当然应该考虑添加一个额外的数据节点（或 2 个）来提高查询能力

多种因素影响 ES 查询性能，更明智的做法是关注真正的瓶颈。CPU使用率，内存使用率，磁盘吞吐量，网络带宽等。最好弄清楚瓶颈是什么。添加节点、使用 SSD 而不是 SATA 或添加内存也可能会有所帮助。