Elasticsearch簡(jiǎn)介

Elasticsearch是什么？它能干什么？

Elasticsearch（以下稱之為ES）是一款基于Lucene的分布式全文搜索引擎，擅長(zhǎng)海量數(shù)據(jù)存儲(chǔ)、數(shù)據(jù)分析以及全文檢索查詢，它是一款非常優(yōu)秀的數(shù)據(jù)存儲(chǔ)與數(shù)據(jù)分析中間件，廣泛應(yīng)用于日志分析以及全文檢索等領(lǐng)域，目前很多大廠都基于Elasticsearch開(kāi)發(fā)了自己的存儲(chǔ)中間件以及數(shù)據(jù)分析平臺(tái)。

從核心概念開(kāi)始

Lucence

Lucene是Apache下的一個(gè)子項(xiàng)目，是一個(gè)開(kāi)放源代碼的全文檢索引擎工具包，但它不是一個(gè)完整的全文檢索引擎，而是一個(gè)全文檢索引擎的架構(gòu)，提供了完整的查詢引擎和索引引擎，它是ES實(shí)現(xiàn)全文檢索的核心基礎(chǔ)，索引文檔以及搜索索引的的核心流程都是在Lucene中完成的。

核心數(shù)據(jù)結(jié)構(gòu)

Document

我們都說(shuō)ES是面向document的，這句話什么意思呢？實(shí)際就是表示ES是基于document進(jìn)行數(shù)據(jù)操作的，操作主要包括數(shù)據(jù)搜索以及索引（這里的索引時(shí)數(shù)據(jù)寫(xiě)入的意思）。因此可以說(shuō)document是ES的基礎(chǔ)數(shù)據(jù)結(jié)構(gòu)，它會(huì)被序列化之后保存到ES中。那么這個(gè)document到底是個(gè)什么東東呢？相信大家都對(duì)Mysql還是比較熟悉的，因此我們用Mysql中的數(shù)據(jù)庫(kù)與表的概念與ES的index進(jìn)行對(duì)比，可能并不是十分的恰當(dāng)和吻合，但是可以有助于大家對(duì)于這些概念的理解。另外type也在ES6.x版本之后逐漸取消了。

Index

在ES之前的版本中，是有type這個(gè)概念的，類比數(shù)據(jù)庫(kù)中的表，那上文中所說(shuō)的document就會(huì)放在type中。但是在ES后面的版本中為了提高數(shù)據(jù)存儲(chǔ)的效率逐漸取消了type，因此index實(shí)際上在現(xiàn)在的ES中既有庫(kù)的概念也有表的概念。簡(jiǎn)單理解就是index就是文檔的容器，它是一類文檔的集合，但是這里需要注意的是index是邏輯空間的分類，實(shí)際數(shù)據(jù)是存在物理空間的分片上的。

另外需要說(shuō)明的是，在ES中索引是有不同上下文含義的，它既可以是名詞也可以是動(dòng)詞。索引為名詞是就是上文中提到的它是document的集合，索引為動(dòng)詞的時(shí)候表示將document數(shù)據(jù)保存到ES中，也就是數(shù)據(jù)寫(xiě)入。

在ES中，為了屏蔽語(yǔ)言的交互差異，ES直接對(duì)外的交互都是通過(guò)Rest API進(jìn)行的。

倒排索引

我們都知道索引存在的意義就是為了加速數(shù)據(jù)的查詢。在關(guān)系型數(shù)據(jù)庫(kù)中如果沒(méi)有索引的話，為了查找數(shù)據(jù)我們需要每條數(shù)據(jù)去進(jìn)行比對(duì)，運(yùn)氣不好的話可能需要掃描全表才能查找到想要的數(shù)據(jù)。以Mysql為例，它使用了B+樹(shù)作為索引來(lái)加速數(shù)據(jù)的查詢。假設(shè)有這樣的一種場(chǎng)景，周末在路上逛的時(shí)候突然聽(tīng)到一首非常好聽(tīng)的歌曲，你記住了其中兩句歌詞，想著趕快拿手機(jī)到QQ音樂(lè)中查一下是什么歌。如果你是QQ音樂(lè)的程序猿，你該怎么實(shí)現(xiàn)根據(jù)歌詞查詢歌曲的功能呢？ 用B+樹(shù)作為索引行不行呢？全文索引就是需要支持對(duì)大文本進(jìn)行索引的，從空間上來(lái)說(shuō) B+ 樹(shù)不適合作為全文索引，同時(shí) B+ 樹(shù)因?yàn)槊看嗡阉鞫际菑母?jié)點(diǎn)開(kāi)始往下搜索，所以會(huì)遵循最左匹配原則，而我們使用全文搜索時(shí)，往往不會(huì)遵循最左匹配原則，所以可能會(huì)導(dǎo)致索引失效。這時(shí)候倒排索引就派上用場(chǎng)了。 所謂正排索引就像書(shū)中的目錄一樣，根據(jù)頁(yè)碼查詢內(nèi)容，但是倒排索引確實(shí)相反的，它是通過(guò)對(duì)內(nèi)容的分詞，建立內(nèi)容到文檔ID的關(guān)聯(lián)關(guān)系。這樣在進(jìn)行全文檢索的時(shí)候，根據(jù)詞典的內(nèi)容便可以精確以及模糊查詢，非常符合全文檢索的要求。

