目錄
返回目錄：http://www.cnblogs.com/hanyinglong/p/5464604.html
1.Elasticsearch配置文件詳解
a. 在上面博客中，我們已經安裝並且成功配置了Elasticsearch以及部分插件，接下來我們就需要看看Elasticseach的配置文件的信息以及文檔的一些說明。
b.首先找到Elasticsearch的安裝位置，跳轉到elasticsearch的config文件夾下，在此文件夾下含有兩個配置文件：elasticsearch.yml和logging.yml，第一個是Elasticsearch的基本配置文件，第二個是日志配置文件，Elasticsearch是使用log4j來記錄日志的，所以logging.yml里的設置按普通的log4j配置文件夾來設置即可。下面我們主要來說一下elasticsearch.yml文件中的配置信息。
c.文檔說明采用寫備注的方法來說明elasticsearch.yml文件,Elasticsearch的版本是：2.3.1。
c.1 cluster.name: kencery 配置Elasticsearch的集群名稱，默認是elasticsearch，Elasticsearch會自動發現在同一網段下的es集群，如果在同一個網段下有多個集群，可以利用這個屬性來區分不同的集群。
c.2 node.name : "kencery-node1" 集群的節點名稱，Elasticsearch啟動的時候會自動創建節點名稱，但是你也可以進行配置。
c.3 node.rack: r1 每個節點都可以定義一些與之關聯的通用屬性，用於后期集群進行碎片分配時的過濾。
c.4 path.data: /path/to/data 設置索引數據的存儲路徑，默認是Elasticsearch根目錄下的data文件夾，可以設置多個存儲路徑，用逗號隔開，是的數據在文件級別跨域位置，這樣在創建時就有更多的自由路徑，如：path.data: /path/to/data1,/path/to/data2
c.5 path.logs: /path/to/logs 設置日志文件的存儲路徑，默認是Elasticsearch根目錄下的logs文件夾。
c.6 bootstrap.mlockall: true 設置為true來鎖住內存，因為當JVM開始swapping的時候Elasticsearch的效率會降低，所以要保證他不被swap，可以吧ES_MIN_MEN和ES_MAX_MEN兩個環境變量設置為同一個值，並且保證機器有足夠的內存分配給Elasticsearch，同時也要允許Elasticsearch的進程可以鎖住內存，linux下可以通過`ulimit -l unlimited`命令。
c.7 network.host: 192.168.37.133 設置綁定的IP地址，可以是ipv4或者ipv5，默認使用0.0.0.0地址，並為http傳輸開啟9200、9300端口，為節點到節點的通信開啟9300-9400端口，也可以自行設置IP地址。
c.8 http.port: 9200 設置對外服務的Http端口，默認是9200
c.9 discovery.zen.ping.unicast.hosts: ["192.168.37.133", "192.168.37.137"] 設置集群中master節點的初始化列表，可以通過這些節點來自動發現新加入集群的節點(主要用於不同網段機器連接)。
c.10 discovery.zen.minimum_master_nodes: 3 設置這個參數來保證集群中的節點可以知道其它N個有master資格的節點，默認為1，當集群多余三個節點時，可以設置大一點的值(2-4)
c.11 gateway.recover_after_nodes: 3 設置集群中國N個節點啟動時進行數據恢復，默認是1
c.12 node.max_local_storage_nodes: 1 默認情況下，多個節點可以在同一個安裝路徑啟動，如果你想讓你的Elasticsearch只啟動一個節點，在這合理設置。
c.13 action.destructive_requires_name: true 設置是否可以通過正則或者_all刪除或者關閉索引。
d. 上面所有的節點信息都是在配置文件中存在的，有些節點信息配置文件沒有顯示(不推薦修改)，可以查看這里學習：http://www.zihou.me/html/2014/01/17/9061.html
e. 上面只是簡單描述了一些Elasticsearch配置文件中的信息，詳細配置請看你安裝的Elasticsearch里面的配置文件的信息.
f. 關於Elasticsearch的基礎概念，請參考：http://blog.csdn.net/cnweike/article/details/33736429
2. 數據對象處理
a. 在編程中，無論我們的程序如何去寫，相信最終的目標是數據為我們服務，但是在眾多的條件下，數據並不只是簡單的由隨機比特和字節組成的沒有意義的數據，所以我們會在數據庫的節點之間使用關聯來表示現實世界中的某些事物，比如：在現實的世界中，並不是所有的實體類型看起來是一樣的，比如公司員工(Employee)：一個人可能只有一個座機號碼，另一個人可能只有一個手機號碼，而有些人可能兩者都有，一個人可能有Email，其他人也可能沒有。那么如何解決這種問題呢？相信大家第一時間都會想到面向對象，是的，我們可以使用對象來處理現實世界中的這些有着復雜結構的實體。到目前為止，基本所有的開發語言都支持面向對象。
b. 但是當我們想存儲下來這些實體時便存在了問題，大部分引用中，我們使用行和列的形式把數據存儲在關系型數據庫中，但是這種固定的存儲方式導致對象的靈活性不存在了，那么如何能以對象的形式存儲對象呢？相對於圍繞表格去為我們的程序建模，我們可以更加專注於使用數據，把對象的靈活性給釋放(mongodb就是這方面典型的代表)。
c. 對象(Object)是一種語言相關，記錄在內存中的數據結構，為了在網絡間發送或者儲存它，故而出現了標准的格式來表示它，JSON(JavaScript Object Notation)是一種可讀的以文本來表示對象的方式，它已經成為NoSql世界中數據交換的一種事實標准，當對象被序列化為JSON,它就成為JSON文檔了。
d. Elasticsearch是一個分布式的文檔(Document)存儲引擎，他可以實時存儲並且檢索復雜的數據結構(序列化的JSON文檔)，換言之一旦文檔被存儲在Elasticsearch中，它就可以在集群的任意一個節點上被檢索，當然我們不僅需要存儲數據，還需要快速的批量查詢，雖然很多NoSql的解決方案允許以文檔的形式存儲對象，但它們依舊需要考慮如何查詢這些數據以及那些字段需要添加索引來使檢索時更加快速，而在Elasticsearch中，每一個字段的數據都是默認添加了索引，也就是說，每個字段專門有一個反向索引用於快速檢索，而且與其他的數據庫不同的是他可以在同一個查詢中利用所有的這些反向索引，來快速的返回結果。
e. Elasticsearch使用JSON(JavaScript Object Notation)作為文檔序列化格式，JSON已經被大多數語言所支持，而且已經成為了NoSql領域的標准格式，它簡潔、簡單而且容易閱讀。
f. 上面簡述了Elasticsearch的數據處理對象的來源以及選擇和有點，那么下面我們來說一下面向文檔的開發。
3. 面向文檔的開發
a. 什么是面向文檔的開發呢？通常，我們可以認為對象(object)和文檔(document)是等價想通的，不過在Elasticsearch中，他們還是有所差別的，對象(Object)是一個JSON結構體(類似於哈希，hashmap，字典或者關聯數組)，對象(Object)中還可能包含其他對象(Object)，在Elasticsearch中，文檔(document)這個屬於有着特殊的含義它特質最頂層結構或者根對象(root object)序列化的Json數據(以唯一Id標識並且存儲在Elasticsearch中)。
b. ELasticsearch是面向文檔的，這就意味着他可以存儲整個對象或文檔，然而它不僅僅死存儲，還會索引(index)每個文檔的內容使之可以被搜索，在Elasticsearch中，你可以對文檔對象模型進行索引、搜索、排序、過濾。這就是Elasticsearch能夠執行復雜的全文搜索的原因之一。
c.程序中大多數的實體或者對象能夠被序列化為包含鍵值對的JSON對象，鍵(Key)是字段(field)或屬性(property)的名字，值(value)可以是字符串、數字、布爾類型、對象、數組或者其它特殊類型。
d. 這里我使用C#創建了一個員工類，在里面聲明了一些字段屬性，在后面的文章中將統一使用這個實體類來操作,盡管原始的Employee對象很復雜，但它的結構和對象的含義已經被完成的體現在JSON中了，所以在Elasticsearch中將對象轉化為JSON並做索引要比在表結構中做相同的事情簡單的多。如下所示：實體以及轉換后的JSON。
d.1 實體類如下(C#所寫，大家可以轉換成Java等其它語言)：
1 using System; 2 using System.Collections.Generic; 3 4 namespace Common 5 { 6 /// <summary> 7 /// 員工實體 8 /// </summary> 9 public class Emplyee 10 { 11 /// <summary> 12 /// 員工Id 13 /// </summary> 14 public string Id { get; set; } 15 16 /// <summary> 17 /// 員工名稱 18 /// </summary> 19 public string Name { get; set; } 20 21 /// <summary> 22 /// 員工年齡 23 /// </summary> 24 public int Age { get; set; } 25 26 /// <summary> 27 /// 是否實習 28 /// </summary> 29 public bool IsPractice { get; set; } 30 31 /// <summary> 32 /// 興趣愛好 33 /// </summary> 34 public string[] Interests { get; set; } 35 36 /// <summary> 37 /// 加入公司時間 38 /// </summary> 39 public DateTime JoinDate { get; set; } 40 41 /// <summary> 42 /// 員工家庭信息 43 /// </summary> 44 public Home Home { get; set; } 45 46 /// <summary> 47 /// 員工賬號信息 48 /// </summary> 49 public List<Accounts> Accounts { get; set; } 50 } 51 52 53 /// <summary> 54 /// 員工家庭信息 55 /// </summary> 56 public class Home 57 { 58 /// <summary> 59 /// 緯度 60 /// </summary> 61 public double Lat { get; set; } 62 63 /// <summary> 64 /// 經度 65 /// </summary> 66 public double Long { get; set; } 67 } 68 69 /// <summary> 70 /// 員工賬號信息 71 /// </summary> 72 public class Accounts 73 { 74 /// <summary> 75 /// 類型 76 /// </summary> 77 public string Type { get; set; } 78 79 /// <summary> 80 /// 值 81 /// </summary> 82 public string Value { get; set; } 83 } 84
d.2 賦值生成一個JSON對象，如下圖所示：
e.幾乎所有的語言都有相應的模塊用於將任意數據結構轉換為JSON,但每種語言處理的細節不同，Elasticsearch官方客戶端會自動為我們序列化和反序列化JSON,下面開始你的Elasticsearch學習之旅吧。
4. 文檔元數據
a. 在Elasticsearch下，一個文檔中不只有數據，它還包含了元數據(metadata)，在Elasticsearch下，每創建一條數據，都會對元數據進行寫入等操作，元數據在Elasticsearch下起到了非常大的作用，關於三個必須的元數據節點如下(賦圖)：
| 節點 | 說明 |
| _index | 文檔存儲的地方(類似於數據庫,只可以這樣理解) |
| _type | 文檔代表的對象的類(類似於數據庫中的表，只可以這樣理解) |
| _id | 文檔的唯一標識(類似於數據庫中表的主鍵，只可以這樣理解) |
b. _index 索引(index)類似於關系型數據庫里的"數據庫"，它是存儲和索引關聯數據的地方。
b.1 事實上，我們的數據被存儲和索引在分片(shards)中,索引只是一個把一個或者多個分片分組在一起的邏輯空間，然而內部的一些細節不需要我們程序關心，文檔存儲在索引(index)中，剩下的需要的工作交由Elasticsearch關心即可。
b.2 我們將在后面的文章中將會闡述如何創建並且管理索引，而現在使用Elasticsearch創建索引只需要選擇一個索引名，這個名稱必須全部小寫，不能以下划線開頭，不能包含逗號。如上面定義的類所示，后面我們將使用公司(company)作為索引名。
c. _type
c.1 如上面所說說，在現實世界中，我們使用對象標識一些"事物"，每個對象都屬於一個類(class，如：Employee)，這個類定義了屬性或者對象關聯的數據。
c.2 在關系型數據庫中，我們經常講相同累的對象儲存在一個表里面，因為他們有着相同的結構，當然在Elasticsearch中，我們可以使用相同類型(type)的文檔表示相同的"事物"，因為他們的數據結構是相同的，每個類型都有自己的映射(mapping)或者結構定義，就像傳統數據庫表中的列一樣，所有類型下的文檔被儲存在同一個索引下，但是類型的映射(mapping)會告訴Elasticsearch不同的文檔如何被縮影，后面會說到。
c.3 _type的命名規范，它的名字可以是大寫或者小寫，不能包含下划線或逗號，后面我們將使用employee作為類型名。
d. _id 一個字符串，它與_index和_type組合時，就可以在Elasticsearch中唯一標識一個文檔，當創建一個文檔的時候，你可以自定義_id，也可以讓Elasticsearch自動幫你生成。
每天一點點都是進步
如果文章哪里存在問題，歡迎大家指出來，我會在第一時間修改。