ElasticSearch 檢索文檔慢

Question

我正在使用 Java_API 從 ElasticSearch 檢索記錄，在 Java 應用程序中檢索 100000 個文檔（記錄/行）大約需要 5 秒。

ElasticSearch 速度慢嗎？ 還是正常的？

這是索引設置：

我試圖獲得更好的性能但沒有結果，這是我所做的：

• 將 ElasticSearch 堆空間設置為 3GB，它是 1GB（默認） -Xms3g -Xmx3g

• 從 7200 RPM 硬盤遷移 SSD 上的 ElasticSearch

• 只檢索一個歸檔而不是 30

這是我的 Java 實現代碼

private void getDocuments() {
        int counter = 1;
        try {
            lgg.info("started");
            TransportClient client = new PreBuiltTransportClient(Settings.EMPTY)
                    .addTransportAddress(new TransportAddress(InetAddress.getByName("localhost"), 9300));

            SearchResponse scrollResp = client.prepareSearch("ebpp_payments_union").setSearchType(SearchType.DFS_QUERY_THEN_FETCH)
                    .setQuery(QueryBuilders.matchAllQuery())                 
                    .setScroll(new TimeValue(1000))
                    .setFetchSource(new String[] { "payment_id" }, null)
                    .setSize(10000)
                    .get();

            do {
                for (SearchHit hit : scrollResp.getHits().getHits()) {
                    if (counter % 100000 == 0) {
                        lgg.info(counter + "--" + hit.getSourceAsString());
                    }
                    counter++;
                }

                scrollResp = client.prepareSearchScroll(scrollResp.getScrollId())
                        .setScroll(new TimeValue(60000))
                        .execute()
                        .actionGet();
            } while (scrollResp.getHits().getHits().length != 0);

            client.close();
        } catch (UnknownHostException e) {
            e.printStackTrace();
        }
    }

我知道不推薦使用TransportClient ，我也嘗試過RestHighLevelClient ，但它沒有改變任何東西。

你知道如何獲得更好的性能嗎？

我應該更改 ElasticSearch 中的某些內容還是修改我的 Java 代碼？

Answer 1

如果不了解所涉及的所有內容，就很難進行性能故障排除/調整，但這似乎不是很快。 因為這是一個單節點集群，您將遇到一些性能問題。 如果這是一個生產集群，則每個分片至少有一個副本，也可用於讀取。

您還可以做一些其他事情：

• 根據您最常搜索的屬性索引您的文檔 - 這會將具有相同屬性的所有文檔寫入同一個分片，因此 ES 的讀取工作更少（這對您沒有幫助，因為您只有一個分片）
• 添加多個副本分片，以便您可以在集群中的節點之間分散讀取（再次，需要實際擁有一個集群）
• 不要在與數據相同的盒子上擔任主角色——如果你有一個中等或大型集群，你應該有既不是主也不是數據的盒子，而是你的應用程序連接到的盒子，以便他們可以管理元工作搜索並讓數據節點專注於數據。
• 使用“query_then_fetch” - 除非您使用加權搜索，否則您應該堅持使用 DFS。

Answer 2

我看到了三個可能的優化軸：

1/ 在 _doc 鍵上對文檔進行排序：

當排序順序為 _doc 時，滾動請求具有優化，可以使它們更快。 如果您想遍歷所有文檔而不考慮順序，這是最有效的選項：

（ 文檔來源）

2/ 減小頁面大小，10000 似乎是一個很高的值。 你能用 5000 /1000 等減少的值進行差異測試嗎？

3/ 去除源過濾

.setFetchSource(new String[] { "payment_id" }, null)

進行源過濾可能很繁重，因為彈性節點需要讀取源，在 Object 中進行轉換，然后進行過濾。 那么你可以嘗試刪除它嗎？ 網絡負載會增加，但這是一筆交易:)