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工具（推薦）
使用參考：
https://developer.aliyun.com/article/708200?spm=5176.8068049.0.0.7f0d6d19EqcuVV4. 為什麼要用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。
以上兩種架構的使用，以下連結進行詳細闡述。
http://blog.csdn.net/laoyang360/article/details/52227541一線公司ES使用場景：
1）新浪ES 如何分析處理32億條實時日志
http://dockone.io/article/5052）阿裡ES 建構挖财自己的日志采集和分析體系
http://afoo.me/columns/tec/logging-platform-spec.html3）有贊ES 業務日志處理
http://tech.youzan.com/you-zan-tong-ri-zhi-ping-tai-chu-tan/4）ES實作站内搜尋
http://www.wtoutiao.com/p/13bkqiZ.html6. 如何部署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）下載下傳位址：
https://download.elastic.co/elasticsearch/release/org/elasticsearch/distribution/zip/elasticsearch/2.3.5/elasticsearch-2.3.5.zip5）啟動
cd /usr/local/elasticsearch-2.3.5
./bin/elasticsearch
bin/elasticsearch -d(背景運作)
6.2 ES必要的插件
必要的Head、kibana、IK（中文分詞）、graph等插件的詳細安裝和使用。
http://blog.csdn.net/column/details/deep-elasticsearch.html6.3 ES windows下一鍵安裝
自寫bat腳本實作windows下一鍵安裝。
1）一鍵安裝ES及必要插件（head、kibana、IK、logstash等）
2）安裝後以服務形式運作ES。
3）比自己摸索安裝節省至少2小時時間，效率非常高。
腳本說明：
http://blog.csdn.net/laoyang360/article/details/519002357. ES對外接口（開發人員關注）
1）JAVA API接口
http://www.ibm.com/developerworks/library/j-use-elasticsearch-java-apps/index.html2）RESTful API接口
常見的增、删、改、查操作實作：
http://blog.csdn.net/laoyang360/article/details/519319818.ES遇到問題怎麼辦？
1）國外：
https://discuss.elastic.co/2）國内：
http://elasticsearch.cn/參考：
[1]
http://www.tuicool.com/articles/7fueUbb[2]
http://zhaoyanblog.com/archives/495.html[3]《Elasticsearch伺服器開發》
[4]《實戰Elasticsearch、Logstash、Kibana》
[5]《Elasticsearch In Action》
[6]《某ES大牛PPT》
9.還有嗎？
《死磕 Elasticsearch 方法論》：普通程式員高效精進的 10 大狠招！（免費完整版）
https://blog.csdn.net/laoyang360/article/details/79293493——————————————————————————————————
和你一起，死磕Elasticsearch！
——————————————————————————————————
2016-08-18 21:10 思于家中床前
作者：銘毅天下
轉載請标明出處，原文位址：
http://blog.csdn.net/laoyang360/article/details/52244917如果感覺本文對您有幫助，請點選‘頂’支援一下，您的支援是我堅持寫作最大的動力，謝謝！
來源：CSDN
原文：
https://blog.csdn.net/laoyang360/article/details/52244917版權聲明：本文為部落客原創文章，轉載請附上博文連結！