Java中Elasticsearch 實現分頁方式(三種方式)

2022-07-05 14:02:44

ES 簡介

Elasticsearch 是一個基於 Lucene 實現的搜尋伺服器。它提供了一個分散式多使用者能力的全文搜尋引擎，基於 RESTful web 介面。Elasticsearch是用Java語言開發的，並作為Apache許可條款下的開放原始碼釋出，是一種流行的企業級搜尋引擎。Elasticsearch用於雲端計算中，能夠達到實時搜尋，穩定，可靠，快速，安裝使用方便。

ES 的特點：

分散式實時檔案儲存，可以將每一個欄位都編入索引，使其可以被檢索

可以作為一個大型分散式叢集（數百臺伺服器）技術，處理PB級資料

Elasticsearch不是什麼新技術，主要是將全文檢索、資料分析以及分散式技術，合併在了一起，才形成了獨一無二的ES。

下面介紹下Java中Elasticsearch 實現分頁的 3 種方式，還有誰不會？？

一、from + size 淺分頁

"淺"分頁可以理解為簡單意義上的分頁。

它的原理很簡單，就是查詢前20條資料，然後截斷前10條，只返回10-20的資料。這樣其實白白浪費了前10條的查詢。

GET test_dev/_search
{
  "query": {
    "bool": {
      "filter": [
        {
          "term": {
            "age": 28
          }
        }
      ]
    }
  },
  "size": 10,
  "from": 20,
  "sort": [
    {
      "timestamp": {
        "order": "desc"
      },
      "_id": {
        "order": "desc"
      }
    }
  ]
}

其中，from定義了目標資料的偏移值，size定義當前返回的數目。預設from為0，size為10，即所有的查詢預設僅僅返回前10條資料。

在這裡有必要了解一下from/size的原理：

因為es是基於分片的，假設有5個分片，from=100，size=10。則會根據排序規則從5個分片中各取回100條資料資料，然後彙總成500條資料後選擇最後面的10條資料。

做過測試，越往後的分頁，執行的效率越低。總體上會隨著from的增加，消耗時間也會增加。而且資料量越大，就越明顯！

二、scroll 深分頁

from+size查詢在10000-50000條資料（1000到5000頁）以內的時候還是可以的，但是如果資料過多的話，就會出現深分頁問題。

為了解決上面的問題，elasticsearch提出了一個scroll捲動的方式。

scroll 類似於sql中的cursor，使用scroll，每次只能獲取一頁的內容，然後會返回一個scroll_id。根據返回的這個scroll_id可以不斷地獲取下一頁的內容，所以scroll並不適用於有跳頁的情景。

GET test_dev/_search?scroll=5m
{
  "query": {
    "bool": {
      "filter": [
        {
          "term": {
            "age": 28
          }
        }
      ]
    }
  },
  "size": 10,
  "from": 0,
  "sort": [
    {
      "timestamp": {
        "order": "desc"
      },
      "_id": {
        "order": "desc"
      }
    }
  ]
}

scroll=5m表示設定scroll_id保留5分鐘可用。
使用scroll必須要將from設定為0。
size決定後面每次呼叫_search搜尋返回的數量

然後我們可以通過資料返回的_scroll_id讀取下一頁內容，每次請求將會讀取下10條資料，直到資料讀取完畢或者scroll_id保留時間截止：

GET _search/scroll
{
  "scroll_id": "DnF1ZXJ5VGhlbkZldGNoBQAAAAAAAJZ9Fnk1d......",
  "scroll": "5m"
}

注意：請求的介面不再使用索引名了，而是 _search/scroll，其中GET和POST方法都可以使用。

scroll刪除

根據官方檔案的說法，scroll的搜尋上下文會在scroll的保留時間截止後自動清除，但是我們知道scroll是非常消耗資源的，所以一個建議就是當不需要了scroll資料的時候，儘可能快的把scroll_id顯式刪除掉。

清除指定的scroll_id：

DELETE _search/scroll/DnF1ZXJ5VGhlbkZldGNo.....

清除所有的scroll：

DELETE _search/scroll/_all

三、search_after 深分頁

scroll 的方式，官方的建議不用於實時的請求（一般用於資料匯出），因為每一個 scroll_id 不僅會佔用大量的資源，而且會生成歷史快照，對於資料的變更不會反映到快照上。

search_after 分頁的方式是根據上一頁的最後一條資料來確定下一頁的位置，同時在分頁請求的過程中，如果有索引資料的增刪改查，這些變更也會實時的反映到遊標上。但是需要注意，因為每一頁的資料依賴於上一頁最後一條資料，所以無法跳頁請求。

為了找到每一頁最後一條資料，每個檔案必須有一個全域性唯一值，官方推薦使用 _uid 作為全域性唯一值，其實使用業務層的 id 也可以。

GET test_dev/_search
{
  "query": {
    "bool": {
      "filter": [
        {
          "term": {
            "age": 28
          }
        }
      ]
    }
  },
  "size": 20,
  "from": 0,
  "sort": [
    {
      "timestamp": {
        "order": "desc"
      },
      "_id": {
        "order": "desc"
      }
    }
  ]
}

使用search_after必須要設定from=0。
這裡我使用timestamp和_id作為唯一值排序。
我們在返回的最後一條資料裡拿到sort屬性的值傳入到search_after。

使用sort返回的值搜尋下一頁：

GET test_dev/_search
{
  "query": {
    "bool": {
      "filter": [
        {
          "term": {
            "age": 28
          }
        }
      ]
    }
  },
  "size": 10,
  "from": 0,
  "search_after": [
    1541495312521,
    "d0xH6GYBBtbwbQSP0j1A"
  ],
  "sort": [
    {
      "timestamp": {
        "order": "desc"
      },
      "_id": {
        "order": "desc"
      }
    }
  ]
}

到此這篇關於Elasticsearch 實現分頁的 3 種方式，還有誰不會？？的文章就介紹到這了,更多相關Elasticsearch 實現分頁內容請搜尋it145.com以前的文章或繼續瀏覽下面的相關文章希望大家以後多多支援it145.com！