ElasticSearch 入門教程 一（體系結構）

全文檢索的介紹

全文檢索的需求介紹

首先我們談幾個公司，如雷貫耳的：百度、谷歌、維基百科；這些公司都有一個相似性就是門戶網站，可以提供我們通過關鍵字搜索，然後快速的檢索出我們想要的信息；
【網頁百度展示】
比如我們檢索關鍵詞，百度後臺就會按照這個關鍵字進行查找（裏面有搜索庫，以及爬蟲庫），然後按照權重來進行從上到下的排序，給我們高亮的展示出現。
【京東或者淘寶展示】
隨便搜索東西，就會高精度的展示我們想要的；就會根據關鍵詞進行海量數據的快速的檢索。
比如我們查找：”護手霜“ ， 那麼這期間內部會經過大體的：1、分詞（護手，手霜，護等）2、根據這些詞去海量的數據中檢索 3、然後根據權重把檢索出來的信息進行排序展示給我們。
【傳統做法】
那麼對於一般的公司，初期是沒有那麼多數據的，所以很多公司更傾向於使用傳統的數據庫：mysql；比如我們要查找關鍵字”大數據“，那麼查詢的方式大概就是:select * from table where field like ‘%大數據%’; 但是隨着業務發展，數據會不斷的膨脹，那麼問題就來了；mysql單表查詢能力即便經過了優化，它的極限也就是400W左右的數據量。而且還會經常出現查詢超時的現象；
然後很多公司開始對數據庫進行橫向和縱向的擴容，開始進行數據庫表的“拆分”：橫向拆分和縱向拆分；但是即便這樣操作，仍然會出現很多問題，比如：

1、數據庫會出現單點故障問題，於是先天主從複製關係，於是增加了運維成本。
2、因爲對錶的拆分，增加了後期維護的難度，同樣也是增加了運維成本。
3、即便做了大量的維護，但對於大數據的檢索操作，依然很慢，完全達不到期望值。

於是出現了lucene，全文檢索的工具。但是lucene對外暴露出的可用接口對於開發人員來說，操作是非常的複雜，而且沒有效率的；於是在lucene的基礎上進一步的封裝，有了一個叫做solr的高性能分佈式檢索服務框架，但是，solr有一個致命的缺點就是：在建立索引期間，solr的搜索能力會極度下降，這就在一定程度上造成了solr在實時索引上效率並不高；
最後，出現了一個叫做elasticsearch的框架，同樣是以lucene爲基礎，並且吸收了前兩代的教訓而開發出的分佈式多用戶能力的全文搜索引擎，並且elasticsearch是基於RESTful web接口RESTful web接口進行發佈的，那麼這就意味着，我們開發人員操作起來更方便快捷；同時es拓展節點方便，可用於存儲和檢索海量數據，接近實時搜索能力，自動發現節點、副本機制保障可用性。

非結構化數據查找方法

1：順序掃描法(Serial Scanning)
所謂順序掃描，比如要找內容包含某一個字符串的文件，就是一個文檔一個文檔的看，對於每一個文檔，從頭看到尾，如果此文檔包含此字符串，則此文檔爲我們要找的文件，接着看下一個文件，直到掃描完所有的文件。如利用windows的搜索也可以搜索文件內容，只是相當的慢。
2：全文檢索(Full-text Search)
將非結構化數據中的一部分信息提取出來，重新組織，使其變得有一定結構，然後對此有一定結構的數據進行搜索，從而達到搜索相對較快的目的。這部分從非結構化數據中提取出的然後重新組織的信息，我們稱之索引。
例如：字典。字典的拼音表和部首檢字表就相當於字典的索引，對每一個字的解釋是非結構化的，如果字典沒有音節表和部首檢字表，在茫茫辭海中找一個字只能順序掃描。然而字的某些信息可以提取出來進行結構化處理，比如讀音，就比較結構化，分聲母和韻母，分別只有幾種可以一一列舉，於是將讀音拿出來按一定的順序排列，每一項讀音都指向此字的詳細解釋的頁數。我們搜索時按結構化的拼音搜到讀音，然後按其指向的頁數，便可找到我們的非結構化數據——也即對字的解釋。
這種先建立索引，再對索引進行搜索的過程就叫全文檢索(Full-text Search)。
雖然創建索引的過程也是非常耗時的，但是索引一旦創建就可以多次使用，全文檢索主要處理的是查詢，所以耗時間創建索引是值得的。
3、如何實現全文檢索
可以使用Lucene實現全文檢索。Lucene是apache下的一個開放源代碼的全文檢索引擎工具包（提供了Jar包，實現全文檢索的類庫）。它提供了完整的查詢引擎和索引引擎，部分文本分析引擎。Lucene的目的是爲軟件開發人員提供一個簡單易用的工具包，以方便地在目標系統中實現全文檢索的功能。
注意：Lucene只是一個引擎，只是一個工具包，如果使用Lucene開發全文檢索功能，要記住Lucene是不能單獨運行的。

