『壹』 如何查看IT大數據中ElasticSearch組件的數據存儲路徑
如果是默認配置的話，就是放在ES目錄下的data文件夾下
如果是默認配置的話，就是放在ES目錄下的data文件夾下
-
『貳』 elasticsearch document 怎麼存
本文翻譯自Elasticsearch官方指南的distributed document store一章。
分布式文檔存儲
在上一章中，我們一直在介紹索引數據和獲取數據的方法。但是我們省略了很多關於數據是如何在集群中被分布(Distributed)和獲取(Fetched)的技術細節。這實際上是有意為之 - 你真的不需要了解數據在ES中是如何被分布的。它能工作就足夠了。
在本章中，我們將會深入到這些內部技術細節中，來幫助你了解你的數據是如何被存儲在一個分布式系統中的。
路由一份文檔(Document)到一個分片(Shard)
當你索引一份文檔時，它會被保存到一個主要分片(Primary Shard)上。那麼ES是如何知道該文檔應該被保存到哪個分片上呢？當我們創建了一份新文檔，ES是如何知道它究竟應該保存到分片1或者分片2上的呢？
這個過程不能是隨機的，因為將來我們或許還需要獲取該文檔。實際上，這個過程是通過一個非常簡單的公式決定的：
shard = hash(routing) % number_of_primary_shards
以上的routing的值是一個任意的字元串，它默認被設置成文檔的_id欄位，但是也可以被設置成其他指定的值。這個routing字元串會被傳入到一個哈希函數(Hash Function)來得到一個數字，然後該數字會和索引中的主要分片數進行模運算來得到余數。這個余數的范圍應該總是在0和number_of_primary_shards - 1之間，它就是一份文檔被存儲到的分片的號碼。
這就解釋了為什麼索引中的主要分片數量只能在索引創建時被指定，並且將來都不能在被更改：如果主要分片數量在索引創建後改變了，那麼之前的所有路由結果都會變的不正確，從而導致文檔不能被正確地獲取。
用戶有時會認為將主要分片數量固定下來會讓將來對索引的水平擴展(Scale Out)變的困難。實際上，有些技術能夠讓你根據需要方便地進行水平擴展。我們會在Designing for scale中介紹這些技術。
所有的文檔API(get, index, delete, buli, update和mget)都接受一個routing參數，它用來定製從文檔到分片的映射。一個特定的routing值能夠確保所有相關文檔 - 比如屬於相同用戶的所有文檔 - 都會被存儲在相同的分片上。我們會在Designing for scale中詳細介紹為什麼你可能會這樣做。
『叄』 Elasticsearch的架構是什麼樣的
Elasticsearch是由Shay Banon發起的一個開源搜索伺服器項目，2010年2月發布。迄今，該項目已發展成為搜索和數據分析解決方案領域的主要一員，廣泛應用於聲名卓著或鮮為人知的搜索應用程序。此外，由於其分布式性質和實時功能，許多人把它作為文檔資料庫。
Elasticsearch架構簡單介紹如下。
索引
索引（index）是Elasticsearch對邏輯數據的邏輯存儲，所以它可以分為更小的部分。你可以把索引看成關系型資料庫的表。然而，索引的結構是為快速有效的全文索引准備的，特別是它不存儲原始值。如果你知道MongoDB，可以把Elasticsearch的索引看成MongoDB里的一個集合。如果你熟悉CouchDB，可以把索引看成CouchDB資料庫索引。Elasticsearch可以把索引存放在一台機器或者分散在多台伺服器上，每個索引有一或多個分片（shard），每個分片可以有多個副本（replica）。
文檔
存儲在Elasticsearch中的主要實體叫文檔（document）。用關系型資料庫來類比的話，一個文檔相當於資料庫表中的一行記錄。當比較Elasticsearch中的文檔和MongoDB中的文檔，你會發現兩者都可以有不同的結構，但Elasticsearch的文檔中，相同欄位必須有相同類型。這意味著，所有包含title欄位的文檔，title欄位類型都必須一樣，比如string。
文檔由多個欄位組成，每個欄位可能多次出現在一個文檔里，這樣的欄位叫多值欄位（multivalued）。每個欄位有類型，如文本、數值、日期等。欄位類型也可以是復雜類型，一個欄位包含其他子文檔或者數組。欄位類型在Elasticsearch中很重要，因為它給出了各種操作（如分析或排序）如何被執行的信息。幸好，這可以自動確定，然而，我們仍然建議使用映射。與關系型資料庫不同，文檔不需要有固定的結構，每個文檔可以有不同的欄位，此外，在程序開發期間，不必確定有哪些欄位。當然，可以用模式強行規定文檔結構。從客戶端的角度看，文檔是一個JSON對象（關於JSON格式的更多內容，參見http://en.wikipedia.org/wiki/JSON）。每個文檔存儲在一個索引中並有一個Elasticsearch自動生成的唯一標識符和文檔類型。文檔需要有對應文檔類型的唯一標識符，這意味著在一個索引中，兩個不同類型的文檔可以有相同的唯一標識符。
文檔類型
在Elasticsearch中，一個索引對象可以存儲很多不同用途的對象。例如，一個博客應用程序可以保存文章和評論。文檔類型讓我們輕易地區分單個索引中的不同對象。每個文檔可以有不同的結構，但在實際部署中，將文件按類型區分對數據操作有很大幫助。當然，需要記住一個限制，不同的文檔類型不能為相同的屬性設置不同的類型。例如，在同一索引中的所有文檔類型中，一個叫title的欄位必須具有相同的類型。
映射
在有關全文搜索基礎知識部分，我們提到了分析的過程：為建索引和搜索准備輸入文本。文檔中的每個欄位都必須根據不同類型做相應的分析。舉例來說，對數值欄位和從網頁抓取的文本欄位有不同的分析，比如前者的數字不應該按字母順序排序，後者的第一步是忽略HTML標簽，因為它們是無用的信息噪音。Elasticsearch在映射中存儲有關欄位的信息。每一個文檔類型都有自己的映射，即使我們沒有明確定義。
現在，我們已經知道Elasticsearch把數據存儲在一個或多個索引上，每個索引包含各種類型的文檔。我們也知道了每個文檔有很多欄位，映射定義了Elasticsearch如何對待這些欄位。但還有更多，從一開始，Elasticsearch就被設計為能處理數以億計的文檔和每秒數以百計的搜索請求的分布式解決方案。這歸功於幾個重要的概念，我們現在將更詳細地描述。
節點和集群
Elasticsearch可以作為一個獨立的單個搜索伺服器。不過，為了能夠處理大型數據集，實現容錯和高可用性，Elasticsearch可以運行在許多互相合作的伺服器上。這些伺服器稱為集群（cluster），形成集群的每個伺服器稱為節點（node）。
分片
當有大量的文檔時，由於內存的限制、硬碟能力、處理能力不足、無法足夠快地響應客戶端請求等，一個節點可能不夠。在這種情況下，數據可以分為較小的稱為分片（shard）的部分（其中每個分片都是一個獨立的Apache Lucene索引）。每個分片可以放在不同的伺服器上，因此，數據可以在集群的節點中傳播。當你查詢的索引分布在多個分片上時，Elasticsearch會把查詢發送給每個相關的分片，並將結果合並在一起，而應用程序並不知道分片的存在。此外，多個分片可以加快索引。
副本
為了提高查詢吞吐量或實現高可用性，可以使用分片副本。副本（replica）只是一個分片的精確復制，每個分片可以有零個或多個副本。換句話說，Elasticsearch可以有許多相同的分片，其中之一被自動選擇去更改索引操作。這種特殊的分片稱為主分片（primary shard），其餘稱為副本分片（replica shard）。在主分片丟失時，例如該分片數據所在伺服器不可用，集群將副本提升為新的主分片。
『肆』 elasticsearch數據存儲目錄data會存哪些信息
elasticsearch數據存儲目錄data會存哪些信息
如果是默認配置的話,就是放在ES目錄下的data文件夾下如果是默認配置的話,就是放在ES目錄下的d
『伍』 elasticsearch integer 和 string存儲的區別
在Es中，欄位的類型很關鍵：
在索引的時候，如果欄位第一次出現，會自動識別某個類型，這種規則之前已經講過了。
那麼如果一個欄位已經存在了，並且設置為某個類型。再來一條數據，欄位的數據不與當前的類型相符，就會出現欄位沖突的問題。如果發生了沖突，在2.x版本會自動拒絕。
如果自動映射無法滿足需求，就需要使用者自己來設置映射類型，因此，就需要使用者了解ES中的類型。
下面就步入正題吧！
『陸』 elasticsearch 怎麼更新數據的
我們經常有這樣的需求，在對 Elasticsearch 數據進行操作的時候，要及時返回剛剛操作完畢的數據，或者數據列表。
比如加入存儲一條數據後，我馬上要返回數據的總條數，這個時候，會出問題，Elasticsearch會返回操作之前的數據，也就是假如開始有500條數據，我Insert了一條進去，按道理來說應該是501條，但是這個時候查詢會發現，只有500條數據，再次請求又得到501條數據，這個是怎麼回事呢？
這個問題因為 Elasticsearch 有延遲的關系（好像記得是3秒還是1秒來著）。有的人的做法比如有以下方法解決的。
Thread.sleep(3000L);
還有再請求一次的。但這些都不是解決方案，當你知道有方法的時候，你會自己笑自己。
其實我看過這個網站的博客里有用到，但是群主沒提到這個方法的作用。
在：http://www.sojson.com/blog/88.html里有一句代碼，如下：
BulkRequestBuilder bulkRequest = ESTools.client.prepareBulk().setRefresh(true);
這里的setRefresh(true);
就是自動刷新的用處。所以在我們CRUD的時候，如果對數據增刪改操作的時候，如果要及時返回最新數據，那麼我們就需要加這個方法，及時刷新數據。
當然 Elasticsearch 也是可以配置刷新時間的，但是沒必要，頻繁的刷新會造成壓力過大。
『柒』 elasticsearch，solr對比各自有哪些優缺點
從兩個方面對ElasticSearch和Solr進行對比，從關系型資料庫中的導入速度和模糊查詢的速度。
單機對比
1. Solr 發布了4.0-alpha，試了一下，發現需要自己修改schema，好處是它自帶一個data importer。在自己的計算機上測試了一下，導入的性能大概是：14分鍾導入 3092730 條記錄，約合 3682條/秒。
2. 3百萬條記錄的情況下，模糊查詢和排序基本都在1秒內返回
3. 剛才的測試，是每個field單獨存儲，現在修改了一下配置文件，增加了一個Field，所有的field都拷貝一份到text這個field裡面去，導入的性能大概是：19分鍾導入了3092730 條記錄，約合 2713條/秒
4. 3百萬條記錄的情況下，針對text的模糊查詢基本在1秒內返回，但是針對所有記錄的排序，大概要2~3秒
5. 使用 elasticsearch 0.19.8，預設配置，用單任務導入，導入性能是：20分鍾導入了3092730 條記錄，約合2577條/秒
6. 3百萬條記錄的情況下，查詢基本上在1秒內返回，但是模糊查詢比較慢，第一次要10秒，後來大概要1~3秒。加上排序大概需要5秒，整體排序基本100ms
查詢及排序的指令：
{
"query": {
"query_string": {
"query": "*999*"
}
},
"sort": [
{
"TIME_UP": {
"order": "asc"
}
}
]
}
7. Es0.19.8，用兩個任務導入，導入性能是：13分鍾導入了3092730 條記錄，約合3965條/秒
8. Solr全部建好索引後，佔用磁碟空間是1.2G，es佔用磁碟空間是4G
單機對比2
在一台Intel i7，32G內存的機器上，重新跑這兩個的對比。不過有個重大的區別在於，Solr是在這台性能很好的機器上跑，而es的導入進程則是在一台Intel 四核 2.5G，4G內存的機器上跑的，也許會有性能的差異。ES版本0.19.8，Solr版本4.0-ALPHA。
1. Solr的導入性能：3400萬條記錄，用時62分鍾，平均9140條/秒，佔用空間12.75G
2. 使用 *999* 這樣的模糊查詢，3秒以內返回，稍長一點的查詢條件 *00100014*，也是2~3秒返回
3. Es的導入性能（設置Xmx為10G）：3400萬條記錄，用時40分鍾，平均14167條/秒，佔用空間33.26G，客戶端採用4個並發。
4. 使用 *999* 這樣的模糊查詢，9秒返回，稍長一點的查詢條件 *00100014*，11.8秒返回
5. 如果不是針對所有欄位查詢，而是針對某個特定欄位，比如 SAM_CODE: *00100014*，那麼也是1秒以內返回。
6. 結論：es的查詢效率也可以很高，只是我們還不會用。
7. 結論2：es有個設置是把所有欄位放一塊的那個，預設是放一起，但是不知道為什麼沒起到應有的作用。
備註：
1. Solr第一次的那個內存使用的是預設設置，這次改為10G，結果導入性能反而變差了，400萬條記錄，用了8分鍾，平均8333條/秒，不知道為什麼。
2. 改回預設的內存配置，導入速度仍然慢。
3. 重啟Linux，用10G的內存配置，再導入，5030萬條記錄，用時92分，約9112條/秒，說明導入速度和內存配置沒有大差別
4. 在10G配置的情況下，檢索速度也差別不大。
5. 為了搞清楚lucene4.0和solr4.0的進步有多大，下載了solr3.6.1，所幸的是4.0的配置文件在3.6.1上也可以用，所以很快就搭起來進行測試，導入性能為：3400萬條記錄，用時55分鍾，約10303條/秒，佔用空間13.85G。查詢性能：*999*第一次11.6s，*00100014* 27.3s，相比4.0ALPHA的結果（5000萬結果當中，*999*第一次2.6s，*00100014*第一次2.5s）來說，慢了很多，與es的性能差不多，因此，也許lucene4.0真的對性能有大幅提升？
集群對比：
採用4台同樣配置（Intel i7，32G內存）的Centos 6.3組成的集群，進行對比。
1. 首先是es，很方便的就組成了一個Cluster，等上一個3400萬條的Index全部均衡負載之後進行測試，導入到另外一個Index當中。
2. 導入性能：8500萬條記錄，用時72分鍾，約為19676條/秒。在前5千萬條記錄導入時的速度在2萬/條以上，初始的速度在2.2萬/條。佔用空間78.6G（由於有冗餘，實際佔用空間為157.2G）
3. 查詢性能：
*999*第一次13.5秒，第二次19.5秒，第三次7.4秒，第四次7.1秒，第五次7.1秒
*00100014*第一次17.2秒，第二次16.6秒，第三次17.9秒，第四次16.7秒，第五次17.1秒
SAM_CODE:*999*，0.8s，1.3s，0.02s，0.02s，0.02s
SAM_CODE: *00100014*，0.1s，0.1s，0.02s，0.03s，0.05s
4. Solr4.0-ALPHA，SolrCloud的配置還算簡單，啟動一個ZooKeeper，然後其他三台機器訪問這個地址，就可以組成一個Cloud：
機器1： nohup java -Xms10G -Xmx10G -Xss256k -Djetty.port=8983 -Dsolr.solr.home="./example-DIH/solr/" -Dbootstrap_confdir=./example-DIH/solr/db/conf/ -Dcollection.configName=xabconf3 -DzkRun -DnumShards=4 -jar start.jar &
其他機器：nohup java -Xms10G -Xmx10G -Dsolr.solr.home="./example-DIH/solr/" -DzkHost=192.168.2.11:9983 -jar start.jar &
但是在執行 data import 的時候，頻繁出現 OutOfMemoryError: unable to create new native thread。查了很多資料，把Linux的ulimit當中的nproc改成10240，把Xss改成256K，都解決不了問題。暫時沒有辦法進行。
結論
1. 導入性能，es更強
2. 查詢性能，solr 4.0最好，es與solr 3.6持平，可以樂觀的認為，等es採用了lucene4之後，性能會有質的提升
3. Es採用SAM_CODE這樣的查詢性能很好，但是用_all性能就很差，而且差別非常大，因此，個人認為在目前的es情況下，仍然有性能提升的空間，只是現在還沒找到方法。
『捌』 elasticsearch如何搭建在hadoop上
配置elasticsearch的存儲路徑為hdfs需要兩步，安裝插件elasticsearch-hadoop，在聯網的情況下在命令窗口運行：plugin -install elasticsearch/elasticsearch-hadoop/1.2.0即可。
如果沒有聯網解壓插件到plugins中即可，目錄為/hadoop。。。。。
在配置文件elasticsearch.yml中要配置如下：
gateway:
type: hdfs
gateway:
hdfs:
uri: hdfs://localhost:9000
『玖』 如何搭建elasticsearch
配置elasticsearch的存儲路徑為hdfs需要兩步，安裝插件elasticsearch-hadoop，在聯網的情況下在命令窗口運行：plugin -install elasticsearch/elasticsearch-hadoop/1.2.0即可。如果沒有聯網解壓插件到plugins中即可，目錄為/hadoop。。。。。在配置文件elasticsearch.yml中要配置如下：gateway:type: hdfsgateway:hdfs:uri: hdfs://localhost:9000