lucene和ElasticSearch基本概念

lucene基本概念

索引(Index)

對應一個倒排表，一個檢索的基本單位。在lucene中就對應一個目錄。

lucene基本概念

段(Segment)

一個索引能夠包含多個段，段與段之間是獨立的，添加新文檔能夠生成新的段，不一樣的段能夠合併。段是索引數據存儲的單元。

文檔(Document)

•文檔是咱們建索引的基本單位，不一樣的文檔是保存在不一樣的段中的，一個段能夠包含多篇文檔。

•新添加的文檔是單獨保存在一個新生成的段中，隨着段的合併，不一樣的文檔合併到同一個段中。

域(Field)

•一篇文檔包含不一樣類型的信息，能夠分開索引，好比標題，時間，正文，做者等，均可以保存在不一樣的域裏。

•不一樣域的索引方式能夠不一樣。

詞(Term)

詞是索引的最小單位，是通過詞法分析和語言處理後的字符串。

詞相同，但域不一樣被認爲是兩個不一樣的詞，也就是說詞是詞根和域名的一個組合。

詞向量(Term Vector)

又稱文檔向量（document vector),由詞文本和詞頻率組成。

語義樹

語義樹是構成搜索處理的一箇中間結果，搜索時，會生成語義樹，而後再進行搜索。

權重（Term Weight)

計算分值時使用的主要指標，指詞(Term）在文檔中的分值，脫離文檔單獨說某個詞的權重是沒有意義的。

Term Frequency (tf)：即此Term 在此文檔中出現了多少次。tf 越大說明越重要。

Document Frequency (df)：即有多少文檔包含次Term。df 越大說明越不重要  。

 Posting

通常狀況下，將一個詞條所索引的文檔（通常用文檔編號表示）稱之爲 Posting，那麼一個詞條索引的多個文檔就稱之爲 Posting-list。這個詞咱們在看Java api的時候會常常看到

Payload

 即詞條 (Term) 的元數據或稱載荷， Lucene 支持用戶在索引的過程當中將詞條的元數據添加的索引庫中，同時也提供了在檢索結果時讀取 Payload 信息的功能。Payload 的誕生爲用戶提供了一種可靈活配置的高級索引技術，爲支持更加豐富的搜索體驗創造了條件。

倒排表（Inverted Indexing）

倒排表是Lucene索引採用的一套數據結構，這種結構以詞爲中心，可以快速找到包含該詞根的文檔。由於跟正常的便利文檔檢索採用的方法相反，所以叫倒排表。倒排表是一種數據結構，lucene的數據文件一塊兒構成了一張大的倒排表，而不是具體的某文件存儲的倒排結構。

文檔編號（Document Number)

Lucene內部經過文檔編號索引文檔。這個編號在一個段內部惟一，一個段的第一個文檔的編號爲0，依次遞增。不過這個編號僅用於lucene內部使用，並且這個編號在段合併的時候會發生改變。若是須要在段外部使用，必須對這個編號進行惟一性從新編排，確保一個文檔在更大的範圍也是惟一的。從新編排的一個實現方法是，基數+段內序號的方法。好比有兩個段，每一個段裏面都有5個文檔，則第一個段的文檔編號=0+段內編號，第二個段的文檔編號=5+段內編號。

 

 

ES基本概念

索引(Index)

ElasticSearch把數據存放到一個或者多個索引(indices)中。若是用關係型數據庫模型對比，索引(index)的地位與數據庫實例(database)至關。索引存放和讀取的基本單元是文檔(Document)。咱們也一再強調，ElasticSearch內部用Apache Lucene實現索引中數據的讀寫。讀者應該清楚的是：在ElasticSearch中被視爲單獨的一個索引(index)，在Lucene中可能不止一個。這是由於在分佈式體系中，ElasticSearch會用到分片(shards)和備份(replicas)機制將一個索引(index)存儲多份。

文檔(Document)

