Elasticsearch學習，請先看這一篇！

#題記： Elasticsearch研究有一段時間了，現特將Elasticsearch相關核心知識、原理從初學者認知、學習的角度，從以下9個方面進行詳細梳理。歡迎討論...... #0. 帶著問題上路——ES是如何產生的？ ##（1）思考：大規模資料如何檢索？ 如：當系統資料量上了10億、100億條的時候，我們在做系統架構的時候通常會從以下角度去考慮問題： 1）用什麼資料庫好？(mysql、sybase、oracle、達夢、神通、mongodb、hbase…) 2）如何解決單點故障；(lvs、F5、A10、Zookeep、MQ) 3）如何保證資料安全性；(熱備、冷備、異地多活) 4）如何解決檢索難題；(資料庫代理中介軟體：mysql-proxy、Cobar、MaxScale等;) 5）如何解決統計分析問題；(離線、近實時)

##（2）傳統資料庫的應對解決方案 對於關係型資料，我們通常採用以下或類似架構去解決查詢瓶頸和寫入瓶頸： 解決要點： 1）通過主從備份解決資料安全性問題； 2）通過資料庫代理中介軟體心跳監測，解決單點故障問題； 3）通過代理中介軟體將查詢語句分發到各個slave節點進行查詢，並彙總結果

##（3）非關係型資料庫的解決方案 對於Nosql資料庫，以mongodb為例，其它原理類似： 解決要點： 1）通過副本備份保證資料安全性； 2）通過節點競選機制解決單點問題； 3）先從配置庫檢索分片資訊，然後將請求分發到各個節點，最後由路由節點合併彙總結果

##另闢蹊徑——完全把資料放入記憶體怎麼樣？ 我們知道，完全把資料放在記憶體中是不可靠的，實際上也不太現實，當我們的資料達到PB級別時，按照每個節點96G記憶體計算，在記憶體完全裝滿的資料情況下，我們需要的機器是：1PB=1024T=1048576G 節點數=1048576/96=10922個 實際上，考慮到資料備份，節點數往往在2.5萬臺左右。成本巨大決定了其不現實！

從前面討論我們瞭解到，把資料放在記憶體也好，不放在記憶體也好，都不能完完全全解決問題。 全部放在記憶體速度問題是解決了，但成本問題上來了。 為解決以上問題，從源頭著手分析，通常會從以下方式來尋找方法： 1、儲存資料時按有序儲存； 2、將資料和索引分離； 3、壓縮資料； 這就引出了Elasticsearch。

#1. ES 基礎一網打盡

##1.1 ES定義 ES=elaticsearch簡寫， Elasticsearch是一個開源的高擴充套件的分散式全文檢索引擎，它可以近乎實時的儲存、檢索資料；本身擴充套件性很好，可以擴充套件到上百臺伺服器，處理PB級別的資料。 Elasticsearch也使用Java開發並使用Lucene作為其核心來實現所有索引和搜尋的功能，但是它的目的是通過簡單的RESTful API來隱藏Lucene的複雜性，從而讓全文搜尋變得簡單。

##1.2 Lucene與ES關係？ 1）Lucene只是一個庫。想要使用它，你必須使用Java來作為開發語言並將其直接整合到你的應用中，更糟糕的是，Lucene非常複雜，你需要深入瞭解檢索的相關知識來理解它是如何工作的。

2）Elasticsearch也使用Java開發並使用Lucene作為其核心來實現所有索引和搜尋的功能，但是它的目的是通過簡單的RESTful API來隱藏Lucene的複雜性，從而讓全文搜尋變得簡單。

##1.3 ES主要解決問題： 1）檢索相關資料； 2）返回統計結果； 3）速度要快。

##1.4 ES工作原理 當ElasticSearch的節點啟動後，它會利用多播(multicast)(或者單播，如果使用者更改了配置)尋找叢集中的其它節點，並與之建立連線。這個過程如下圖所示：

