Elasticsearch學習上手（二）

在安裝elasticsearch以後，咱們就要開始進行操做實踐，那麼在實踐以前，咱們首先了解下elasticsearch的幾個概念

面向文檔

相對關係型數據庫，是採用行和列的形式進行存儲數據，elasticsearch是面向文檔的，意味着它存儲整個對象或文檔。Elasticsearch 不只存儲文檔，並且 索引 每一個文檔的內容使之能夠被檢索。在 Elasticsearch 中，你對文檔進行索引、檢索、排序和過濾--而不是對行列數據。這是一種徹底不一樣的思考數據的方式，也是 Elasticsearch 能支持複雜全文檢索的緣由。
Elasticsearch 使用 JavaScript Object Notation 或者 JSON 做爲文檔的序列化格式。JSON 序列化被大多數編程語言所支持，而且已經成爲 NoSQL 領域的標準格式。 它簡單、簡潔、易於閱讀。

集羣（cluster）

一個集羣就是由一個或多個節點組織在一塊兒，它們共同持有你整個的數據，並一塊兒提供索引和搜索功能。一個集羣由一個惟一的名字標識，這個名字默認就是「elasticsearch」。這個名字是重要的，由於一個節點只能經過指定某個集羣的名字，來加入這個集羣。在產品環境中顯式地設定這個名字是一個好習慣，可是使用默認值來進行測試/開發也是不錯的。

節點（node）

一個節點是你集羣中的一個服務器，做爲集羣的一部分，它存儲你的數據，參與集羣的索引和搜索功能。和集羣相似，一個節點也是由一個名字來標識的，默認狀況下，這個名字是一個隨機的漫威漫畫角色的名字，這個名字會在啓動的時候賦予節點。這個名字對於管理工做來講挺重要的，由於在這個管理過程當中，你會去肯定網絡中的哪些服務器對應於Elasticsearch集羣中的哪些節點。
一個節點能夠經過配置集羣名稱的方式來加入一個指定的集羣。默認狀況下，每一個節點都會被安排加入到一個叫作「elasticsearch」的集羣中，這意味着，若是你在你的網絡中啓動了若干個節點，並假定它們可以相互發現彼此，它們將會自動地造成並加入到一個叫作「elasticsearch」的集羣中。

ps:固然你能夠經過修改配置文件中node.name自行定義節點名稱

分片和複製（shards & replicas）

一個索引能夠存儲超出單個結點硬件限制的大量數據。好比，一個具備10億文檔的索引佔據1TB的磁盤空間，而任一節點都沒有這樣大的磁盤空間；或者單個節點處理搜索請求，響應太慢。

爲了解決這個問題，Elasticsearch提供了將索引劃分紅多份的能力，這些份就叫作分片。當你建立一個索引的時候，你能夠指定你想要的分片的數量。每一個分片自己也是一個功能完善而且獨立的「索引」，這個「索引」能夠被放置到集羣中的任何節點上。
分片之因此重要，主要有兩方面的緣由：

• 容許你水平分割/擴展你的內容容量

• 容許你在分片（潛在地，位於多個節點上）之上進行分佈式的、並行的操做，進而提升性能/吞吐量

  至於一個分片怎樣分佈，它的文檔怎樣聚合回搜索請求，是徹底由Elasticsearch管理的，對於做爲用戶的你來講，這些都是透明的。

  在一個網絡/雲的環境裏，失敗隨時均可能發生，在某個分片/節點不知怎麼的就處於離線狀態，或者因爲任何緣由消失了，這種狀況下，有一個故障轉移機制是很是有用而且是強烈推薦的。爲此目的，Elasticsearch容許你建立分片的一份或多份拷貝，這些拷貝叫作複製分片，或者直接叫複製。

  複製之因此重要，有兩個主要緣由：

• 在分片/節點失敗的狀況下，提供了高可用性。由於這個緣由，注意到複製分片從不與原/主要（original/primary）分片置於同一節點上是很是重要的。

• 擴展你的搜索量/吞吐量，由於搜索能夠在全部的複製上並行運行

  總之，每一個索引能夠被分紅多個分片。一個索引也能夠被複制0次（意思是沒有複製）或屢次。一旦複製了，每一個索引就有了主分片（做爲複製源的原來的分片）和複製分片（主分片的拷貝）之別。分片和複製的數量能夠在索引建立的時候指定。在索引建立以後，你能夠在任什麼時候候動態地改變複製的數量，可是你過後不能改變分片的數量。

  默認狀況下，Elasticsearch中的每一個索引被分片5個主分片和1個複製，這意味着，若是你的集羣中至少有兩個節點，你的索引將會有5個主分片和另外5個複製分片（1個徹底拷貝），這樣的話每一個索引總共就有10個分片。

索引（_index）

一個 索引應該是因共同的特性被分組到一塊兒的文檔集合。通常來講，對比關係型數據庫，至關於SQL的數據庫或者schema。經過索引對文檔的進行建立、查詢、修改和刪除等操做。須要注意的是，索引的名稱必須全爲小寫字符。

類型（_type）

類型是索引內部的邏輯分區(category/partition)，然而其意義徹底取決於用戶需求。通常來講，類型就是爲那些擁有相同的域的文檔作的預約義。對比關係型數據庫，對應的是「表」。

_id

ID 是一個字符串，當它和 _index以及 _type組合就能夠惟一肯定Elasticsearch 中的一個文檔。 當你建立一個新的文檔，要麼提供本身的 _id，要麼讓 Elasticsearch 幫你生成。

若是你的文檔有一個天然的標識符 （例如，一個 user_account
 字段或其餘標識文檔的值），你應該使用以下方式的 index API 並提供你本身 _id

PUT /{index}/{type}/{id}
{ "field": "value", ...}

若是你的數據沒有天然的 ID， Elasticsearch 能夠幫咱們自動生成 ID 。請求的結構調整爲： 再也不使用PUT請求(「使用這個 URL 存儲這個文檔」)， 而是使用 POST請求(「存儲文檔在這個 URL 命名空間下」)。
如今該 URL 只需包含 _index 和 _type

POST /{index}/{type}
{ "field": "value", ...}

 
參考：
https://www.elastic.co/guide/...
http://blog.csdn.net/cnweike/...
http://www.cnblogs.com/ajianb...