lucene實現全文檢索流程

1. 綠色表示索引過程，對要搜索的原始內容進行索引構建一個索引庫，索引過程包括：確定原始內容即要搜索的內容→採集文檔→創建文檔→分析文檔→索引文檔。
2. 紅色表示搜索過程，從索引庫中搜索內容，搜索過程包括：用戶通過搜索界面→創建查詢→執行搜索，從索引庫搜索→渲染搜索結果。
   從上面瞭解到的知識點也可看出，索引和搜索流程圖也可表示爲：
   
   總結：全文檢索過程分爲索引、搜索兩個過程：

索引

1. 從關係數據庫中、互聯網上、文件系統採集源數據(要搜索的目標信息)，源數據的來源是很廣泛的。
2. 將源數據採集到一個統一的地方，要創建索引，將索引創建到一個索引庫（文件系統）中，從源數據庫中提取關鍵信息，從關鍵信息中抽取一個一個詞，詞和源數據是有關聯的。也即創建索引時，詞和源數據有關聯，索引庫中記錄了這個關聯，如果找到了詞就說明找到了源數據（http的網頁、pdf電子書等……）。

搜索

1. 用戶執行搜索（全文檢索）編寫查詢關鍵字。
2. 從索引庫中搜索索引，根據查詢關鍵字搜索索引庫中的一個一個詞。
3. 展示搜索的結果。

全文檢索框架介紹

市面上全文檢索的框架很多，較早期的一個框架就是lucene，基本上所有的全文檢索的工作都交給lucene來實現，但是lucene最大的弊端就是API太原生，沒有經過任何封裝，不太好使用。所以後來出現一個叫做solr的框架，它也是基於lucene進行改造封裝和包裝，將服務端單獨提取出來，客戶端進行請求即可。
另外一個框架就是大名鼎鼎的elasticsearch了，es也是一個基於lucene打造的全文檢索的框架，且一經推出就迅速被市場認可，市場佔有率越來越多，現在首選的全文檢索的框架基本就是ES了。

Elasticsearch介紹

Elaticsearch，簡稱爲es， es是一個開源的高擴展的分佈式全文檢索引擎，它可以近乎實時的存儲、檢索數據；本身擴展性很好，可以擴展到上百臺服務器，處理PB級別的數據。es也使用Java開發並使用Lucene作爲其核心來實現所有索引和搜索的功能，但是它的目的是通過簡單的RESTful API來隱藏Lucene的複雜性，從而讓全文搜索變得簡單。

ElasticSearch使用案例

• 2013年初，GitHub拋棄了Solr，採取ElasticSearch 來做PB級的搜索。 “GitHub使用ElasticSearch搜索20TB的數據，包括13億文件和1300億行代碼”
• 維基百科：啓動以elasticsearch爲基礎的核心搜索架構
• SoundCloud：“SoundCloud使用ElasticSearch爲1.8億用戶提供即時而精準的音樂搜索服務”
• 百度：百度目前廣泛使用ElasticSearch作爲文本數據分析，採集百度所有服務器上的各類指標數據及用戶自定義數據，通過對各種數據進行多維分析展示，輔助定位分析實例異常或業務層面異常。目前覆蓋百度內部20多個業務線（包括casio、雲分析、網盟、預測、文庫、直達號、錢包、風控等），單集羣最大100臺機器，200個ES節點，每天導入30TB+數據
• 新浪使用ES 分析處理32億條實時日誌
• 阿里使用ES 構建挖財自己的日誌採集和分析體系

