ES的跨索引查詢有多便利？對比下分庫分表、分片更直觀
掃描二維碼
隨時隨地手機看文章
作者介紹
李猛(ynuosoft)，Elastic-stack產(chǎn)品深度用戶，ES認證工程師，2012年接觸Elasticsearch，對Elastic-Stack開發(fā)、架構(gòu)、運維等方面有深入體驗，實踐過多種Elasticsearch項目，最暴力的大數(shù)據(jù)分析應用，最復雜的業(yè)務系統(tǒng)應用；業(yè)余為企業(yè)提供Elastic-stack咨詢培訓以及調(diào)優(yōu)實施。
Elasticsearch，中文名直譯彈性搜索，不僅僅在單索引內(nèi)部分片層面彈性搜索，更強的是在跨索引外圍支持分片彈性搜索，同比其它分布式數(shù)據(jù)產(chǎn)品，此特性更鮮明，代表了Elastic集群架構(gòu)設計的優(yōu)越性。
本文將從以下幾個方面展開探討：
-
為什么需要跨索引查詢？
-
跨索查詢有哪些經(jīng)典應用場景？
-
跨索引查詢技術(shù)原理是怎樣的？
-
跨索引查詢有哪些注意事項？
Elasticsearch索引本身有一些指標限制，對于很多新手來說最容易忽視或者亂用。
-
Elastic索引數(shù)據(jù)量有大小限制；
-
單個分片數(shù)據(jù)容量官方建議不超過50GB，合理范圍是20GB～40GB之間；
-
單個分片數(shù)據(jù)條數(shù)不超過約21億條（2的32次方），此值一般很難達到，基本可以忽略，背后原理可以參考源碼或者其它；
-
索引分片過多，分布式資源消耗越大，查詢響應越慢。
基于以上限制，索引在創(chuàng)建之前就需要依據(jù)業(yè)務場景估算，設置合理的分片數(shù)，不能過多也不能過少。
在基于關系型數(shù)據(jù)庫的應用場景中，數(shù)據(jù)量過大，一般會采用分庫分表策略，查詢數(shù)據(jù)時基于第三方中間件，限制多多；在基于NoSQL的應用場景中，如MongoDB，數(shù)據(jù)量過大，會采用數(shù)據(jù)產(chǎn)品本身提供的分片特性，查詢數(shù)據(jù)時基于自身的路由機制。
無論是分庫分表還是分片，它們只解決了一維數(shù)據(jù)的存儲與查詢，二維的不能，如電商訂單系統(tǒng)場景，數(shù)據(jù)庫采用多庫多表拆分，一旦容量超過預期設計，需要二次拆分繼續(xù)分庫分表；MongoDB采用多分片拆分，一旦容量超過預計設計，需要繼續(xù)擴展分片節(jié)點。
以上對于Elasticsearch可以不用這樣，它提供了兩個維度的拆分方式，第一維度采用多個索引命名拆分，第二維度采用索引多分片，對于查詢來說，可以靈活匹配索引，一次指定一個索引，也可以一次指定多個索引。
IT應用中，除去技術(shù)本身局限問題，多數(shù)的問題都是由于耦合造成的，“高內(nèi)聚，低耦合”一直是我們IT從業(yè)者的座右銘。應用系統(tǒng)耦合，就成了單體應用，然后就延伸出微服務架構(gòu)理念。同樣數(shù)據(jù)耦合，我們也要基于一定維度的微服務化，或垂直或水平或混合垂直水平。
舉例某些業(yè)務場景，實時數(shù)據(jù)與歷史數(shù)據(jù)存儲和查詢問題，假設日均數(shù)據(jù)量超過千萬條，那么月度數(shù)量超過3億條，年度也會超過36億條。
若采用Elasticsearch存儲，則可以按月/按季度/按年度 創(chuàng)建索引，這樣實時數(shù)據(jù)的更新只會影響當前的索引，不影響歷史的索引；查詢時也一樣，依據(jù)查詢條件指定索引名稱，按需要掃描查詢，無需每次掃描所有的數(shù)據(jù)。這比基于傳統(tǒng)的數(shù)據(jù)產(chǎn)品靈活很多。
Elasticsearch在大數(shù)據(jù)應用場景下很受歡迎，已經(jīng)成為大數(shù)據(jù)平臺對外提供結(jié)果查詢的標配。大數(shù)據(jù)平臺需要定期計算數(shù)據(jù)，將結(jié)果數(shù)據(jù)批量寫入到Elasticsearch中，供業(yè)務系統(tǒng)查詢，由于部分業(yè)務規(guī)則設定，Elasticsearch原來的索引數(shù)據(jù)要全部刪除，并重新寫入，這種操作很頻繁。對于大數(shù)據(jù)平臺每次全量計算，代價很大，對于Elasticsearch平臺，超大索引數(shù)據(jù)頻繁刪除重建，代價也很大。
基于以上，采用多索引方式，如按照月份拆解，依據(jù)需要刪除的月份索引數(shù)據(jù)。同樣的問題，業(yè)務系統(tǒng)查詢時，非常靈活指定需要的月份索引數(shù)據(jù)，這樣保證了存儲與查詢的平衡。
Elasticsearch應對這個日志場景非常擅長，誕生了著名的ELK組合，比如一個大中型的業(yè)務系統(tǒng)，每天日志量幾十TB/幾百TB很正常，可按天或者按小時或者更小粒度創(chuàng)建索引，通常查詢?nèi)罩局粫樵冏罱鼤r間的，過去很久的日志，偶然需要查詢幾次，甚至會刪除。所以對于此場景，Elasticsearch的跨索引查詢非常便利，程序編寫也很簡單。
Elasticsearch跨索引查詢的方式可依據(jù)業(yè)務場景靈活選擇，下面介紹幾種：
明確指定多個索引名稱，這種方式一般應用在非常精確的查詢場景下，便于查詢索引范圍，性能平衡考慮，若索引不存在會出現(xiàn)錯誤，如下：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 /
GET /%3Cindex-%7Bnow%2Fd%7D%3E/_search{
"query" : {
"match": {
"test": "data"
}
}
}
Elasticsearch能夠做到跨索引查詢，離不開其架構(gòu)設計以及相關實現(xiàn)原理。
-
索引是一個虛擬的數(shù)據(jù)集合，索引由多個分片組成；
-
分片存儲實際的數(shù)據(jù)；
-
索引分片數(shù)量不限制。
查詢過程簡單說來就是分發(fā)與合并：
-
查詢分發(fā)，客戶端發(fā)送請求到協(xié)調(diào)節(jié)點，協(xié)調(diào)節(jié)點分發(fā)查詢請求到索引分片節(jié)點；
-
數(shù)據(jù)合并，索引分片節(jié)點將數(shù)據(jù)發(fā)送到協(xié)調(diào)節(jié)點，協(xié)調(diào)節(jié)點合并返回客戶端。
所以說，Elasticsearch提供跨索引查詢的能力，實際上與原來單索引查詢時一樣，本質(zhì)上是跨多個分片查詢，然后合并。
索引與分片等價的關系，1個索引20分片與4個索引每個索引5個分片理論上是等價的，鑒于索引分片的容量限制與性能平衡，在面對需要跨索引業(yè)務場景時，索引的數(shù)量與分片的數(shù)量盡量的少，既要保障索引熱點數(shù)據(jù)的實時處理能力，也要平衡歷史數(shù)據(jù)的查詢性能。
鑒于Elastic查詢過程，在跨多個索引查詢時，協(xié)調(diào)節(jié)點承擔了所有分片查詢返回的數(shù)據(jù)合并，需要消耗很大資源，在應對高并發(fā)場景，建議部署獨立的協(xié)調(diào)節(jié)點，將集群的數(shù)據(jù)節(jié)點與協(xié)調(diào)節(jié)點分離，以達到最佳的性能平衡。
Elasticsearch寫入數(shù)據(jù)分布默認是基于索引主鍵_id的Hash值，此機制在數(shù)據(jù)分布上很均衡，但也沒有什么規(guī)律，對于跨索引查詢場景，若自定義指定路由鍵，可以在搜索時避開不需要的索引分片，有效減少分片查詢的分片數(shù)量，達到更高的性能。
Elasticsearch由于其架構(gòu)設計的彈性能力，小小的一個跨索引查詢特性，就能給我們應用系統(tǒng)帶來很多架構(gòu)設計的便利，解決很多實際場景問題，這是其它數(shù)據(jù)產(chǎn)品目前還做不到的。Elasticsearch還有更厲害的跨多個集群跨多個版本，詳情可繼續(xù)關注筆者下一篇文章的探討。
還是那句話，Elastic用得好，下班下得早。
特別推薦一個分享架構(gòu)+算法的優(yōu)質(zhì)內(nèi)容，還沒關注的小伙伴，可以長按關注一下：
長按訂閱更多精彩▼
如有收獲，點個在看，誠摯感謝
免責聲明：本文內(nèi)容由21ic獲得授權(quán)后發(fā)布，版權(quán)歸原作者所有，本平臺僅提供信息存儲服務。文章僅代表作者個人觀點，不代表本平臺立場，如有問題，請聯(lián)系我們，謝謝！
下載文檔