在ElasticSearch的世界中，文檔(Document)是主要的存在實體(在Lucene中也是如此)。全部的ElasticSearch應用需求到最後均可以統一建模成一個檢索模型：檢索相關文檔。文檔(Document)由一個或者多個域(Field)組成，每一個域(Field)由一個域名(此域名非彼域名)和一個或者多個值組成(有多個值的值稱爲多值域(multi-valued))。在ElasticSeach中，每一個文檔(Document)均可能會有不一樣的域(Field)集合；也就是說文檔(Document)是沒有固定的模式和統一的結構。文檔(Document)之間保持結構的類似性便可(Lucene中的文檔(Document)也秉持着相同的規定)。實際上，ElasticSearch中的文檔(Document)就是Lucene中的文檔(Document)。從客戶端的角度來看，文檔(Document)就是一個JSON對象(關於JSON格式的相關信息,請參看hhtp://en.wikipedia.org/wiki/JSON)。

### 參數映射(Mapping)

在  1.1節 認識Apache Lucene  中已經提到，全部的文檔(Document)在存儲以前都必須通過分析(analyze)流程。用戶能夠配置輸入文本分解成Token的方式；哪些Token應該被過濾掉；或者其它的的處理流程，好比去除HTML標籤。此外，ElasticSearch提供的各類特性，好比排序的相關信息。保存上述的配置信息，這就是參數映射(Mapping)在ElasticSearch中扮演的角色。儘管ElasticSearch能夠根據域的值自動識別域的類型(field type)，在生產應用中，都是須要本身配置這些信息以免一些奇的問題發生。要保證應用的可控性。

文檔類型(Type)

每一個文檔在ElasticSearch中都必須設定它的類型。文檔類型使得同一個索引中在存儲結構不一樣文檔時，只須要依據文檔類型就能夠找到對應的參數映射(Mapping)信息，方便文檔的存取。

節點(Node)

單獨一個ElasticSearch服務器實例稱爲一個節點。對於許多應用場景來講，部署一個單節點的ElasticSearch服務器就足夠了。可是考慮到容錯性和數據過載，配置多節點的ElasticSearch集羣是明智的選擇。

集羣(Cluster)

集羣是多個ElasticSearch節點的集合。這些節點齊心合力應對單個節點沒法處理的搜索需求和數據存儲需求。集羣同時也是應對因爲部分機器(節點)運行中斷或者升級致使沒法提供服務這一問題的利器。ElasticSearch提供的集羣各個節點幾乎是無縫鏈接(所謂無縫鏈接，即集羣對外而言是一個總體，增長一個節點或者去掉一個節點對用戶而言是透明的<我的理解，僅供參考>)。在ElasticSearch中配置一個集羣很是簡單，在咱們看來，這是在與同類產品中競爭所體現出的最大優點。

分片索引(Shard)

前面已經提到，集羣可以存儲超出單機容量的信息。爲了實現這種需求，ElasticSearch把數據分發到多個存儲Lucene索引的物理機上。這些Lucene索引稱爲分片索引，這個分發的過程稱爲索引分片(Sharding)。在ElasticSearch集羣中，索引分片(Sharding)是自動完成的，並且全部分片索引(Shard)是做爲一個總體呈現給用戶的。須要注意的是，儘管索引分片這個過程是自動的，可是在應用中須要事先調整好參數。由於集羣中分片的數量須要在索引建立前配置好，並且服務器啓動後是沒法修改的，至少目前沒法修改。

索引副本(Replica)

經過索引分片機制(Sharding)能夠向ElasticSearch集羣中導入超過單機容量的數據，客戶端操做任意一個節點便可實現對集羣數據的讀寫操做。當集羣負載增加，用戶搜索請求阻塞在單個節點上時，經過索引副本(Replica)機制就能夠解決這個問題。索引副本(Replica)機制的的思路很簡單：爲索引分片建立一份新的拷貝，它能夠像原來的主分片同樣處理用戶搜索請求。同時也順便保證了數據的安全性。即若是主分片數據丟失，ElasticSearch經過索引副本使得數據不丟失。索引副本能夠隨時添加或者刪除，因此用戶能夠在須要的時候動態調整其數量。

時間之門(Gateway)

在運行的過程當中，ElasticSearch會收集集羣的狀態、索引的參數等信息。這些數據被存儲在Gateway中。