ElasticSearch對比Solr

• Solr 利用 Zookeeper 進行分佈式管理，而 Elasticsearch 自身帶有分佈式協調管理功能;
• Solr 支持更多格式的數據，而 Elasticsearch 僅支持json文件格式；
• Solr 官方提供的功能更多，而 Elasticsearch 本身更注重於核心功能，高級功能多有第三方插件提供；
• Solr 在傳統的搜索應用中表現好於 Elasticsearch，但在處理實時搜索應用時效率明顯低於 Elasticsearch

ElasticSearch架構圖以及基本概念(術語)

es概述

Elasticsearch是面向文檔(document oriented)的，這意味着它可以存儲整個對象或文檔(document)。然而它不僅僅是存儲，還會索引(index)每個文檔的內容使之可以被搜索。在Elasticsearch中，你可以對文檔（而非成行成列的數據）進行索引、搜索、排序、過濾。
Elasticsearch比傳統關係型數據庫如下：
Relational DB -> Databases -> Tables -> Rows -> Columns
Elasticsearch -> Indices -> Types -> Documents -> Fields

ES架構模塊

Gateway是ES用來存儲索引的文件系統，支持多種類型。
Gateway的上層是一個分佈式的lucene框架。
Lucene之上是ES的模塊，包括：索引模塊、搜索模塊、映射解析模塊等
ES模塊之上是 Discovery、Scripting和第三方插件。
Discovery是ES的節點發現模塊，不同機器上的ES節點要組成集羣需要進行消息通信，集羣內部需要選舉master節點，這些工作都是由Discovery模塊完成。支持多種發現機制，如 Zen 、EC2、gce、Azure。
Scripting用來支持在查詢語句中插入javascript、python等腳本語言，scripting模塊負責解析這些腳本，使用腳本語句性能稍低。ES也支持多種第三方插件。
再上層是ES的傳輸模塊和JMX.傳輸模塊支持多種傳輸協議，如 Thrift、memecached、http，默認使用http。JMX是java的管理框架，用來管理ES應用。
最上層是ES提供給用戶的接口，可以通過RESTful接口和ES集羣進行交互。

Elasticsearch核心概念

