基本概念
Elasticsearch 有幾個核心概念。從一開始理解這些概念會對整個學習過程有莫大的幫助。
接近實時（NRT）
Elasticsearch 是一個接近實時的搜索平臺。這意味着，從索引一個文檔直到這個文檔能夠被搜索到有一個輕微的延遲（通常是1 秒）。
集羣（cluster）
一個集羣就是由一個或多個節點組織在一起，它們共同持有你整個的數據，並一起提供索引和搜索功能。一個集羣由一個唯一的名字標識，這個名字默認就是“elasticsearch”。這個名字是重要的，因爲一個節點只能通過指定某個集羣的名字，來加入這個集羣。在產品環境中顯式地設定這個名字是一個好習慣，但是使用默認值來進行測試/開發也是不錯的。
可以通過GET /_cluster/health獲取集羣健康狀況，它有紅、黃、綠三種狀態之分。
節點（node）
一個節點是你集羣中的一個服務器，作爲集羣的一部分，它存儲你的數據，參與集羣的索引和搜索功能。和集羣類似，一個節點也是由一個名字來標識的，默認情況下，這個名字是一個隨機的漫威漫畫角色的名字，這個名字會在啓動的時候賦予節點。這個名字對於管理工作來說挺重要的，因爲在這個管理過程中，你會去確定網絡中的哪些服務器對應於Elasticsearch 集羣中的哪些節點。
一個節點可以通過配置集羣名稱的方式來加入一個指定的集羣。默認情況下，每個節點都會被安排加入到一個叫做“elasticsearch”的集羣中，這意味着，如果你在你的網絡中啓動了若干個節點，並假定它們能夠相互發現彼此，它們將會自動地形成並加入到一個叫做“elasticsearch”的集羣中。在一個集羣裏，只要你想，可以擁有任意多個節點。而且，如果當前你的網絡中沒有運行任何Elasticsearch 節點， 這時啓動一個節點， 會默認創建並加入一個叫做“elasticsearch”的集羣。
節點是Elasticsearch運行中的實例，而 集羣 則包含一個或多個具有相同 cluster.name 的節點，它們協同工作，共享數據，並共同分擔工作負荷。由於節點是從屬集羣的，集羣會自我重組來均勻地分發數據。集羣中的一個節點會被選爲master節點，它將負責管理集羣範疇的變更，例如創建或刪除索引，添加節點到集羣或從集羣刪除節點。master節點無需參與文檔層面的變更和搜索，這意味着僅有一個master節點並不會因流量增長而成爲瓶頸。任意一個節點都可以成爲master節點。我們例舉的集羣只有一個節點，因此它會扮演master節點的角色。
作爲用戶，我們可以訪問包括master節點在內的集羣中的任一節點。每個節點都知道各個文檔的位置，並能夠將我們的請求直接轉發到擁有我們想要的數據的節點。無論我們訪問的是哪個節點，它都會控制從擁有數據的節點收集響應的過程，並返回給客戶端最終的結果。這一切都是由Elasticsearch透明管理的。
索引（index）
一個索引就是一個擁有幾分相似特徵的文檔的集合。比如說，你可以有一個客戶數據的索引，另一個產品目錄的索引，還有一個訂單數據的索引。一個索引由一個名字來標識（必須全部是小寫字母的），並且當我們要對對應於這個索引中的文檔進行索引、搜索、更新和刪除的時候，都要使用到這個名字。在一個集羣中，如果你想，可以定義任意多的索引。
在Elasticsearch中，我們的數據都在分片中被存儲以及索引，索引只是一個邏輯命名空間，它可以將一個或多個分片組合在一起。然而，這只是一個內
部的運作原理，我們的程序可以根本不用關心分片。對於我們的程序來說，我們的文檔存儲在索引中。剩下的交給Elasticsearch就可以了。
索引名稱必須要全部小寫，也不能以下劃線開頭，不能包含逗號。
類型（type）
在一個索引中，你可以定義一種或多種類型。一個類型是你的索引的一個邏輯上的分類/分區，其語義完全由你來定。通常，會爲具有一組共同字段的文檔定義一個類型。比如說，我們假設你運營一個博客平臺並且將你所有的數據存儲到一個索引中。在這個索引中，你可以爲用戶數據定義一個類型，爲博客數據定義另一個類型，當然，也可以爲評論數據定義另一個類型。
每一個類型都擁有自己的映射(mapping)或者結構定義，它們定義了當前類型下的數據結構，類似於數據庫表中的列。所有類型下的文檔會被存儲在同一個索引下，但是映射會告訴Elasticsearch不同的數據應該如何被索引。
劃分時需要注意一些限制條件，例如不同的文檔類型對同一字段不能設置爲不同的字段類型。
一個文檔是一個可被索引的基礎信息單元。比如，你可以擁有某一個客戶的文檔，某一個產品的一個文檔，當然，也可以擁有某個訂單的一個文檔。文檔以JSON（JavascriptObject Notation）格式來表示，而JSON 是一個到處存在的互聯網數據交互格式。在一個index/type 裏面，只要你想，你可以存儲任意多的文檔。注意，儘管一個文檔，物理上存在於一個索引之中，文檔必須被索引/賦予一個索引的type。
與關係型數據庫不同，ES的文檔不需要有固定的結構，不同文檔可以具有不同的字段集合，而且在程序開發時不需要知道文檔的字段。當然用戶可以通過模式映射(schema mapping)定義文檔結構。
在Elasticsearch中，文檔這個單詞有特殊的含義。它指的是在Elasticsearch中被存儲到唯一ID下的由最高級或者根對象 (rootobject )序列化而來的JSON。
一個文檔不只包含了數據。它還包含了元數據(metadata) —— 關於文檔的信息。有三個元數據元素是必須存在的，它們是：
id是一個字符串，當它與 _index 以及 _type 組合時，就可以來代表Elasticsearch中一個特定的文檔。
一個索引可以存儲超出單個結點硬件限制的大量數據。比如，一個具有10 億文檔的索引佔據1TB 的磁盤空間，而任一節點都沒有這樣大的磁盤空間；或者單個節點的計算能力達不到期望的複雜功能的要求。這種情況下，可以將數據切分，每部分是一個單獨的apache lucene索引，稱爲分片。每個分片可以被存儲在集羣的不同節點上。
爲了解決這個問題，Elasticsearch 提供了將索引劃分成多份的能力，這些份就叫做分片。當你創建一個索引的時候，你可以指定你想要的分片的數量。每個分片本身也是一個功能完善並且獨立的“索引”，這個“索引”可以被放置到集羣中的任何節點上。
分片之所以重要，主要有兩方面的原因：
- 允許你水平分割/擴展你的內容容量
- 允許你在分片（潛在地，位於多個節點上）之上進行分佈式的、並行的操作，進而提高性能/吞吐量
至於一個分片怎樣分佈，它的文檔怎樣聚合回搜索請求，是完全由Elasticsearch 管理的，對於作爲用戶的你來說，這些都是透明的。
在一個網絡/雲的環境裏，失敗隨時都可能發生，在某個分片/節點不知怎麼的就處於離線狀態，或者由於任何原因消失了，這種情況下，有一個故障轉移機制是非常有用並且是強烈推薦的。爲此目的，Elasticsearch 允許你創建分片的一份或多份拷貝，這些拷貝叫做複製分片，或者直接叫複製。複製之所以重要，有兩個主要原因：[高可用與高吞吐]
- 在分片/節點失敗的情況下，提供了高可用性。因爲這個原因，注意到複製分片從不與原/主要（original/primary）分片置於同一節點上是非常重要的。
- 擴展你的搜索量/吞吐量，因爲搜索可以在所有的複製上並行運行
總之，每個索引可以被分成多個分片。一個索引也可以被複制0 次（意思是沒有複製）或多次。一旦複製了，每個索引就有了主分片（作爲複製源的原來的分片）和複製分片（主分片的拷貝）之別。分片和複製的數量可以在索引創建的時候指定。在索引創建之後，你可以在任何時候動態地改變複製的數量，但是你事後不能改變分片的數量。
默認情況下，Elasticsearch 中的每個索引被分片5 個主分片和1 個複製，這意味着，如果你的集羣中至少有兩個節點，你的索引將會有5 個主分片和另外5 個複製分片（1 個完全拷貝），這樣的話每個索引總共就有10 個分片。
與關係數據庫對照關係
與傳統的關係型數據庫有一些大致的相似之處：
關係數據庫 ⇒ 數據庫 ⇒ 表 ⇒ 行 ⇒ 列(Columns)
Elasticsearch ⇒ 索引 ⇒ 類型 ⇒ 文檔 ⇒ 字段(Fields)
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
DB -> Databases -> Tables -> Rows -> Columns
ES -> Indices -> Types -> Documents -> Fields
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
River
代表es的一個數據源，也是其它存儲方式（如：數據庫）同步數據到es的一個方法。它是以插件方式存在的一個es服務，通過讀取river中的數據並把它索引到es中，官方的river有couchDB的，RabbitMQ的，Twitter的，Wikipedia的。
Gateway
代表es索引的持久化存儲方式，es默認是先把索引存放到內存中，當內存滿了時再持久化到硬盤。當這個es集羣關閉再重新啓動時就會從gateway中讀取索引數據。es支持多種類型的gateway，有本地文件系統（默認），分佈式文件系統，Hadoop的HDFS和amazon的s3雲存儲服務。
discovery.zen
代表es的自動發現節點機制，es是一個基於p2p的系統，它先通過廣播尋找存在的節點，再通過多播協議來進行節點之間的通信，同時也支持點對點的交互。
Transport
代表es內部節點或集羣與客戶端的交互方式，默認內部是使用tcp協議（9300端口）進行交互，同時它支持http協議（json格式）（9200端口）、thrift、servlet、memcached、zeroMQ等的傳輸協議（通過插件方式集成）。