ES 的跨索引查詢詳細講解

序言

Elasticsearch，中文名直譯彈性搜尋，不僅僅在單索引內部分片層面彈性搜尋，更強的是在跨索引外圍支援分片彈性搜尋，同比其它分散式資料產品，此特性更鮮明，代表了 Elastic 叢集架構設計的優越性。

本文將從以下幾個方面展開探討：

為什麼需要跨索引查詢？

跨索查詢有哪些經典應用場景？

跨索引查詢技術原理是怎樣的？

跨索引查詢有哪些注意事項？

圖示：跨索引示意圖 + 多個索引查詢效果圖

為什麼需要跨索引查詢

技術限制

Elasticsearch 索引本身有一些指標限制，對於很多新手來說最容易忽視或者亂用。

Elastic 索引資料量有大小限制；

單個分片資料容量官方建議不超過 50GB，合理範圍是 20GB～40GB 之間；

單個分片資料條數不超過約 21 億條（2 的 32 次方），此值一般很難達到，基本可以忽略，背後原理可以參考原始碼或者其它；

索引分片過多，分散式資源消耗越大，查詢響應越慢。

基於以上限制，索引在建立之前就需要依據業務場景估算，設定合理的分片數，不能過多也不能過少。

技術便利

在基於關係型資料庫的應用場景中，資料量過大，一般會採用分庫分表策略，查詢資料時基於第三方中介軟體，限制多多；在基於 NoSQL 的應用場景中，如 MongoDB，資料量過大，會採用資料產品本身提供的分片特性，查詢資料時基於自身的路由機制。

無論是分庫分表還是分片，它們只解決了一維資料的儲存與查詢，二維的不能，如電商訂單系統場景，資料庫採用多庫多表拆分，一旦容量超過預期設計，需要二次拆分繼續分庫分表；MongoDB 採用多分片拆分，一旦容量超過預計設計，需要繼續擴充套件分片節點。

以上對於 Elasticsearch 可以不用這樣，它提供了兩個維度的拆分方式，第一維度採用多個索引命名拆分，第二維度採用索引多分片，對於查詢來說，可以靈活匹配索引，一次指定一個索引，也可以一次指定多個索引。

圖示：ES 查詢示意圖 + 多索引 + 多分片示意圖

跨索引查詢應用場景

IT 應用中，除去技術本身侷限問題，多數的問題都是由於耦合造成的，“高內聚，低耦合”一直是我們 IT 從業者的座右銘。應用系統耦合，就成了單體應用，然後就延伸出微服務架構理念。同樣資料耦合，我們也要基於一定維度的微服務化，或垂直或水平或混合垂直水平。

業務系統

舉例某些業務場景，實時資料與歷史資料儲存和查詢問題，假設日均資料量超過千萬條，那麼月度數量超過 3 億條，年度也會超過 36 億條。

若採用 Elasticsearch 儲存，則可以按月 / 按季度 / 按年度 建立索引，這樣實時資料的更新只會影響當前的索引，不影響歷史的索引；查詢時也一樣，依據查詢條件指定索引名稱，按需要掃描查詢，無需每次掃描所有的資料。這比基於傳統的資料產品靈活很多。

圖示：實時資料與歷史資料業務場景

大資料

Elasticsearch 在大資料應用場景下很受歡迎，已經成為大資料平臺對外提供結果查詢的標配。大資料平臺需要定期計算資料，將結果資料批次寫入到 Elasticsearch 中，供業務系統查詢，由於部分業務規則設定，Elasticsearch 原來的索引資料要全部刪除，並重新寫入，這種操作很頻繁。對於大資料平臺每次全量計算，代價很大，對於 Elasticsearch 平臺，超大索引資料頻繁刪除重建，代價也很大。

基於以上，採用多索引方式，如按照月份拆解，依據需要刪除的月份索引資料。同樣的問題，業務系統查詢時，非常靈活指定需要的月份索引資料，這樣保證了儲存與查詢的平衡。

