作者介紹

李猛(ynuosoft)，Elastic-stack產(chǎn)品深度用戶，ES認(rèn)證工程師，2012年接觸Elasticsearch，對Elastic-Stack開發(fā)、架構(gòu)、運(yùn)維等方面有深入體驗(yàn)，實(shí)踐過多種Elasticsearch項(xiàng)目，最暴力的大數(shù)據(jù)分析應(yīng)用，最復(fù)雜的業(yè)務(wù)系統(tǒng)應(yīng)用；業(yè)余為企業(yè)提供Elastic-stack咨詢培訓(xùn)以及調(diào)優(yōu)實(shí)施。

序言

Elasticsearch，中文名直譯彈性搜索，不僅僅在單索引內(nèi)部分片層面彈性搜索，更強(qiáng)的是在跨索引外圍支持分片彈性搜索，同比其它分布式數(shù)據(jù)產(chǎn)品，此特性更鮮明，代表了Elastic集群架構(gòu)設(shè)計的優(yōu)越性。

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

• 為什么需要跨索引查詢？

• 跨索查詢有哪些經(jīng)典應(yīng)用場景？

• 跨索引查詢技術(shù)原理是怎樣的？

• 跨索引查詢有哪些注意事項(xiàng)？

為什么需要跨索引查詢

技術(shù)限制

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

• Elastic索引數(shù)據(jù)量有大小限制；

• 單個分片數(shù)據(jù)容量官方建議不超過50GB，合理范圍是20GB～40GB之間；

• 單個分片數(shù)據(jù)條數(shù)不超過約21億條（2的32次方），此值一般很難達(dá)到，基本可以忽略，背后原理可以參考源碼或者其它；

• 索引分片過多，分布式資源消耗越大，查詢響應(yīng)越慢。

基于以上限制，索引在創(chuàng)建之前就需要依據(jù)業(yè)務(wù)場景估算，設(shè)置合理的分片數(shù)，不能過多也不能過少。

技術(shù)便利

在基于關(guān)系型數(shù)據(jù)庫的應(yīng)用場景中，數(shù)據(jù)量過大，一般會采用分庫分表策略，查詢數(shù)據(jù)時基于第三方中間件，限制多多；在基于NoSQL的應(yīng)用場景中，如MongoDB，數(shù)據(jù)量過大，會采用數(shù)據(jù)產(chǎn)品本身提供的分片特性，查詢數(shù)據(jù)時基于自身的路由機(jī)制。

無論是分庫分表還是分片，它們只解決了一維數(shù)據(jù)的存儲與查詢，二維的不能，如電商訂單系統(tǒng)場景，數(shù)據(jù)庫采用多庫多表拆分，一旦容量超過預(yù)期設(shè)計，需要二次拆分繼續(xù)分庫分表；MongoDB采用多分片拆分，一旦容量超過預(yù)計設(shè)計，需要繼續(xù)擴(kuò)展分片節(jié)點(diǎn)。

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

跨索引查詢應(yīng)用場景

IT應(yīng)用中，除去技術(shù)本身局限問題，多數(shù)的問題都是由于耦合造成的，“高內(nèi)聚，低耦合”一直是我們IT從業(yè)者的座右銘。應(yīng)用系統(tǒng)耦合，就成了單體應(yīng)用，然后就延伸出微服務(wù)架構(gòu)理念。同樣數(shù)據(jù)耦合，我們也要基于一定維度的微服務(wù)化，或垂直或水平或混合垂直水平。

業(yè)務(wù)系統(tǒng)

舉例某些業(yè)務(wù)場景，實(shí)時數(shù)據(jù)與歷史數(shù)據(jù)存儲和查詢問題，假設(shè)日均數(shù)據(jù)量超過千萬條，那么月度數(shù)量超過3億條，年度也會超過36億條。

若采用Elasticsearch存儲，則可以按月/按季度/按年度 創(chuàng)建索引，這樣實(shí)時數(shù)據(jù)的更新只會影響當(dāng)前的索引，不影響歷史的索引；查詢時也一樣，依據(jù)查詢條件指定索引名稱，按需要掃描查詢，無需每次掃描所有的數(shù)據(jù)。這比基于傳統(tǒng)的數(shù)據(jù)產(chǎn)品靈活很多。

大數(shù)據(jù)

Elasticsearch在大數(shù)據(jù)應(yīng)用場景下很受歡迎，已經(jīng)成為大數(shù)據(jù)平臺對外提供結(jié)果查詢的標(biāo)配。大數(shù)據(jù)平臺需要定期計算數(shù)據(jù)，將結(jié)果數(shù)據(jù)批量寫入到Elasticsearch中，供業(yè)務(wù)系統(tǒng)查詢，由于部分業(yè)務(wù)規(guī)則設(shè)定，Elasticsearch原來的索引數(shù)據(jù)要全部刪除，并重新寫入，這種操作很頻繁。對于大數(shù)據(jù)平臺每次全量計算，代價很大，對于Elasticsearch平臺，超大索引數(shù)據(jù)頻繁刪除重建，代價也很大。

