代表es的一個數據源，也是其它存儲方式（如：數據庫）同步數據到es的一個方法。它是以插件方式存在的一個es服 務，通過讀取river中的數據并把它索引到es中，官方的river有couchDB的，RabbitMQ的，Twitter的，Wikipedia 的。
代表es索引的持久化存儲方式，es默認是先把索引存放到內存中，當內存滿了時再持久化到硬盤。當這個es集群關閉再 重新啟動時就會從gateway中讀取索引數據。es支持多種類型的gateway，有本地文件系統（默認），分布式文件系統，Hadoop的HDFS和 amazon的s3云存儲服務。
代表es內部節點或集群與客戶端的交互方式，默認內部是使用tcp協議進行交互，同時它支持http協議（json格式）、thrift、servlet、memcached、zeroMQ等的傳輸協議（通過插件方式集成）。
elasticsearch官方只提供smartcn這個中文分詞插件，效果不是很好，好在國內有medcl大神（國內最早研究es的人之一）寫的兩個中文分詞插件，一個是ik的，一個是mmseg的，下面分別介紹下兩者的用法，其實都差不多的，先安裝插件，命令行：
wget http://github.com/downloads/medcl/elasticsearch-analysis-ik/ik.zip --no-check-certificate
wget http://github.com/downloads/medcl/elasticsearch-analysis-mmseg/mmseg.zip --no-check-certificate
這樣配置完后插件安裝完成，啟動es就會加載插件。
定義mapping
在添加索引的mapping時就可以這樣定義分詞器
{ "page":{ "properties":{ "title":{ "type":"string", "indexAnalyzer":"ik", "searchAnalyzer":"ik" }, "content":{ "type":"string", "indexAnalyzer":"ik", "searchAnalyzer":"ik" } } } } |
indexAnalyzer為索引時使用的分詞器，searchAnalyzer為搜索時使用的分詞器。
java mapping代碼如下：
XContentBuilder content = XContentFactory.jsonBuilder().startObject() .startObject("page") .startObject("properties") .startObject("title") .field("type", "string") .field("indexAnalyzer", "ik") .field("searchAnalyzer", "ik") .endObject() .startObject("code") .field("type", "string") .field("indexAnalyzer", "ik") .field("searchAnalyzer", "ik") .endObject() .endObject() .endObject() .endObject() |
定義完后操作索引就會以指定的分詞器來進行分詞。
附：
ik分詞插件項目地址：https://github.com/medcl/elasticsearch-analysis-ik
mmseg分詞插件項目地址：https://github.com/medcl/elasticsearch-analysis-mmseg
如果覺得配置麻煩，也可以下載個配置好的es版本，地址如下：https://github.com/medcl/elasticsearch-rtf
elasticsearch的基本用法
最大的特點：
1. 數據庫的 database, 就是 index
2. 數據庫的 table, 就是 tag
3. 不要使用browser， 使用curl來進行客戶端操作. 否則會出現 java heap ooxx...
curl: -X 后面跟 RESTful ： GET, POST ...
-d 后面跟數據。 (d = data to send)
1. create:
指定 ID 來建立新記錄。 （貌似PUT， POST都可以）
$ curl -XPOST localhost:9200/films/md/2 -d '
{ "name":"hei yi ren", "tag": "good"}'
使用自動生成的 ID 建立新紀錄：
$ curl -XPOST localhost:9200/films/md -d '
{ "name":"ma da jia si jia3", "tag": "good"}'
2. 查詢：
2.1 查詢所有的 index, type:
$ curl localhost:9200/_search?pretty=true
2.2 查詢某個index下所有的type:
$ curl localhost:9200/films/_search
2.3 查詢某個index 下， 某個 type下所有的記錄：
$ curl localhost:9200/films/md/_search?pretty=true
2.4 帶有參數的查詢：
$ curl localhost:9200/films/md/_search?q=tag:good
{"took":7,"timed_out":false,"_shards":{"total":5,"successful":5,"failed":0},"hits":{"total":2,"max_score":1.0,"hits":[{"_index":"film","_type":"md","_id":"2","_score":1.0, "_source" :
{ "name":"hei yi ren", "tag": "good"}},{"_index":"film","_type":"md","_id":"1","_score":0.30685282, "_source" :
{ "name":"ma da jia si jia", "tag": "good"}}]}}
2.5 使用JSON參數的查詢： （注意 query 和 term 關鍵字）
$ curl localhost:9200/film/_search -d '
{"query" : { "term": { "tag":"bad"}}}'
3. update
$ curl -XPUT localhost:9200/films/md/1 -d { ...(data)... }
4. 刪除。 刪除所有的：
$ curl -XDELETE localhost:9200/films
引言：
今天，事情終于發生了。Java6（Mustang），是2006年早些時候出來的，至今仍然應用在眾多生產環境中，現在終于走到了盡頭。已經沒有什么理由阻止遷移到Java7(Dolphin)上了。
這也促使我想寫一篇關于在ElasticSearch上配置Java6和7的細微差異的博文。
Elasticsearch對Java虛擬機進行了預先的配置。通常情況下，因為這些配置的選擇還是很謹慎的，所以你不需要太關心，并且你能立刻使用ElasticSearch。
但是，當你監視ElasticSearch節點內存時，你可能嘗試修改一些配置。這些修改是否會改善你的處境？
這篇博文嘗試揭開Elasticsearch配置的神秘面紗，并且討論最常見的調整。最終，會給出一些推薦的配置調整。
Elasticsearch JVM 配置概覽：
這些是Elasticsearch 0.19.11版本的默認配置。
JVM參數 Elasticsearch默認值 Environment變量
-Xms 256m ES_MIN_MEM -Xmx 1g ES_MAX_MEM -Xms and -Xmx ES_HEAP_SIZE -Xmn ES_HEAP_NEWSIZE -XX:MaxDirectMemorySize ES_DIRECT_SIZE -Xss 256k -XX:UseParNewGC + -XX:UseConcMarkSweepGC + -XX:CMSInitiatingOccupancyFraction 75 -XX:UseCMSInitiatingOccupancyOnly + -XX:UseCondCardMark (commented out) |
首先你注意到的是，Elasticsearch預留了256M到1GB的堆內存。
這個設置適用于開發和演示環境。開發人員只需要簡單的解壓發行包，再執行./bin/elasticsearch -f就完成了Elasticsearch的安裝。當然這點對于開發來說非常棒，并且在很多場景下都能工作，但是當你需要更多內存來降低Elasticsearch負載的時候就不行了，你需要比2GB RAM更多的可用內存。
ES_MIN_MEM/ES_MAX_MEM是控制堆大小的配置。新的ES_HEAP_SIZE變量是一個更為便利的選擇，因為將堆的初始大小和最大值設為相同。也推薦在分配堆內存時盡可能不要用內存的碎片。內存碎片對于性能優化來說非常不利。
ES_HEAP_NEWSIZE是可選參數，它控制堆的子集大小，也就是新生代的大小。
ES_DIRECT_SIZE控制本機直接內存大小，即JVM管理NIO框架中使用的數據區域大小。本機直接內存可以被映射到虛擬地址空間上，這樣在64位的機器上更高效，因為可以規避文件系統緩沖。Elasticsearch對本機直接內存沒有限制(可能導致OOM)。
由于歷史原因Java虛擬機有多個垃圾收集器。可以通過以下的JVM參數組合啟用：
JVM parameter Garbage collector -XX:+UseSerialGC serial collector -XX:+UseParallelGC parallel collector -XX:+UseParallelOldGC Parallel compacting collector -XX:+UseConcMarkSweepGC Concurrent-Mark-Sweep (CMS) collector -XX:+UseG1GC Garbage-First collector (G1) |
UseParNewGC和UseConcMarkSweepGC組合啟用垃圾收集器的并發多線程模式。UseConcMarkSweepGC自動選擇UseParNewGC模式并禁用串行收集器（Serial collector）。在Java6中這是默認行為。
CMSInitiatingOccupancyFraction提煉了一種CMS（Concurrent-Mark-Sweep）垃圾收集設置；它將舊生代觸發垃圾收集的閥值設為75.舊生代的大小是堆大小減去新生代大小。這告訴JVM當堆內容達到75%時啟用垃圾收集。這是個估計的值，因為越小的堆可能需要越早啟動GC。
UseCondCardMark將在垃圾收集器的card table使用時，在marking之前進行額外的判斷，避免冗余的store操作。UseCondCardMark不影響Garbage-First收集器。強烈推薦在高并發場景下配置這個參數（規避card table marking技術在高并發場景下的降低吞吐量的負面作用）。在ElasticSearch中，這個參數是被注釋掉的。
有些配置可以參考諸如Apache Cassandra項目，他們在JVM上有類似的需求。
總而言之，ElastciSearch配置上推薦：
1. 不采用自動的堆內存配置，將堆大小默認最大值設為1GB
2.調整觸發垃圾收集的閥值，比如將gc設為75%堆大小的時候觸發，這樣不會影響性能。
3.禁用Java7默認的G1收集器，前提是你的ElasticSearch跑在Java7u4以上的版本上。
JVM進程的內存結果
JVM內存由幾部分組成：
Java代碼本身：包括內部代碼、數據、接口，調試和監控代理或者字節碼指令
非堆內存：用于加載類
棧內存：用于為每個線程存儲本地變量和操作數
堆內存：用于存放對象引用和對象本身
直接緩沖區：用于緩沖I/O數據
堆內存的大小設置非常重要，因為Java的運行依賴于合理的堆大小，并且JVM需要從操作系統那獲取有限的堆內存，用于支撐整個JVM生命周期。
如果堆太小，垃圾回收就會頻繁發生，發生OOM的幾率會很大。
如果堆太大，垃圾回收會延遲，但是一旦回收，就需要處理大量的存活堆數據。并且，操作系統的壓力也會變大，因為JVM進程需要更大的堆，產生換頁的可能性就會提高。
注意，使用CMS垃圾收集器，Java不會把內存還給操作系統，因此配置合理的堆初始值和最大值就非常重要。
非堆內存由Java應用自動分配。沒有什么參數控制這里的大小，這是由Java應用程序代碼自己決定的。
棧內存在每個線程中分配，在Elasticsearch中，每個線程大小必須由128K增加到256K，因為Java7比Java6需要更大的棧內存 ，這是由于Java7支持新的編程語言特征來利用棧空間。比如，引入了continuations模型，編程語言的一個著名概念。Continuations模型對于
協同程序、綠色線程（green thread）、纖程（fiber）非常有用 。當實現非阻塞I/O時，一個大的優勢是，代碼可以根據線程實際使用情況編寫，但是運行時仍然在后臺采用非阻塞I/O。Elasticsearch使用了多個線程池，因為Netty I/O框架和Guava是Elasticsearch的基礎組件，因此在用Java7時，可以考慮進一步挖掘優化線程的特性。
發揮增加棧空間大小的優勢還是有挑戰的，因為不同的操作系統、不同的CPU架構，甚至在不同的JVM版本之間，棧空間的消耗不是容易比較的。取決于CPU架構和操作系統，JVM的棧空間大小是內建的。他們是否在所有場景下都適合？例如Sloaris Sparc 64位的JVM Xss默認為512K，因為有更大地址指針，Sloaris X86為320K。Linux降為256K。Windows 32位Java6默認320K，Windows 64位則為1024K。
大堆的挑戰
今天，幾GB的內存是很常見的。但是在不久以前，系統管理員還在為多幾G的內存需求淚流滿面。
Java垃圾收集器是隨著2006年的Java6的出現而顯著改進的。從那以后，可以并發執行多任務，并且減少了GC停頓幾率： stop - the - world階段。CMS算法是革命性的，多任務，并發， 不需要移動的GC。但是不幸的是，對于堆的存活數據量來說，它是不可擴展的。Prateek Khanna 和 Aaron Morton給出了CMS垃圾收集器能夠處理的堆規模的數字。
避免Stop-the-world階段
我們已經學習了Elasticsearch如何配置CMS垃圾收集器。但這并不能組織長時間的GC停頓，它只是降低了發生的幾率。CMS是一個低停頓幾率的收集器，但是仍然有一些邊界情況。當堆上有MB級別的大數組，或者其他一些特殊的場景，CMS可能比預期要花費更多的時間。
MB級別數組的創建在Lucene segment-based索引合并時是很常見的。如果你希望降低CMS的額外負載，就需要調整Lucene合并階段的段數量，使用參數index.merge.policy.segments_per_tier
減少換頁
大堆的風險在于內存壓力上。注意，如果Java JVM在處理大堆時，這部分內存對于系統其它部分來說是不可用的。如果內存吃緊，操作系統會進行換頁，并且，在緊急情況下，當所有其他方式回收內存都失敗時，會強制殺掉進程。如果換頁發生，整個系統的性能會下降，自然GC的性能也跟著下降。所以，不要給堆分配太多的內存。
垃圾收集器的選擇
從Java JDK 7u4開始，Garbage-First（G1）收集器是Java7默認的垃圾收集器。它適用于多核的機器以及大內存。它一方面降低了停頓時間，另一方面增加了停頓的次數。整個堆的操作，例如全局標記，是在應用線程中并發執行的。這會防止隨著堆或存活數據大小的變化，中斷時間也成比例的變化。
G1收集器目標是獲取更高的吞吐量，而不是速度。在以下情況下，它能運行的很好：
1. 存活數據占用了超過50%的Java堆
2. 對象分配比例或者promotion會有明顯的變化
3. 不希望gc或者compaction停頓時間長（超過0.5至1s）
注意，如果使用G1垃圾收集器，堆不再使用的內存可能會被歸還給操作系統
G1垃圾收集器的不足是CPU使用率越高，應用性能越差。因此，如果在內存足夠和CPU能力一般的情況下，CMS可能更勝一籌。
對于Elasticsearch來說，G1意味著沒有長時間的stop-the-world階段，以及更靈活的內存管理，因為buffer memory和系統I/O緩存能更充分的利用機器內存資源。代價就是小成本的最大化性能，因為G1利用了更多CPU資源。
性能調優策略
你讀這篇博文因為你希望在性能調優上得到一些啟示：
1. 清楚了解你的性能目標。你希望最大化速度，還是最大化吞吐量？
2. 記錄任何事情（log everything），收集統計數據，閱讀日志、分析事件來診斷配置
3. 選擇你調整的目標（最大化性能還是最大化吞吐量）
4. 計劃你的調整
5. 應用你的新配置
6. 監控新配置后的系統
7. 如果新配置沒有改善你的處境，重復上面的一系列動作，反復嘗試
Elasticsearch垃圾收集日志格式
Elasticsearch長時間GC下warns級別的日志如下所示：
| [2012-11-26 18:13:53,166][WARN ][monitor.jvm ] [Ectokid] [gc][ParNew][1135087][11248] duration [2.6m], collections [1]/[2.7m], total [2.6m]/[6.8m], memory [2.4gb]->[2.3gb]/[3.8gb], all_pools {[Code Cache] [13.7mb]->[13.7mb]/[48mb]}{[Par Eden Space] [109.6mb]->[15.4mb]/[1gb]}{[Par Survivor Space] [136.5mb]->[0b]/[136.5mb]}{[CMS Old Gen] [2.1gb]->[2.3gb]/[2.6gb]}{[CMS Perm Gen] [35.1mb]->[34.9mb]/[82mb]} |
JvmMonitorService類中有相關的使用方式：
Logfile Explanation gc 運行中的gc ParNew new parallel garbage collector duration 2.6m gc時間為2.6分鐘 collections [1]/[2.7m] 在跑一個收集，共花2.7分鐘 memory [2.4gb]->[2.3gb]/[3.8gb] 內存消耗, 開始是2.4gb, 現在是2.3gb, 共有3.8gb內存 Code Cache [13.7mb]->[13.7mb]/[48mb] code cache占用內存 Par Eden Space [109.6mb]->[15.4mb]/[1gb] Par Eden Space占用內存 Par Survivor Space [136.5mb]->[0b]/[136.5mb] Par Survivor Space占用內存 CMS Old Gen [2.1gb]->[2.3gb]/[2.6gb] CMS Old Gen占用內存 CMS Perm Gen [35.1mb]->[34.9mb]/[82mb] CMS Perm Gen占用內存 JvmMonitorSer |
一些建議
1. 不要在Java 6u22之前的發布版本中跑Elasticsearch。有內存方面的bug。那些超過兩三年的bug和缺陷會妨礙Elasticsearch的正常運行。與舊的OpenJDK 6相比，更推薦Sun/Oracle的版本，因為后者修復了很多bug。
2. 放棄Java6，轉到Java7。Oracle宣稱Java6更新到2013年2月結束。考慮到Elasticsearch還是一個相對新的軟件，應該使用更新的技術來提升性能。盡量從JVM中擠壓性能。檢查操作系統的版本。在最新版本的操作系統中運行，有助于你的Java運行環境達到最佳性能。
3. 定期更新Java運行環境。平均一個季度一次。告訴sa你需要及時更新Java版本，以獲取Java性能的提升。
4. 從小到大。先在Elasticsearch單節點上進行開發。但是不要忘了Elasticsearch分布式的強大功能。單節點不能模擬生產環境的特征，至少需要3個節點進行開發測試。
5. 在調整JVM之前先做一下性能測試。對你的系統建立性能基線。調整測試時候的節點數量。如果索引時候負載很高，你可能需要降低Elasticsearch索引時候占用的堆大小，通過index.merge.policy.segments_per_tierparameter參數調整段的合并。
6. 調整前清楚你的性能目標，然后決定是調整速度還是吞吐量。
7. 啟用日志以便更好的進行診斷。在優化系統前進行小心的評估。
8. 如果使用CMS垃圾收集器，你可能需要加上合理的 -XX:CMSWaitDuration 參數。
9. 如果你的堆超過6-8GB，超過了CMS垃圾收集器設計容量，你會遇到長時間的stop-the-world階段，你有幾個方案：調整CMSInitiatingOccupancyFraction參數降低長時間GC的幾率減少最大堆的大小；啟用G1垃圾收集器。
10. 學習垃圾收集調優藝術。如果你想精通的話，列出可用的JVM選項，在java命令中加入java -XX:+UnlockDiagnosticVMOptions -XX:+PrintFlagsFinal -version，然后調優。