圖示：大資料平臺寫資料到 Elastic 平臺示意圖

日誌

Elasticsearch 應對這個日誌場景非常擅長，誕生了著名的 ELK 組合，比如一個大中型的業務系統，每天日誌量幾十 TB/ 幾百 TB 很正常，可按天或者按小時或者更小粒度建立索引，通常查詢日誌只會查詢最近時間的，過去很久的日誌，偶然需要查詢幾次，甚至會刪除。所以對於此場景，Elasticsearch 的跨索引查詢非常便利，程式編寫也很簡單。

跨索引查詢應用方式

Elasticsearch 跨索引查詢的方式可依據業務場景靈活選擇，下面介紹幾種：

直接型

明確指定多個索引名稱，這種方式一般應用在非常精確的查詢場景下，便於查詢索引範圍，效能平衡考慮，若索引不存在會出現錯誤，如下：index_01，index_02

GET /index_01，index_02/_search

{

“query” ： {

“match”： {

“test”： “data”

}

}

}

模糊型

不限定死索引名稱，這種方式一般採用萬用字元，無需判斷該索引是否存在，支援前匹配、後匹配，前後匹配，如下：index_* 匹配字首一樣的所有索引

GET /index_*/_search

{

“query” ： {

“match”： {

“test”： “data”

}

}

}

計算型

索引名稱透過計算表示式指定，類似正則表示式，也可以同時指定多個索引，如下：logstash-{now/d}表示當前日期

# 索引名稱如：index-2024。03。22

# GET //_search

GET /%3Cindex-%7Bnow%2Fd%7D%3E/_search{

“query” ： {

“match”： {

“test”： “data”

}

}

}

跨索引查詢技術原理

Elasticsearch 能夠做到跨索引查詢，離不開其架構設計以及相關實現原理。

索引分片

圖示：索引由分片組成

索引是一個虛擬的資料集合，索引由多個分片組成；

分片儲存實際的資料；

索引分片數量不限制。

查詢過程

圖示：索引查詢階段

圖示：取回資料階段

查詢過程簡單說來就是分發與合併：

查詢分發，客戶端傳送請求到協調節點，協調節點分發查詢請求到索引分片節點；

資料合併，索引分片節點將資料傳送到協調節點，協調節點合併返回客戶端。

所以說，Elasticsearch 提供跨索引查詢的能力，實際上與原來單索引查詢時一樣，本質上是跨多個分片查詢，然後合併。

跨索引查詢注意事項

索引與分片等價關係

索引與分片等價的關係，1 個索引 20 分片與 4 個索引每個索引 5 個分片理論上是等價的，鑑於索引分片的容量限制與效能平衡，在面對需要跨索引業務場景時，索引的數量與分片的數量儘量的少，既要保障索引熱點資料的實時處理能力，也要平衡歷史資料的查詢效能。

協調節點分離

鑑於 Elastic 查詢過程，在跨多個索引查詢時，協調節點承擔了所有分片查詢返回的資料合併，需要消耗很大資源，在應對高併發場景，建議部署獨立的協調節點，將叢集的資料節點與協調節點分離，以達到最佳的效能平衡。

路由機制

Elasticsearch 寫入資料分佈預設是基於索引主鍵 _id 的 Hash 值，此機制在資料分佈上很均衡，但也沒有什麼規律，對於跨索引查詢場景，若自定義指定路由鍵，可以在搜尋時避開不需要的索引分片，有效減少分片查詢的分片數量，達到更高的效能。

總結

Elasticsearch 由於其架構設計的彈效能力，小小的一個跨索引查詢特性，就能給我們應用系統帶來很多架構設計的便利，解決很多實際場景問題，這是其它資料產品目前還做不到的。Elasticsearch 還有更厲害的跨多個叢集跨多個版本，詳情可繼續關注筆者下一篇文章的探討。

還是那句話，Elastic 用得好，下班下得早。