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 /内存等峰值。任何想法如何改进？
Garry关于堆空间的观点是正确的，但这可能不是堆空间问题。
使用当前配置，对于1.5 TB索引，您可以使用少于60 GB的页面缓存。 如果页面缓存中的索引少于4.2％，那么在大多数搜索中，您很可能需要访问磁盘。
您可能希望为群集添加更多内存，并且您还需要仔细考虑分片数量。 坚持默认会导致分布不均匀。 如果你在这种情况下有五个分片，你就有两台机器，每台40％的数据，第三台只有20％。 在任何一种情况下，在进行分布式搜索时，您将始终等待最慢的机器或磁盘。 关于Elasticsearch in Production的这篇文章更深入地确定了适当的内存量。
对于这个确切的搜索示例，您可以使用filter。 您正在排序，因此忽略了查询计算的分数。 使用filter，它将在第一次运行后进行缓存，后续搜索将很快。
好的，这里有几件事：
- 减小堆大小，每个平台上的每个Elasticsearch实例的堆大小超过32gb。 Java不会压缩超过32GB的指针。 将节点丢弃到仅32gb，如果需要，可以启动另一个实例。
- 如果启动另一个实例实例不是一个选项，并且3个节点上的32gb不足以运行ES那么你将不得不将你的堆内存提升到48gb以上！
- 我可能会坚持使用分片和副本的默认设置。 5个碎片，1个复制品。 但是，您可以调整分片设置以适应。 我要做的是在几个不同的条件下重新索引几个指数中的数据。 第一个索引只有1个分片，第二个索引有2个分片，我一直这样做最多10个分片。 查询每个索引并查看哪个表现最佳。 如果10个分片索引是性能最佳的分片，则继续增加分片计数，直到性能变差，然后达到分片限制。
但要考虑的一件事是，分片可能会提高搜索性能，但它也会对索引时间产生巨大影响。 分片越多，索引文档所需的时间越长……
您也存储了相当多的数据，也许您应该查看自定义路由 。