Java Elasticsearch提高查询性能

我正在努力提高查询性能。对于不涉及嵌套文档的简单查询，平均需要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/内存等方面有任何明显的峰值。有什么想法可以改进吗？

好的，这里有几点：

减小堆大小，每个平台上每个Elasticsearch实例的堆大小都超过32gb。Java不会压缩超过32gb的指针。将节点降低到32gb，如果需要，还可以启动另一个实例

如果不能旋转另一个实例，并且3个节点上的32gb不足以运行ES，那么您必须将堆内存提升到48gb以上

我可能会坚持碎片和副本的默认设置。5个碎片，1个复制品。但是，您可以调整碎片设置以适应。我要做的是在几种不同的条件下，在几种指数中对数据重新编制索引。第一个索引只有1个碎片，第二个索引有2个碎片，我会一直这样做，最多10个碎片。查询每个索引，看看哪个性能最好。如果10分片索引是性能最好的索引，请不断增加分片数，直到性能变差，那么您已经达到了分片限制

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

---

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

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

使用当前配置，对于1.5 TB的索引，可用的页面缓存将少于60GB。由于页面缓存中的索引不到4.2%，您很可能需要在大多数搜索中访问磁盘

您可能希望向集群添加更多内存，并且还需要仔细考虑碎片的数量。仅仅坚持默认值就可能导致分布不均匀。在这种情况下，如果您有五个碎片，那么您将有两台机器，每台机器拥有40%的数据，第三台机器只有20%的数据。无论哪种情况，在进行分布式搜索时，您都将始终等待速度最慢的计算机或磁盘。本文将更深入地讨论如何确定正确的内存量

---

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

谢谢。我已经将一些源代码更改为使用过滤器，但它们仍然不够快。奇怪的是，我们有一个拥有相似数量文档（减去嵌套文档）的集群，但字段和查询的数量要少得多，速度要快得多（ms）。这是硬件数量的一半，而且索引仍然太大，无法放入RAM中。我目前正在使用index:no-store:false对整个字段加载数据重新编制索引。知道这是否有帮助吗？字段的数量并不是真正的问题，而是回答大多数搜索所需的索引页是否在页面缓存中。虽然降低索引大小很好，但删除那些实际上没有被使用的数据并不会有很大的改善。删除字段不会有帮助。但是，如果您将所有字段设置为“stored=true”，那么它们将构成索引的一部分，索引驻留在RAM中。所有字段都作为文档的一部分存储在磁盘上，只需确保没有将不必要的字段设置为作为索引的一部分存储即可。默认情况下，Elasticsearch将整个原始文档存储为

\u source

，没有其他字段。添加更多字段显然会使为返回的命中而获取的磁盘上“结果对象”变大，但这些内容不会持久驻留在RAM中。