基于以上，采用多索引方式，如按照月份拆解，依據(jù)需要刪除的月份索引數(shù)據(jù)。同樣的問題，業(yè)務(wù)系統(tǒng)查詢時，非常靈活指定需要的月份索引數(shù)據(jù)，這樣保證了存儲與查詢的平衡。

日志

Elasticsearch應(yīng)對這個日志場景非常擅長，誕生了著名的ELK組合，比如一個大中型的業(yè)務(wù)系統(tǒng)，每天日志量幾十TB/幾百TB很正常，可按天或者按小時或者更小粒度創(chuàng)建索引，通常查詢?nèi)罩局粫樵冏罱鼤r間的，過去很久的日志，偶然需要查詢幾次，甚至?xí)h除。所以對于此場景，Elasticsearch的跨索引查詢非常便利，程序編寫也很簡單。

跨索引查詢應(yīng)用方式

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

直接型

明確指定多個索引名稱，這種方式一般應(yīng)用在非常精確的查詢場景下，便于查詢索引范圍，性能平衡考慮，若索引不存在會出現(xiàn)錯誤，如下：index_01,index_02

GET /index_01,index_02/_search

{

"query" : {

"match": {

"test": "data"

}

}

}

模糊型

不限定死索引名稱，這種方式一般采用通配符，無需判斷該索引是否存在，支持前匹配、后匹配，前后匹配，如下：index_* 匹配前綴一樣的所有索引

GET /index_*/_search

{

"query" : {

"match": {

"test": "data"

}

}

}

計算型

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

# 索引名稱如：index-2024.03.22

# GET //_search

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

"query" : {

"match": {

"test": "data"

}

}

}

跨索引查詢技術(shù)原理

Elasticsearch能夠做到跨索引查詢，離不開其架構(gòu)設(shè)計以及相關(guān)實(shí)現(xiàn)原理。

索引分片 

• 索引是一個虛擬的數(shù)據(jù)集合，索引由多個分片組成；

• 分片存儲實(shí)際的數(shù)據(jù)；

• 索引分片數(shù)量不限制。

查詢過程 

查詢過程簡單說來就是分發(fā)與合并：

• 查詢分發(fā)，客戶端發(fā)送請求到協(xié)調(diào)節(jié)點(diǎn)，協(xié)調(diào)節(jié)點(diǎn)分發(fā)查詢請求到索引分片節(jié)點(diǎn)；

• 數(shù)據(jù)合并，索引分片節(jié)點(diǎn)將數(shù)據(jù)發(fā)送到協(xié)調(diào)節(jié)點(diǎn)，協(xié)調(diào)節(jié)點(diǎn)合并返回客戶端。

所以說，Elasticsearch提供跨索引查詢的能力，實(shí)際上與原來單索引查詢時一樣，本質(zhì)上是跨多個分片查詢，然后合并。

跨索引查詢注意事項(xiàng)

索引與分片等價關(guān)系

索引與分片等價的關(guān)系，1個索引20分片與4個索引每個索引5個分片理論上是等價的，鑒于索引分片的容量限制與性能平衡，在面對需要跨索引業(yè)務(wù)場景時，索引的數(shù)量與分片的數(shù)量盡量的少，既要保障索引熱點(diǎn)數(shù)據(jù)的實(shí)時處理能力，也要平衡歷史數(shù)據(jù)的查詢性能。

協(xié)調(diào)節(jié)點(diǎn)分離

鑒于Elastic查詢過程，在跨多個索引查詢時，協(xié)調(diào)節(jié)點(diǎn)承擔(dān)了所有分片查詢返回的數(shù)據(jù)合并，需要消耗很大資源，在應(yīng)對高并發(fā)場景，建議部署獨(dú)立的協(xié)調(diào)節(jié)點(diǎn)，將集群的數(shù)據(jù)節(jié)點(diǎn)與協(xié)調(diào)節(jié)點(diǎn)分離，以達(dá)到最佳的性能平衡。

路由機(jī)制

Elasticsearch寫入數(shù)據(jù)分布默認(rèn)是基于索引主鍵_id的Hash值，此機(jī)制在數(shù)據(jù)分布上很均衡，但也沒有什么規(guī)律，對于跨索引查詢場景，若自定義指定路由鍵，可以在搜索時避開不需要的索引分片，有效減少分片查詢的分片數(shù)量，達(dá)到更高的性能。

總結(jié)

Elasticsearch由于其架構(gòu)設(shè)計的彈性能力，小小的一個跨索引查詢特性，就能給我們應(yīng)用系統(tǒng)帶來很多架構(gòu)設(shè)計的便利，解決很多實(shí)際場景問題，這是其它數(shù)據(jù)產(chǎn)品目前還做不到的。Elasticsearch還有更厲害的跨多個集群跨多個版本，詳情可繼續(xù)關(guān)注筆者下一篇文章的探討。

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

特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關(guān)注的小伙伴，可以長按關(guān)注一下：
			

		

長按訂閱更多精彩▼
			

		
如有收獲，點(diǎn)個在看，誠摯感謝