1、索引 index
一個索引就是一個擁有幾分相似特徵的文檔的集合。比如說，你可以有一個客戶數據的索引，另一個產品目錄的索引，還有一個訂單數據的索引。一個索引由一個名字來標識（必須全部是小寫字母的），並且當我們要對對應於這個索引中的文檔進行索引、搜索、更新和刪除的時候，都要使用到這個名字。在一個集羣中，可以定義任意多的索引。
2、類型 type
在一個索引中，你可以定義一種或多種類型。一個類型是你的索引的一個邏輯上的分類/分區，其語義完全由你來定。通常，會爲具有一組共同字段的文檔定義一個類型。比如說，我們假設你運營一個博客平臺並且將你所有的數據存儲到一個索引中。在這個索引中，你可以爲用戶數據定義一個類型，爲博客數據定義另一個類型，當然，也可以爲評論數據定義另一個類型。
3、字段Field
相當於是數據表的字段，對文檔數據根據不同屬性進行的分類標識
4、映射 mapping
mapping是處理數據的方式和規則方面做一些限制，如某個字段的數據類型、默認值、分析器、是否被索引等等，這些都是映射裏面可以設置的，其它就是處理es裏面數據的一些使用規則設置也叫做映射，按着最優規則處理數據對性能提高很大，因此才需要建立映射，並且需要思考如何建立映射才能對性能更好。
5、文檔 document
一個文檔是一個可被索引的基礎信息單元。比如，你可以擁有某一個客戶的文檔，某一個產品的一個文檔，當然，也可以擁有某個訂單的一個文檔。文檔以JSON（Javascript Object Notation）格式來表示，而JSON是一個到處存在的互聯網數據交互格式。
在一個index/type裏面，你可以存儲任意多的文檔。注意，儘管一個文檔，物理上存在於一個索引之中，文檔必須被索引/賦予一個索引的type。
6、集羣 cluster
一個集羣就是由一個或多個節點組織在一起，它們共同持有整個的數據，並一起提供索引和搜索功能。一個集羣由一個唯一的名字標識，這個名字默認就是“elasticsearch”。這個名字是重要的，因爲一個節點只能通過指定某個集羣的名字，來加入這個集羣
7、節點 node
一個節點是集羣中的一個服務器，作爲集羣的一部分，它存儲數據，參與集羣的索引和搜索功能。和集羣類似，一個節點也是由一個名字來標識的，默認情況下，這個名字是一個隨機的漫威漫畫角色的名字，這個名字會在啓動的時候賦予節點。這個名字對於管理工作來說挺重要的，因爲在這個管理過程中，你會去確定網絡中的哪些服務器對應於Elasticsearch集羣中的哪些節點。
一個節點可以通過配置集羣名稱的方式來加入一個指定的集羣。默認情況下，每個節點都會被安排加入到一個叫做“elasticsearch”的集羣中，這意味着，如果你在你的網絡中啓動了若干個節點，並假定它們能夠相互發現彼此，它們將會自動地形成並加入到一個叫做“elasticsearch”的集羣中。
在一個集羣裏，只要你想，可以擁有任意多個節點。而且，如果當前你的網絡中沒有運行任何Elasticsearch節點，這時啓動一個節點，會默認創建並加入一個叫做“elasticsearch”的集羣。
8、分片和複製 shards&replicas
一個索引可以存儲超出單個結點硬件限制的大量數據。比如，一個具有10億文檔的索引佔據1TB的磁盤空間，而任一節點都沒有這樣大的磁盤空間；或者單個節點處理搜索請求，響應太慢。爲了解決這個問題，Elasticsearch提供了將索引劃分成多份的能力，這些份就叫做分片。當你創建一個索引的時候，你可以指定你想要的分片的數量。每個分片本身也是一個功能完善並且獨立的“索引”，這個“索引”可以被放置到集羣中的任何節點上。分片很重要，主要有兩方面的原因： 1）允許你水平分割/擴展你的內容容量。 2）允許你在分片（潛在地，位於多個節點上）之上進行分佈式的、並行的操作，進而提高性能/吞吐量。
至於一個分片怎樣分佈，它的文檔怎樣聚合回搜索請求，是完全由Elasticsearch管理的，對於作爲用戶的你來說，這些都是透明的。
在一個網絡/雲的環境裏，失敗隨時都可能發生，在某個分片/節點不知怎麼的就處於離線狀態，或者由於任何原因消失了，這種情況下，有一個故障轉移機制是非常有用並且是強烈推薦的。爲此目的，Elasticsearch允許你創建分片的一份或多份拷貝，這些拷貝叫做複製分片，或者直接叫複製。
複製之所以重要，有兩個主要原因： 在分片/節點失敗的情況下，提供了高可用性。因爲這個原因，注意到複製分片從不與原/主要（original/primary）分片置於同一節點上是非常重要的。擴展你的搜索量/吞吐量，因爲搜索可以在所有的複製上並行運行。總之，每個索引可以被分成多個分片。一個索引也可以被複制0次（意思是沒有複製）或多次。一旦複製了，每個索引就有了主分片（作爲複製源的原來的分片）和複製分片（主分片的拷貝）之別。分片和複製的數量可以在索引創建的時候指定。在索引創建之後，你可以在任何時候動態地改變複製的數量，但是你事後不能改變分片的數量。
默認情況下，Elasticsearch中的每個索引被分片5個主分片和1個複製，這意味着，如果你的集羣中至少有兩個節點，你的索引將會有5個主分片和另外5個複製分片（1個完全拷貝），這樣的話每個索引總共就有10個分片。