學習下ElasticSearch

ElasticSearch基礎概念

Elasticsearch的Head插件安裝

Elasticsearch在Centos 7上的安裝常見的問題

使用場景:好比分庫的狀況下，你想統計全部數據的報表，就把全部數據都放在ElasticSearch上

關係型數據庫	ElasticSearch
數據庫Database	索引index，支持全文檢索
表Table	類型Type
數據行Row	文檔Document
數據列Column	字段Field
模式Schema	映射Mapping

用關係型數據庫就會想到創建一張User表，再建字段等，

而在Elasticsearch的文件存儲，Elasticsearch是面向文檔型數據庫，一條數據在這裏就是一個文檔，用JSON做爲文檔序列化的格式

在ES6.0以後，已經不容許在一個index下建不一樣的Type了，一個index下只有一個Type(之後版本中Type概念會去掉，能夠直接把index類比成Table)

節點Node：

　　一個ElasticSearch運行的實列，集羣構成的單元

集羣Cluster：

　　由一個或多個節點組成，對外提供服務　　

Elasticsearch實現原理-倒排索引

ElasticSearch是基於倒排索引實現的

倒排索引（Inverted Index）也叫反向索引，有反向索引必有正向索引。

通俗地來說，正向索引是經過key找value，反向索引則是經過value找key。

倒排索引—單詞詞典

單詞詞典(Term Dictionary)是倒排索引的重要組成部分。

——記錄全部文檔的單詞，通常都比較大

——記錄單詞到倒排列表的關聯信息(這個單詞關聯了哪些文檔)

倒排索引—排序列表

倒排列表(Posting List)記錄了單詞對應文檔的集合，由倒排索引項(Posting)組成

倒排索引項(Posting)主要包含以下信息

—文檔Id，用於獲取原始信息

—單詞頻率(TF,Term Frequency)，記錄該單詞在文檔中出現的次數，用於後序相關算分

—位置(Position)，記錄單詞在文檔中的分詞位置，用於作詞語搜索(Phrase Query)

—偏移(Offset)，記錄單詞在文檔的開始和結束位置，用於高亮顯示

Elasticsearch分詞

搜索引擎的核心是倒排索引，而倒排索引的基礎就是分詞。所謂分詞能夠簡單理解爲將一個完整的句子切割爲一個個單詞的過程。也能夠叫文本分析，在es稱爲Analysis。

如文本：elasticSearch是最流行的搜索引擎

分詞結果：elasticSearch 流行 搜索引擎

分詞器是es中專門處理分詞的組件，英文爲Analyzer，它的組成以下

Character Filters：針對原始文本特殊處理，好比除html特殊符

Tokenizer：將原始文本按照必定規則切分爲單詞

TokenFilters：針對tokenizer處理的單詞就行在加工，好比轉小寫，刪除或新增處理(好比中文中的  這 呢 無實意的詞)

Analyze API

es提供了一個測試分詞的API接口，方便驗證分詞效果，endpoint是_analyze

—能夠直接指定analyze測試

—能夠直接指定索引中的字段進行測試

—能夠自定義分詞器進行測試

Elasticsearch文檔映射Mapping

Mapping相似數據庫中的表結構定義，主要做用以下：

—定義Index下的字段名(Field Name)

—定義字段的類型，好比數值型、字符串型、布爾型等

—定義倒排索引相關的配置，好比是否索引、記錄position等

Dynamic Mapping

es能夠自動識別文檔字段類型，從而下降用戶使用成本

SearchAPI介紹和相關性算分

es中存儲的數據進行查詢分析，endpoint爲_search

查詢主要有兩種形式

1）URI Search

操做簡單，方便經過命令進行測試

但 僅包含部分查詢語法

GET /indexname/_search?q=user:xx

2）Request Body Search

es提供的完備查詢語法Query DSL(Domain Specific Language)

GET /indexname/_search

{
　　"query": {
　　　　"term": {
　　　　　　"user": "xx"
　　　　}
　　}
}

相關算分

相關算分是指文檔與查詢語句直接的相關度，英文爲relevance

　　經過倒排索引能夠獲取與查詢語句相匹配的文檔列表，那麼如何將最符合用戶查詢的文檔放到前列呢

　　本質是一個排序問題，排序的依據是相關算分

ES目前主要有兩個相關性算分模型

　　TF/IDF模型

　　BM25模型 5.x以後的默認模型

BM25相比TF/IDF的一大優化是下降了TF(Term Frequency單詞頻率)在過大時的權重

相關算分是shard與shard間是相互獨立的，也就意味着一個Term的IDF等值在不一樣shard上是不一樣的。文檔的相關算分和它所處的shard有關

在文檔數量很少時 會致使相關算分嚴重不許的狀況發生

解決辦法

　　—設置分片數是一個，從根本排除問題，在文檔數據量很少時能夠考慮該方法，(百萬到千萬)

　　—二是使用DFS Query Then Ftech查詢方式

Elasticsearch分佈式特性

es支持集羣模式，是一個分佈式系統，好處是

—1)增長系統容量：內存、磁盤，使es集羣能夠支持PB級的數據

如何將數據分佈在全部節點上

　　—引入分片 Shard解決問題

分片是ES支持PB級數據的基石

　　—分片存儲了部分數據，能夠分部在任意節點上

　　—分片數在索引建立時指定且後序不容許再更改(即便你後面新增了也用不到)，默認5個

　　—分片有主分片和副本分片之分，以實現數據的高可用

es集羣由多個es實列組成

　　—不一樣集羣經過集羣名字來區分，可經過cluster.name修改，默認爲elasticSearch

　　—每一個ES實列本質是一個JVM進程，且有本身的名字，經過node.name修改

Master Node：Master節點經過集羣中全部的節點選舉產生，能夠被選舉的節點稱爲master-eligible節點，

　　　　　　相關配置以下：node.master:true

Coordinating Node：處理請求的節點爲Coordinating節點，該節點爲全部節點默認角色，不能取消

　　　　　　　　    做用是把請求路由到正確的節點處理，好比建立索引請求到master節點

Data Node：存儲數據的節點即爲data節點，默認節點都是data類型，相關配置以下：node.data.true

—2)提供系統可用性：即部分節點中止服務，整個集羣依然能夠正常服務

提升系統可用性

服務可用性

　　—兩個節點狀況下，容許其中一個節點中止服務　　

數據可用性

　　—引入副本(Replication)解決

　　—每一個節點上都有完備的數據

複製分片的意義在於容錯性，當一個節點掛了，另外一個節點上的分片能夠代替掛掉節點上的分片

故障轉移

一：

 二：

 三：

文檔到分片的映射算法

es經過以下公式計算文檔到對應的分片 -shard=hash(routing)%number_of_primary_shards

hash算法保證能夠將數據均勻的分散在分片中

routing是一個關鍵參數，默認是文檔id，也能夠自行指定

number_of_primary_shards是主片分數(該算法與主片分數相關，這也是分片數量一旦肯定就不能修改的緣由)

腦裂問題

在上述第一步的時候 node2和node3選舉node2爲master節點了時候，此時會更新cluster state

此時node1節點網絡恢復了，node1本身組成集羣后，也會更新cluster state

此時：同一個集羣有兩個master，並且維護不一樣的cluster state，網絡恢復後 沒法選擇正確的master

解決方案：僅在可選舉master-eligible節點數大於等於quorum時才能夠進行master選舉

　　　　    即便node1節點恢復了 ，可選節點數未達到quorum，不選舉