作者介紹

李猛(ynuosoft)， Elastic-stack產品深度用戶，ES認證工程師，2012年接觸Elasticsearch，對Elastic-Stack開發、架構、運維等方面有深入體驗，實踐過多種Elasticsearch項目，最暴力的大數據分析應用，最複雜的業務系統應用；業餘爲企業提供Elastic-stack諮詢培訓以及調優實施。

序言

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 /<index-{now/d}>/_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用得好，下班下得早。