es

一、爲何要用es

咱們的要求：（1）搜索解決方案要快（2）最好是有一個零配置和一個徹底免費的搜索模式（3）咱們但願可以簡單地使用JSON/XML經過HTTP的索引數據

（4）咱們但願咱們的搜索服務器始終可用，並可以從一臺開始並在須要擴容時方便地擴展到數百（5）咱們要實時搜索，咱們要簡單的多租戶，咱們但願創建一個雲的解決方案

二、es的優勢（lucene的缺點es都已解決）

　　Lucene能夠被認爲是迄今爲止最早進、性能最好的、功能最全的搜索引擎庫。可是，Lucene只是一個庫，使用很是複雜。

　　lucene缺點：

  　　 1）只能在JAVA項目中使用,而且要以jar包的方式直接集成項目中.

   　　2）配置及使用很是複雜-建立索引和搜索索引代碼多

　　   3）不支持集羣環境-索引數據不一樣步（不支持大型項目）

　　   4）索引數據若是太多就不行。索引庫和應用所在同一個服務器,共同佔用硬盤.共用空間少.

三、es解決了lucene的那些缺點：

　　（1） 優化Lucene的調用方式，經過簡單的 RESTful API來隱藏Lucene的複雜性（調用簡單）

 　（2）並實現了高可用的分佈式集羣的搜索方案（高可用，分佈式）

　　（3）分佈式的實時分析搜索引擎（實時）

　　（4）能夠擴展到上百臺服務器，處理PB級結構化或非結構化數據（擴展性好）

　　（5）高度集成化的服務，支持各類語言

 

四、相似框架

①Solr（重量級對手） /SolrJ

　　Apache Lucene項目的開源企業搜索平臺。其主要功能包括全文檢索、命中標示、分面搜索、動態聚類、數據庫集成，以及富文本（如Word、PDF）的處理。Solr是高度可擴展的，並提供了分佈式搜索和索引複製。Solr是最流行的企業級搜索引擎，SolrJ 還增長了NoSQL支持。

　　Solr和ES比較：

Solr 利用 Zookeeper 進行分佈式管理，支持更多格式的數據（HTML/PDF/CSV），官方提供的功能更多在傳統的搜索應用中表現好於 ES，但實時搜索效率低。

 ES自身帶有分佈式協調管理功能，但僅支持json文件格式，自己更注重於核心功能，高級功能多有第三方插件提供，在處理實時搜索應用時效率明顯高於 Solr。

② Katta

　　基於 Lucene 的，支持分佈式，可擴展，具備容錯功能，準實時的搜索方案。

　　優勢：開箱即用，能夠與 Hadoop 配合實現分佈式。具有擴展和容錯機制。

　　缺點：只是搜索方案，建索引部分仍是須要本身實現。在搜索功能上，只實現了最基本的需求。成功案例較少，項目的成熟度稍微差一些。

③ HadoopContrib

　　Map/Reduce 模式的，分佈式建索引方案，能夠跟 Katta 配合使用。

　　優勢：分佈式建索引，具有可擴展性。

　　缺點：只是建索引方案，不包括搜索實現。工做在批處理模式，對實時搜索的支持不佳。

五、傳統數據庫和ES的對應關係：

　　關係數據庫（MYSQL） -> 數據庫DB-> 表TABLE-> 行ROW-> 列Column

 

　　Elasticsearch -> 索引庫Indices -> 類型Types -> 文檔Documents -> 字段Fields

六、es支持的字段類型

　　① 基本字段類型

　　字符串（String）：text,keyword

       　　 text默認爲全文文本，keyword默認爲非全文文本

　　數字：long,integer,short,double,float

　　日期：date

　　邏輯：boolean

　　② 複雜數據類型

　　對象類型：object

　　數組類型：array

　　地理位置：geo_point,geo_shape

七、Bulk（批量操做）一次最大處理多少數據量？

bulk會把將要處理的數據載入內存中，因此數據量是有限制的

最佳的數據量不是一個肯定的數值，它取決於你的硬件，你的文檔大小以及複雜性，你的索引以及搜索的負載。

通常建議是1000-5000個文檔，若是你的文檔很大，能夠適當減小隊列,大小建議是5-15MB，默認不能超過100M

，能夠在es的配置文件中修改這個值http.max_content_length: 100mb.     

八、ES在高併發的狀況下如何保證數據線程安全問題？

在讀數據與寫數據之間若是有其餘線程進行寫操做，就會出問題，es使用版本控制才避免這種問題。

 

在修改數據的時候指定版本號，操做一次版本號加1。

 

九、ES自動映射的規則

　　字段映射的經常使用屬性配置列表