倒排索引的結(jié)構(gòu)主要包括了兩大部分一個(gè)是Term Dictionary（單詞詞典），另一個(gè)是Posting List（倒排列表）。Term Dictionary（單詞詞典）記錄了所用文檔的單詞以及單詞和倒排列表的關(guān)系。Posting List（倒排列表）則是記錄了term在文檔中的位置以及其他信息，主要包括文檔ID,詞頻（term在文檔中出現(xiàn)的次數(shù)，用來(lái)計(jì)算相關(guān)性評(píng)分），位置以及偏移（實(shí)現(xiàn)搜索高亮）。

FST

如上文所述，在進(jìn)行全文檢索的時(shí)候，通過(guò)倒排索引中term與docId的關(guān)聯(lián)關(guān)系獲取到原始數(shù)據(jù)。但是這里有一個(gè)問(wèn)題，ES底層依賴Lucene實(shí)現(xiàn)倒排索引的，因此在進(jìn)行數(shù)據(jù)寫(xiě)入的時(shí)候，Lucene會(huì)為原始數(shù)據(jù)中的每個(gè)term生成對(duì)應(yīng)的倒排索引，因此造成的結(jié)果就是倒排索引的數(shù)據(jù)量就會(huì)很大。而倒排索引對(duì)應(yīng)的倒排表文件是存儲(chǔ)在硬盤(pán)上的。如果每次查詢都直接去磁盤(pán)中讀取倒排索引數(shù)據(jù)，在通過(guò)獲取的docId再去查詢?cè)紨?shù)據(jù)的話，肯定會(huì)造成多次的磁盤(pán)IO，嚴(yán)重影響全文檢索的效率。因此我們需要一種方式可以快速定位到倒排索引中的term。大家想想使用什么方式比較好呢？可以考慮HashMap， TRIE， Binary Search Tree或者Tenary Search Tree等數(shù)據(jù)結(jié)構(gòu)，實(shí)際上Lucene實(shí)際是使用了FST（Finite State Transducer）有限狀態(tài)傳感器來(lái)實(shí)現(xiàn)二級(jí)索引的設(shè)計(jì)，它其實(shí)就是一種有限狀態(tài)機(jī)。

我們先來(lái)看下 trie樹(shù)的結(jié)構(gòu)，在Lucene中是這樣做的，將倒排索引中具有公共前綴的term組成一個(gè)block，如下圖所示的cool以及copy，它們擁有co的公共前綴，按照類似前綴樹(shù)的邏輯來(lái)構(gòu)成trie樹(shù)，對(duì)應(yīng)節(jié)點(diǎn)中攜帶block的首地址。我們來(lái)分析下trie樹(shù)相比hashmap有什么優(yōu)點(diǎn)？hashmap實(shí)現(xiàn)的是精準(zhǔn)查找，但是trie樹(shù)不僅可以實(shí)現(xiàn)精準(zhǔn)查找，另外由于其公共前綴的特性還可以實(shí)現(xiàn)模糊查找。那我們?cè)倏磘rie樹(shù)有什么地方可以再進(jìn)行優(yōu)化的地方？

如上如所示，term中的school以及cool的后面字符是一致的，因此我們可以通過(guò)將原先的trie樹(shù)中的后綴字符進(jìn)行合并來(lái)進(jìn)一步的壓縮空間。優(yōu)化后的trie樹(shù)就是FST。

因此通過(guò)建立FST這個(gè)二級(jí)索引，可以實(shí)現(xiàn)倒排索引的快速定位，不需要經(jīng)過(guò)多次的磁盤(pán)IO，搜索效率大大提高了。不過(guò)需要注意的是FST是存儲(chǔ)在堆內(nèi)存中的，而且是常駐內(nèi)存，大概占用50%-70%的堆內(nèi)存，因此這里也是我們?cè)谏a(chǎn)中可以進(jìn)行堆內(nèi)存優(yōu)化的地方。

集群相關(guān)概念