##1.5 ES核心概念 ###1）Cluster：叢集。 ES可以作為一個獨立的單個搜尋伺服器。不過，為了處理大型資料集，實現容錯和高可用性，ES可以執行在許多互相合作的伺服器上。這些伺服器的集合稱為叢集。 ###2）Node：節點。 形成叢集的每個伺服器稱為節點。 ###3）Shard：分片。 當有大量的文件時，由於記憶體的限制、磁碟處理能力不足、無法足夠快的響應客戶端的請求等，一個節點可能不夠。這種情況下，資料可以分為較小的分片。每個分片放到不同的伺服器上。 當你查詢的索引分佈在多個分片上時，ES會把查詢傳送給每個相關的分片，並將結果組合在一起，而應用程式並不知道分片的存在。即：這個過程對使用者來說是透明的。 ###4）Replia：副本。 為提高查詢吞吐量或實現高可用性，可以使用分片副本。 副本是一個分片的精確複製，每個分片可以有零個或多個副本。ES中可以有許多相同的分片，其中之一被選擇更改索引操作，這種特殊的分片稱為主分片。 當主分片丟失時，如：該分片所在的資料不可用時，叢集將副本提升為新的主分片。 ###5）全文檢索。 全文檢索就是對一篇文章進行索引，可以根據關鍵字搜尋，類似於mysql裡的like語句。 全文索引就是把內容根據詞的意義進行分詞，然後分別建立索引，例如”你們的激情是因為什麼事情來的” 可能會被分詞成：“你們“，”激情“，“什麼事情“，”來“ 等token，這樣當你搜尋“你們” 或者 “激情” 都會把這句搜出來。

##1.6 ES資料架構的主要概念（與關聯式資料庫Mysql對比）

（1）關係型資料庫中的資料庫（DataBase），等價於ES中的索引（Index） （2）一個資料庫下面有N張表（Table），等價於1個索引Index下面有N多型別（Type）， （3）一個資料庫表（Table）下的資料由多行（ROW）多列（column，屬性）組成，等價於1個Type由多個文件（Document）和多Field組成。 （4）在一個關係型資料庫裡面，schema定義了表、每個表的欄位，還有表和欄位之間的關係。 與之對應的，在ES中：Mapping定義索引下的Type的欄位處理規則，即索引如何建立、索引型別、是否儲存原始索引JSON文件、是否壓縮原始JSON文件、是否需要分詞處理、如何進行分詞處理等。 （5）在資料庫中的增insert、刪delete、改update、查search操作等價於ES中的增PUT/POST、刪Delete、改_update、查GET.

##1.7 ELK是什麼？ ELK=elasticsearch+Logstash+kibana elasticsearch：後臺分散式儲存以及全文檢索 logstash: 日誌加工、“搬運工” kibana：資料視覺化展示。 ELK架構為資料分散式儲存、視覺化查詢和日誌解析建立了一個功能強大的管理鏈。 三者相互配合，取長補短，共同完成分散式大資料處理工作。

#2. ES特點和優勢 1）分散式實時檔案儲存，可將每一個欄位存入索引，使其可以被檢索到。 2）實時分析的分散式搜尋引擎。 分散式：索引分拆成多個分片，每個分片可有零個或多個副本。叢集中的每個資料節點都可承載一個或多個分片，並且協調和處理各種操作； 負載再平衡和路由在大多數情況下自動完成。 3）可以擴充套件到上百臺伺服器，處理PB級別的結構化或非結構化資料。也可以執行在單臺PC上（已測試） 4）支援外掛機制，分詞外掛、同步外掛、Hadoop外掛、視覺化外掛等。

#3、ES效能 ##3.1 效能結果展示 （1）硬體配置： CPU 16核 AuthenticAMD 記憶體 總量：32GB 硬碟 總量：500GB 非SSD

（2）在上述硬體指標的基礎上測試效能如下： 1）平均索引吞吐量： 12307docs/s（每個文件大小：40B/docs） 2）平均CPU使用率： 887.7%（16核，平均每核：55.48%） 3）構建索引大小： 3.30111 GB 4）總寫入量： 20.2123 GB 5）測試總耗時： 28m 54s.

##3.2 效能esrally工具（推薦） 使用參考：blog.csdn.net/laoyang360/…

#4、為什麼要用ES？ ##4.1 ES國內外使用優秀案例 1） 2013年初，GitHub拋棄了Solr，採取ElasticSearch 來做PB級的搜尋。 “GitHub使用ElasticSearch搜尋20TB的資料，包括13億檔案和1300億行程式碼”。

2）維基百科：啟動以elasticsearch為基礎的核心搜尋架構。 3）SoundCloud：“SoundCloud使用ElasticSearch為1.8億使用者提供即時而精準的音樂搜尋服務”。 4）百度：百度目前廣泛使用ElasticSearch作為文字資料分析，採集百度所有伺服器上的各類指標資料及使用者自定義資料，通過對各種資料進行多維分析展示，輔助定位分析例項異常或業務層面異常。目前覆蓋百度內部20多個業務線（包括casio、雲分析、網盟、預測、文庫、直達號、錢包、風控等），單叢集最大100臺機器，200個ES節點，每天匯入30TB+資料。

