Elasticsearch提高了查詢性能

Question

我正在嘗試提高查詢性能。 對於甚至沒有觸及嵌套文檔的簡單查詢，平均需要大約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 /內存等峰值。任何想法如何改進？

Answer 1

Garry關於堆空間的觀點是正確的，但這可能不是堆空間問題。

使用當前配置，對於1.5 TB索引，您可以使用少於60 GB的頁面緩存。 如果頁面緩存中的索引少於4.2％，那么在大多數搜索中，您很可能需要訪問磁盤。

您可能希望為群集添加更多內存，並且您還需要仔細考慮分片數量。 堅持默認會導致分布不均勻。 如果你在這種情況下有五個分片，你就有兩台機器，每台40％的數據，第三台機器只有20％。 在任何一種情況下，在進行分布式搜索時，您將始終等待最慢的機器或磁盤。 關於Elasticsearch in Production的這篇文章在確定適當的內存量方面有了更多的深入。

對於這個確切的搜索示例，您可以使用過濾器。 您正在排序，因此忽略查詢計算的分數。 使用過濾器，它將在第一次運行后進行緩存，后續搜索將很快。

Answer 2

好的，這里有幾件事：

1. 減小堆大小，每個平台上的每個Elasticsearch實例的堆大小超過32gb。 Java不會壓縮超過32GB的指針。 將節點丟棄到僅32gb，如果需要，可以啟動另一個實例。
2. 如果啟動另一個實例實例不是一個選項，並且3個節點上的32gb不足以運行ES那么你將不得不將你的堆內存提升到48gb以上！
3. 我可能會堅持使用分片和副本的默認設置。 5個碎片，1個復制品。 但是，您可以調整分片設置以適應。 我要做的是在幾個不同的條件下重新索引幾個指數中的數據。 第一個索引只有1個分片，第二個索引有2個分片，我一直這樣做最多10個分片。 查詢每個索引並查看哪個表現最佳。 如果10個分片索引是性能最佳的分片，則繼續增加分片計數，直到性能變差，然后達到分片限制。

但要考慮的一件事是，分片可能會提高搜索性能，但它也會對索引時間產生巨大影響。 分片越多，索引文檔所需的時間越長......

您也存儲了相當多的數據，也許您應該查看自定義路由 。