返回目錄:http://www.cnblogs.com/hanyinglong/p/5464604.htmlnode
a. 在上面博客中,咱們已經安裝而且成功配置了Elasticsearch以及部分插件,接下來咱們就須要看看Elasticseach的配置文件的信息以及文檔的一些說明。linux
b.首先找到Elasticsearch的安裝位置,跳轉到elasticsearch的config文件夾下,在此文件夾下含有兩個配置文件:elasticsearch.yml和logging.yml,第一個是Elasticsearch的基本配置文件,第二個是日誌配置文件,Elasticsearch是使用log4j來記錄日誌的,因此logging.yml裏的設置按普通的log4j配置文件夾來設置便可。下面咱們主要來講一下elasticsearch.yml文件中的配置信息。mongodb
c.文檔說明採用寫備註的方法來講明elasticsearch.yml文件,Elasticsearch的版本是:2.3.1。數據庫
c.1 cluster.name: kencery 配置Elasticsearch的集羣名稱,默認是elasticsearch,Elasticsearch會自動發如今同一網段下的es集羣,若是在同一個網段下有多個集羣,能夠利用這個屬性來區分不一樣的集羣。編程
c.2 node.name : "kencery-node1" 集羣的節點名稱,Elasticsearch啓動的時候會自動建立節點名稱,可是你也能夠進行配置。bootstrap
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
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的數據處理對象的來源以及選擇和有點,那麼下面咱們來講一下面向文檔的開發。
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學習之旅吧。
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自動幫你生成。
天天一點點都是進步
若是文章哪裏存在問題,歡迎你們指出來,我會在第一時間修改。