Elasticsearch 提高查询性能答案

【问题标题】：Elasticsearch improve query performanceElasticsearch 提高查询性能
【发布时间】：2014-04-09 01:01:43
【问题描述】：

我正在尝试提高查询性能。甚至不涉及嵌套文档的简单查询平均需要大约 3 秒，有时甚至更长。

curl "http://searchbox:9200/global/user/_search?n=0&sort=influence:asc&q=user.name:Bill%20Smith"

即使没有排序也需要几秒钟。以下是集群的详细信息：

1.4TB index size.
210m documents that aren't nested (About 10kb each)
500m documents in total. (nested documents are small: 2-5 fields).
About 128 segments per node.
3 nodes, m2.4xlarge (-Xmx set to 40g, machine memory is 60g)
3 shards.
Index is on amazon EBS volumes.
Replication 0 (have tried replication 2 with only little improvement)

我在 CPU/内存等方面没有看到任何明显的峰值。有什么可以改进的想法吗？

【问题讨论】：

标签： java lucene elasticsearch

【解决方案1】：

Garry 关于堆空间的观点是正确的，但这里的问题可能不是堆空间。

在您当前的配置下，对于 1.5 TB 的索引，您将只有不到 60GB 的页面缓存可用。由于页面缓存中的索引不到 4.2%，因此您很可能需要在大部分搜索中使用磁盘。

您可能希望为集群添加更多内存，并且还需要仔细考虑分片的数量。仅仅坚持默认可能会导致分布不均。如果在这种情况下有五个分片，那么您将拥有两台机器，每台机器都有 40% 的数据，而第三台机器只有 20%。无论哪种情况，在进行分布式搜索时，您总是在等待最慢的机器或磁盘。 Elasticsearch in Production 上的这篇文章更深入地探讨了确定合适的内存量。

不过，对于这个确切的搜索示例，您可能可以使用过滤器。您正在排序，因此忽略了查询计算的分数。使用过滤器，第一次运行后会被缓存，后续搜索会很快。

【讨论】：

谢谢。我已经更改了我们的一些来源以使用过滤器，但它们仍然不够快。奇怪的是，我们有一个集群，其中包含相似数量的文档（减去嵌套文档），但字段少得多，查询速度更快 (ms)。
这使用了一半的硬件，并且索引仍然太大而无法放入 RAM。我目前正在使用 index: no store: false 在整个字段负载上重新索引数据。知道这是否有帮助吗？
字段数量并不是真正的问题，关键在于回答大多数搜索所需的必要索引页面是否在页面缓存中。虽然减小索引大小是件好事，但切掉实际上并未真正使用的数据并不会带来很大的改善。
删除字段无济于事，但是，如果您将所有字段设置为“stored=true”，那么它们将构成索引的一部分，该索引位于 RAM 中。所有字段都作为文档的一部分存储在磁盘上，只需确保没有将不必要的字段设置为索引的一部分。
默认情况下，Elasticsearch 将整个原始文档存储为_source，不存储其他字段。添加更多字段显然会使为返回的命中获取的磁盘“结果对象”更大，但这些东西不会永久驻留在 RAM 中。

【解决方案2】：

好的，这里有几件事：

减小堆大小，每个平台上的每个 Elasticsearch 实例都有超过 32GB 的堆大小。 Java 不会压缩超过 32gb 的指针。将您的节点降到只有 32GB，如果需要，可以启动另一个实例。
如果无法启动另一个实例实例并且 3 个节点上的 32gb 不足以运行 ES，那么您将不得不将堆内存增加到 48gb 以上！
我可能会坚持使用分片和副本的默认设置。 5 个分片，1 个副本。但是，您可以调整分片设置以适应。我要做的是在几个不同的条件下重新索引几个索引中的数据。第一个索引只有 1 个分片，第二个索引有 2 个分片，我会一直这样做到 10 个分片。查询每个索引，看看哪个表现最好。如果 10 个分片索引是性能最好的索引，则不断增加分片计数，直到性能变差，那么您已经达到了分片限制。

但需要考虑的一点是，分片可能会提高搜索性能，但它也会对索引时间产生巨大影响。分片越多，索引文档所需的时间就越长...

你还存储了相当多的数据，也许你也应该看看Custom Routing。

【讨论】：