為了增強(qiáng)ES的數(shù)據(jù)存儲(chǔ)可靠性以及高可用，ES支持進(jìn)行集群部署，集群后的ES即便是某些節(jié)點(diǎn)出現(xiàn)故障，也不會(huì)導(dǎo)致真?zhèn)€ES集群不可用，同時(shí)通過(guò)水平擴(kuò)容增強(qiáng)了ES的數(shù)據(jù)存儲(chǔ)能力。

節(jié)點(diǎn)

所謂的節(jié)點(diǎn)實(shí)際就是ES的實(shí)例，我們通常在一臺(tái)服務(wù)器部署一個(gè)ES實(shí)例，其實(shí)就是一個(gè)Java進(jìn)程。雖然都是ES實(shí)例，但是實(shí)際上的ES集群，不同節(jié)點(diǎn)承擔(dān)著不同的能力角色，有的是data node，主要負(fù)責(zé)保存分片的數(shù)據(jù)的，承擔(dān)著數(shù)據(jù)橫向擴(kuò)展的重要作用，有的是coordinating node負(fù)責(zé)將用戶請(qǐng)求進(jìn)行轉(zhuǎn)發(fā)以及將查詢的結(jié)果進(jìn)行合并返回。當(dāng)然還有master節(jié)點(diǎn)，負(fù)責(zé)對(duì)真?zhèn)€集群狀態(tài)進(jìn)行管理和維護(hù)。

分片

單個(gè)ES節(jié)點(diǎn)的數(shù)據(jù)存儲(chǔ)畢竟有限，沒(méi)法實(shí)現(xiàn)海量數(shù)據(jù)的存儲(chǔ)要求。那么怎么才能滿足海量數(shù)據(jù)的存儲(chǔ)要求呢？一個(gè)核心思想就是拆分，比如總共10億條數(shù)據(jù)，如果都放在一個(gè)節(jié)點(diǎn)中不僅查詢以及數(shù)據(jù)寫(xiě)入的速度回很慢，頁(yè)存在單點(diǎn)問(wèn)題。在傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)中，采用分庫(kù)分表的方式，用更多的數(shù)據(jù)庫(kù)實(shí)例來(lái)承接大量的數(shù)據(jù)存儲(chǔ)。那么在ES中，也是采取類似的設(shè)計(jì)思想，既然一個(gè)ES的實(shí)例存在數(shù)據(jù)存儲(chǔ)的上線，那么就用多個(gè)實(shí)例來(lái)進(jìn)行存儲(chǔ)。在每個(gè)實(shí)例中存在的數(shù)據(jù)集合就是分片。如下圖所示，index被切分成三個(gè)分片，三個(gè)分片分別存儲(chǔ)在三個(gè)ES實(shí)例中，同時(shí)為了提升數(shù)據(jù)的高可用性，每個(gè)主分片都有兩個(gè)副本分片，這些副本分片是主分片的數(shù)據(jù)拷貝。

put /article
{    
	"settings": {
  		"number_of_shards":3,
    	"number_of_replicas":3
  }  
}

這里需要注意的是，分片不是隨意進(jìn)行設(shè)定的，而是需要根據(jù)實(shí)際的生產(chǎn)環(huán)境提前進(jìn)行數(shù)據(jù)存儲(chǔ)的容量規(guī)劃，否則分片設(shè)置的過(guò)大或者過(guò)小都會(huì)影響ES集群的整體性能。如果分片設(shè)置的過(guò)小，那么單個(gè)分片的數(shù)據(jù)量可能會(huì)很大，影響數(shù)據(jù)檢索效率，也會(huì)影響數(shù)據(jù)的橫向擴(kuò)展。如果分片設(shè)置的過(guò)大就會(huì)影響搜索結(jié)果的數(shù)據(jù)相關(guān)性評(píng)分，影響數(shù)據(jù)檢索的準(zhǔn)確性。

總結(jié)

本文對(duì)ES的核心概念進(jìn)行了全面的梳理與闡述，相信大家對(duì)于ES有了初步的了解，下篇文章中再帶大家好好理解下ES的核心業(yè)務(wù)流程的原理以及優(yōu)秀的設(shè)計(jì)思想，只有理解了ES的核心概念以及核心流程，那么在生產(chǎn)中遇到一些搜索優(yōu)化、節(jié)點(diǎn)JVM優(yōu)化等才會(huì)有對(duì)應(yīng)的排查方向，另外ES中的一些優(yōu)秀的設(shè)計(jì)思想，也是非常值得我們學(xué)習(xí)的，當(dāng)我們?cè)谠O(shè)計(jì)軟件平臺(tái)的時(shí)候有時(shí)可以借鑒這些優(yōu)秀的設(shè)計(jì)思想。

到此這篇關(guān)于Java面試重點(diǎn)中的重點(diǎn)之Elasticsearch核心原理的文章就介紹到這了,更多相關(guān)Java Elasticsearch內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評(píng)論