type	類型：基本數據類型，integer,long,date,boolean,keyword,text...
enable	是否啓用：默認爲true。 false：不能索引、不能搜索過濾，僅在_source中存儲
boost	權重提高倍數：用於查詢時加權計算最終的得分。
format	格式：通常用於指定日期格式，如 yyyy-MM-dd HH:mm:ss.SSS
ignore_above	長度限制：長度大於該值的字符串將不會被索引和存儲。
ignore_malformed	轉換錯誤忽略：true表明當格式轉換錯誤時，忽略該值，被忽略後不會被存儲和索引。
include_in_all	是否將該字段值組合到_all中。
null_value	默認控制替換值。如空字符串替換爲」NULL」，空數字替換爲-1
store	是否存儲：默認爲false。true意義不大，由於_source中已有數據
index	索引模式：analyzed (索引並分詞，text默認模式), not_analyzed (索引不分詞，keyword默認模式)，no（不索引）
analyzer	索引分詞器：索引建立時使用的分詞器，如ik_smart,ik_max_word,standard
search_analyzer	搜索分詞器：搜索該字段的值時，傳入的查詢內容的分詞器。
fields	多字段索引：當對該字段須要使用多種索引模式時使用。 如：城市搜索New York "city": {      "type": "text",      "analyzer": "ik_smart",      "fields": {             "raw": {                 "type":  "keyword"              }      } }   訪問分詞:city 訪問不分詞:city.raw 那麼之後搜索過濾和排序就可使用city.raw字段名

十、es如何保證高可用（對失敗節點的數據進行複製）

1. 對於分佈式集羣來講，當一個或多個節點down掉了，可以保證咱們的數據不能丟，最通用的解放方案就是對失敗節點的數據進行複製，經過控制複製的份數能夠保證集羣有很高的可用性，複製這個方案的精髓主要是保證操做的時候沒有單點，對一個節點的操做會同步到其餘的複製節點上去。
2. ES一個索引會拆分紅多個碎片，每一個碎片能夠擁有一個或多個副本（建立索引的時候能夠配置），這裏有個例子，每一個索引分紅3個碎片，每一個碎片有2個副本，以下：

   $ curl -XPUT http://localhost:9200/twitter/ -d ' index : number_of_shards : 3 number_of_replicas : 2

　　　默認是1個分片。不復制

十一、es選舉（和zk差很少，可是es支持1-N，zk的話必須是奇數）

1. 節點啓動後先ping（這裏的ping是 Elasticsearch 的一個RPC命令。若是 discovery.zen.ping.unicast.hosts 有設置，則ping設置中的host，不然嘗試ping localhost 的幾個端口， Elasticsearch 支持同一個主機啓動多個節點）
2. Ping的response會包含該節點的基本信息以及該節點認爲的master節點
3. 選舉開始，先從各節點認爲的master中選，規則很簡單，按照id的字典序排序，取第一個
4. 若是各節點都沒有認爲的master，則從全部節點中選擇，規則同上。這裏有個限制條件就是 discovery.zen.minimum_master_nodes，若是節點數達不到最小值的限制，則循環上述過程，直到節點數足夠能夠開始選舉
5. 最後選舉結果是確定能選舉出一個master，若是隻有一個local節點那就選出的是本身
6. 若是當前節點是master，則開始等待節點數達到 minimum_master_nodes，而後提供服務, 若是當前節點不是master，則嘗試加入master.
7. ES支持任意數目的集羣（1-N）,因此不能像 Zookeeper/Etcd 那樣限制節點必須是奇數，也就沒法用投票的機制來選主，而是經過一個規則，只要全部的節點都遵循一樣的規則，獲得的信息都是對等的，選出來的主節點確定是一致的. 但分佈式系統的問題就出在信息不對等的狀況，這時候很容易出現腦裂（Split-Brain）的問題，大多數解決方案就是設置一個quorum值，要求可用節點必須大於quorum（通常是超過半數節點），才能對外提供服務。而 Elasticsearch 中，這個quorum的配置就是

 十二、es 是如何實現分佈式的?

ElasticSearch 設計的理念就是分佈式搜索引擎，底層其實仍是基於 lucene 的。核心思想就是在多臺機器上啓動多個 es 進程實例，組成了一個 es 集羣。

一個索引，這個索引能夠拆分紅多個 shard，每一個 shard 存儲部分數據

接着就是這個 shard 的數據實際是有多個備份，就是說每一個 shard 都有一個 primary shard，負責寫入數據，可是還有幾個 replica shard。 primary shard 寫入數據以後，會將數據同步到其餘幾個 replica shard 上去。

經過這個 replica 的方案，每一個 shard 的數據都有多個備份，若是某個機器宕機了，不要緊啊，還有別的數據副本在別的機器上呢。高可用了吧。

es 集羣多個節點，會自動選舉一個節點爲 master 節點，這個 master 節點其實就是幹一些管理的工做的，好比維護索引元數據、負責切換 primary shard 和 replica shard 身份等。要是 master 節點宕機了，那麼會從新選舉一個節點爲 master 節點。

若是是非 master節點宕機了，那麼會由 master 節點，讓那個宕機節點上的 primary shard 的身份轉移到其餘機器上的 replica shard。接着你要是修復了那個宕機機器，重啓了以後，master 節點會控制將缺失的 replica shard 分配過去，同步後續修改的數據之類的，讓集羣恢復正常。

若是master 節點宕機了。那麼此節點上的 primary shard 就沒了。master 會讓 primary shard 對應的 replica shard（在其餘機器上）切換爲 primary shard。若是宕機的機器修復了，修復後的節點也再也不是 primary shard，而是 replica shard。

 

原文地址： http://www.javashuo.com/article/p-dapyflum-kv.html