##4.2 我們也需要 實際專案開發實戰中，幾乎每個系統都會有一個搜尋的功能，當搜尋做到一定程度時，維護和擴充套件起來難度就會慢慢變大，所以很多公司都會把搜尋單獨獨立出一個模組，用ElasticSearch等來實現。

近年ElasticSearch發展迅猛，已經超越了其最初的純搜尋引擎的角色，現在已經增加了資料聚合分析（aggregation）和視覺化的特性，如果你有數百萬的文件需要通過關鍵詞進行定位時，ElasticSearch肯定是最佳選擇。當然，如果你的文件是JSON的，你也可以把ElasticSearch當作一種“NoSQL資料庫”， 應用ElasticSearch資料聚合分析（aggregation）的特性，針對資料進行多維度的分析。

【知乎：熱酷架構師潘飛】ES在某些場景下替代傳統DB 個人以為Elasticsearch作為內部儲存來說還是不錯的，效率也基本能夠滿足，在某些方面替代傳統DB也是可以的，前提是你的業務不對操作的事性務有特殊要求；而許可權管理也不用那麼細，因為ES的許可權這塊還不完善。 由於我們對ES的應用場景僅僅是在於對某段時間內的資料聚合操作，沒有大量的單文件請求（比如通過userid來找到一個使用者的文件，類似於NoSQL的應用場景），所以能否替代NoSQL還需要各位自己的測試。 如果讓我選擇的話，我會嘗試使用ES來替代傳統的NoSQL，因為它的橫向擴充套件機制太方便了。

#5. ES的應用場景是怎樣的？ ##通常我們面臨問題有兩個： 1）新系統開發嘗試使用ES作為儲存和檢索伺服器； 2）現有系統升級需要支援全文檢索服務，需要使用ES。 以上兩種架構的使用，以下連結進行詳細闡述。 blog.csdn.net/laoyang360/…

##一線公司ES使用場景： 1）新浪ES 如何分析處理32億條實時日誌 dockone.io/article/505 2）阿里ES 構建挖財自己的日誌採集和分析體系 afoo.me/columns/tec… 3）有贊ES 業務日誌處理 tech.youzan.com/you-zan-ton… 4）ES實現站內搜尋 www.wtoutiao.com/p/13bkqiZ.h…

#6. 如何部署ES？ ##6.1 ES部署（無需安裝） 1）零配置，開箱即用 2）沒有繁瑣的安裝配置 3）java版本要求：最低1.7 我使用的1.8 [root@laoyang config_lhy]# echo $JAVA_HOME /opt/jdk1.8.0_91 4）下載地址： download.elastic.co/elasticsear… 5）啟動 cd /usr/local/elasticsearch-2.3.5 ./bin/elasticsearch bin/elasticsearch -d(後臺執行)

##6.2 ES必要的外掛 必要的Head、kibana、IK（中文分詞）、graph等外掛的詳細安裝和使用。 blog.csdn.net/column/deta…

##6.3 ES windows下一鍵安裝 自寫bat指令碼實現windows下一鍵安裝。 1）一鍵安裝ES及必要外掛（head、kibana、IK、logstash等） 2）安裝後以服務形式執行ES。 3）比自己摸索安裝節省至少2小時時間，效率非常高。 指令碼說明： blog.csdn.net/laoyang360/…

#7. ES對外介面（開發人員關注） ##1）JAVA API介面 www.ibm.com/developerwo…

##2）RESTful API介面 常見的增、刪、改、查操作實現： blog.csdn.net/laoyang360/…

#8.ES遇到問題怎麼辦？ 1）國外：discuss.elastic.co/ 2）國內：elasticsearch.cn/

#參考： [1] www.tuicool.com/articles/7f… [2] zhaoyanblog.com/archives/49… [3]《Elasticsearch伺服器開發》 [4]《實戰Elasticsearch、Logstash、Kibana》 [5]《Elasticsearch In Action》 [6]《某ES大牛PPT》

#9、還有嗎？ 《死磕 Elasticsearch 方法論》：普通程式設計師高效精進的 10 大狠招！（免費完整版） blog.csdn.net/laoyang360/… —————————————————————————————————— 更多ES相關實戰乾貨經驗分享，請掃描下方【銘毅天下】微信公眾號二維碼關注。 （每週至少更新一篇！）

和你一起，死磕Elasticsearch！ ——————————————————————————————————

2016-08-18 21:10 思於家中床前

作者：銘毅天下 轉載請標明出處，原文地址： blog.csdn.net/laoyang360/… 如果感覺本文對您有幫助，請點選‘頂’支援一下，您的支援是我堅持寫作最大的動力，謝謝！