帶給你一篇Elasticsearch入門文章
?
?
引言
Elasticsearch(以下簡稱ES)是我想寫想了很久的一個系列，因為他是我在老東家離職前剛接觸的最后一個新技術(shù)，當(dāng)時就是對某子業(yè)務(wù)的商品搜索做改造，從MySQL遷移商品數(shù)據(jù)到ES中。
我先說一下當(dāng)時為什么會有場景需要引用到ES，上面我說到是一個商品庫的搜索改造，在之前這個子業(yè)務(wù)體量很小使用的人不多，使用場景也比較單一，所以我們就覺得放在數(shù)據(jù)庫里也沒什么，因為正常需求也是可以滿足的。
在數(shù)據(jù)庫我們需要搜索的時候簡單，直接模糊查詢就好了 select id from item where itemName like %xxx%
但是如果你搜索的關(guān)鍵詞有一點不對，就可能匹配不上這個商品，比如商品叫：“煩死了，打不掉” 而你搜索的關(guān)鍵詞是：“煩了” 就匹配不上了，但是他們其實在意思上是有一點關(guān)聯(lián)的對吧?搜出來用戶也是能接受的。
而且隨著你業(yè)務(wù)的發(fā)展，可能需要你搜索出商品名稱帶這個關(guān)鍵詞且描述里面也帶的，這個場景其實多寫點業(yè)務(wù)代碼也能滿足，但是條件越來越多的時候呢?
還有就是業(yè)務(wù)發(fā)展往往是指數(shù)級別的，當(dāng)時我們從幾十萬到百萬用了一年，但是百萬到億就用了幾個月，而且數(shù)據(jù)量級還在不斷增長，這個時候放在數(shù)據(jù)庫就不光是業(yè)務(wù)條件不能滿足了，性能也不是加個索引能搞定的了。
正文
我先介紹一下目前主流的幾種數(shù)據(jù)庫存儲方式 ：
行存儲：同一行的數(shù)據(jù)被物理的存儲在一起
常見的行式數(shù)據(jù)庫系統(tǒng)有：MySQL、Postgres和MS SQL Server。
存儲結(jié)構(gòu)：
?
?
某些場景下行存儲數(shù)據(jù)庫的查詢效率：
列存儲 ：來自不同列的值被單獨存儲，來自同一列的數(shù)據(jù)被存儲在一起
常見的列式數(shù)據(jù)庫有：Vertica、 Paraccel (Actian Matrix，Amazon Redshift)、 Sybase IQ、 Exasol、 Infobright、 InfiniDB、 MonetDB (VectorWise， Actian Vector)、 LucidDB、 SAP HANA、 Google Dremel、 Google PowerDrill、 Druid、 kdb+、Hbase、clickhouse。
?
?
某些場景下列存儲數(shù)據(jù)庫的查詢效率：
最近我在接觸Clickhouse他就是列式存儲，他之所以這么快，主要是以下三點原因：
- 輸入/輸出
- 針對分析類查詢，通常只需要讀取表的一小部分列。在列式數(shù)據(jù)庫中你可以只讀取你需要的數(shù)據(jù)。例如，如果只需要讀取100列中的5列，這將幫助你最少減少20倍的I/O消耗。
- 由于數(shù)據(jù)總是打包成批量讀取的，所以壓縮是非常容易的。同時數(shù)據(jù)按列分別存儲這也更容易壓縮。這進一步降低了I/O的體積。
- 由于I/O的降低，這將幫助更多的數(shù)據(jù)被系統(tǒng)緩存。
注：這里列出這兩個只是對比一些特殊場景的效率差，也是為后面es的快和數(shù)據(jù)結(jié)構(gòu)做鋪墊而已，事實上Clickhouse這樣的數(shù)據(jù)庫也只適合某些場景，大部分場景還得行式數(shù)據(jù)庫。
大家感興趣我后面可以來點Clickhouse的分享(雖然我也還在看)
接下來就說另外一種存儲結(jié)構(gòu)了：
文檔
實際上 es在某種程度上是和列式文檔有一定的相似之處的，大家往后面看就知道了
{
"name": "name"
"size": 24
"sex': "male"
}上面我介紹了幾種常見的存儲結(jié)構(gòu)其實是為了說明一下es的場景，以及es的一些優(yōu)勢，我們都知道數(shù)據(jù)庫是有索引的，而且也挺快的，那es又是怎么存儲數(shù)據(jù)，他的索引又是咋樣的呢?
倒排索引
倒排顧名思義就是通過Value去找key，跟我們傳統(tǒng)意義的根據(jù)key找value還不太一樣。
舉個例子，還是上面的數(shù)據(jù)，我們可以看到es會建立以下的索引：
Name 倒排索引
?
?
Size倒排索引
?
?
Sex倒排索引
?
?
大家可以看到所有的倒排所有都有Term和Posting List這兩個概念，Posting list就是一個int的數(shù)組，存儲了所有符合某個term的文檔id。
怎么根據(jù)value找key呢?就比如我要找所有性別是男生的人，Sex的倒排索引的Posting list可以告訴我是id為1和3的人，那再通過Name的term我可以看到1的是人aobing，3的人是雞蛋，依次類推找到所有信息。
Es的查詢速度是非?？斓?，但是目前看來如果只是以Term的樣子去查找并不快呀?是為什么呢?
這里就會引出接下來的兩個概念，Term Dictionary和Term Index。
Term Dictionary：這個很好理解，我上面說過都是各種Term組成的，那為了查找Term方便，es把所有的Term都排序了，是二分法查找的。
?
?
Trem Index：這是為了優(yōu)化Term Dictionary而存在的，大家想呀這么多Term光是排序了肯定也不行，想要快就得放到內(nèi)存，但是es數(shù)據(jù)量級往往是很大的，那放在磁盤?磁盤的尋址又會很慢，那怎么去減少磁盤上的尋址開銷呢?Term Index
其實就是跟新華字典一樣，每個字母開頭的是哪些，再按照拼音去排序。
?
?
這就是三者的關(guān)系，是一張很經(jīng)典的圖了，基本上所有學(xué)es的人都應(yīng)該看到過。
Term Index就存了一些前綴和映射關(guān)系，這樣可以大大減少磁盤的隨機讀次數(shù)了。
巧妙壓縮
大家是不是發(fā)現(xiàn)這個設(shè)計是很巧妙的?而且es的檢索速度比MySQL是快很多的，大家在使用MySQL的時候可以發(fā)現(xiàn)其實索引跟Trem Dictionary是一樣的，但是es多了一個Index 多了一層篩選，少了一些隨機次數(shù)。
還有一點我很想提一下，就是Term index 在磁盤的存儲結(jié)構(gòu)，這個在我歷史文章有寫過，而且當(dāng)時我還踩過他的坑，今天鑒于篇幅，我就簡單介紹一下。
FST大家可以理解為一種壓縮技術(shù)，最簡單化通過壓縮字節(jié)的方式，上面我說了Term index放到內(nèi)存都放不下，但是壓縮一下呢?
?
?
細節(jié)我就不展開了，下面這個文章解釋的特別詳細，因為這是一篇大概科普的，后面我會專門出文章介紹集群和他壓縮的細節(jié)。
?
?
鏈接：https://cs.nyu.edu/~mohri/pub/fla.pdf
接下來再介紹一些es里面我覺得很重要的概念吧：
接近實時(NRT)
ES寫入的數(shù)據(jù)會先寫到一個內(nèi)存bufferr中去(在buffer里的時候數(shù)據(jù)是搜索不到的)，然后每隔默認是一秒會刷到os cache。
操作系統(tǒng)里面，磁盤文件其實都有一個東西，叫做os cache，操作系統(tǒng)緩存，就是說數(shù)據(jù)寫入磁盤文件之前，會先進入os cache，先進入操作系統(tǒng)級別的一個內(nèi)存緩存中去。
只要buffer中的數(shù)據(jù)被refresh操作，刷入os cache中，就代表這個數(shù)據(jù)就可以被搜索到了。默認是每隔1秒refresh一次的，所以es是準(zhǔn)實時的，因為寫入的數(shù)據(jù)1秒之后才能被看到。
為什么要這么設(shè)計呢?
簡單我們看一下不這么設(shè)計會怎么樣：
?
?
如果寫入緩存之后直接刷到硬盤，其實是十分消耗資源的，而且寫了馬上去硬盤讀取，并發(fā)量很難上去，你可以想象上萬QPS寫入的時候，還去查詢磁盤，是怎樣一個災(zāi)難級別的現(xiàn)場。
那es怎么做的呢?
?
?
數(shù)據(jù)寫入到buffer，然后再每秒刷到cache，這個時候就可以被搜到了，所以說準(zhǔn)實時，而不是實時就是這一秒的差距，這樣設(shè)計可以讓磁盤壓力減少不說，寫入和查詢都不會受到影響，并發(fā)也就上去了。
分詞文本分析(Analysis)是把全文本轉(zhuǎn)換一系列單詞(term/token)的過程，也稱為分詞。
當(dāng)一個文檔被索引時，每個Term都可能會創(chuàng)建一個倒排索引。倒排索引的過程就是將文檔通過分詞器(Analyzer)分成一個一個的Term，每一個Term都指向包含這個Term的文檔集合。
分詞
是es比較核心的功能，但是他默認的分詞其實對中文并不友好，比如我搜中國，那可能會把帶中和帶國的都搜出來，但是中國就是一個詞匯不應(yīng)該這樣分。
現(xiàn)在都是可以采用機器學(xué)習(xí)算法來分詞，還有一些中文分詞插件，比如ik分詞器。
他內(nèi)置分詞器的在英文場景是比較好用的。
腦裂
腦裂問題其實在集群部署的機器上都是會存在的，假設(shè)現(xiàn)在es集群有兩個節(jié)點，節(jié)點1是主節(jié)點對外提供服務(wù)，節(jié)點2是副本分片節(jié)點。
?
?
現(xiàn)在兩個節(jié)點因為網(wǎng)絡(luò)原因斷聯(lián)了，會發(fā)現(xiàn)什么?主節(jié)點發(fā)現(xiàn)自己是主節(jié)點繼續(xù)對外提供服務(wù)，副本節(jié)點發(fā)現(xiàn)沒有主節(jié)點了，選舉自己是主節(jié)點，也對外提供服務(wù)了，因為主節(jié)點不可用他也是被迫當(dāng)主節(jié)點的(狗頭)。
?
?
?
?
對于調(diào)用者來說，這是很難發(fā)現(xiàn)差別的，除非去對比數(shù)據(jù)，而我之前在生產(chǎn)環(huán)境就發(fā)生過腦裂的情況，還是用戶反饋的，因為搜索一個詞匯他有時候能搜出那個商品，有時候不能，因為請求打在不同的節(jié)點上了。
那正常我們會怎么解決呢?elasticsearch.yml中有個配置:discovery.zen.minimum_master_nodes 這個參數(shù)決定了在選主過程中需要有多少個節(jié)點通信，默認是1，設(shè)置的原則就是設(shè)置為 集群節(jié)點數(shù)量/2+1個。
如果你的集群是三個節(jié)點，那這個參數(shù)就設(shè)置為3/2+1=2個，那掛了一個，另外兩個可以通信，所以可以選出一個主的，如果你集群是三個節(jié)點，參數(shù)還是2，但是你發(fā)現(xiàn)掛了一個只有一個節(jié)點自己跟自己通信，就不會選主了。
但是這樣也有弊端只有2個節(jié)點的時候，掛一個就相當(dāng)于服務(wù)不可用了，所以大家要保證集群是三個以上是最好的。
- Elasticsearch的選舉算法基于 Bully 選舉算法，簡單的說，在 Bully 算法中，每個節(jié)點都有一個編號，只有編號最大的存活節(jié)點才能成為 master 節(jié)點。Bully算法的具體過程為：
- 當(dāng)任何一個進程P發(fā)現(xiàn) master 不響應(yīng)請求時，它發(fā)起一次選舉，選舉過程如下：
- (1)P進程向所有編號比它大的進程發(fā)送一個 election 消息;
- (2)如果無人響應(yīng)，則P獲勝，成為 master;
- (3)如果編號比它大的進程響應(yīng)，則由響應(yīng)者接管選舉工作，P的工作完成。
- 任何一個時刻，一個進程只能從編號比它小的進程接受 election 消息，當(dāng)消息到達時，接受者發(fā)送一個 OK 消息給發(fā)送者，表明它在運行，接管工作。
- 最終除了一個進程外，其他進程都放棄，那個進程就是新的協(xié)調(diào)者，隨后協(xié)調(diào)者將獲勝消息發(fā)送給其他所有進程，通知它們新的協(xié)調(diào)者誕生了。
ELK
其實提到ES往往都是ELK三兄弟一起提到的，最后在收尾的地方，我就說一下另外兩個兄弟吧。
L是Logstash，Logstash是一個開源數(shù)據(jù)收集引擎，具有實時管道功能。Logstash可以動態(tài)地將來自不同數(shù)據(jù)源的數(shù)據(jù)統(tǒng)一起來，并將數(shù)據(jù)標(biāo)準(zhǔn)化到你所選擇的目的地。
Logstash管道有兩個必需的元素：輸入和輸出，以及一個可選元素：過濾器。輸入插件從數(shù)據(jù)源那里消費數(shù)據(jù)，過濾器插件根據(jù)你的期望修改數(shù)據(jù)，輸出插件將數(shù)據(jù)寫入目的地。
K就是Kibana，Kibana是一個針對Elasticsearch的開源分析及可視化平臺，用來搜索、查看交互存儲在Elasticsearch索引中的數(shù)據(jù)。使用Kibana，可以通過各種圖表進行高級數(shù)據(jù)分析及展示。
Kibana讓海量數(shù)據(jù)更容易理解。它操作簡單，基于瀏覽器的用戶界面可以快速創(chuàng)建儀表板(dashboard)實時顯示Elasticsearch查詢動態(tài)。
設(shè)置Kibana非常簡單，無需編碼或者額外的基礎(chǔ)架構(gòu)，幾分鐘內(nèi)就可以完成Kibana安裝并啟動Elasticsearch索引監(jiān)測。
??
總結(jié)
這只是簡單的介紹一下es的一些基礎(chǔ)只是，他的壓縮算法，還有集群，分片，副本復(fù)制等等我都沒聊，下篇文章我會介紹的，
