ES學習第一篇

一、ES的產生

1.1 大批量數據如何檢索

問題:當系統數據量上了10億條的時候,我們通常會從以下角度去考慮問題:

  1. 用什麼數據庫好?(mysql、oracle、mongodb、hbase…)
  2. 如何解決單點故障;(zk、mq)
  3. 如何保證數據安全性;(熱備、冷備)
  4. 如何解決檢索難題;(數據庫代理中間件:mysql-proxy、Cobar、MaxScale等;)
  5. 如何解決統計分析問題;(離線、近實時)

1.2 傳統數據庫是如何解決的?

對於關係型數據,我們通常採用以下或類似架構去解決查詢瓶頸和寫入瓶頸:

解決要點:

  1. 通過主從備份解決數據安全性問題;
  2. 通過數據庫代理中間件心跳監測,解決單點故障問題;
  3. 通過代理中間件將查詢語句分發到各個slave節點進行查詢,並彙總結果

在這裏插入圖片描述

1.3 非關係型數據庫是如何解決的?

對於Nosql數據庫,以mongodb爲例,其它原理類似:

解決要點:

  1. 通過副本備份保證數據安全性;
  2. 通過節點競選機制解決單點問題;
  3. 先從配置庫檢索分片信息,然後將請求分發到各個節點,最後由路由節點合併彙總結果

在這裏插入圖片描述

1.4 如果把數據都放到內存中會怎樣?

衆所周知,內存運算速度快,數據都放內存中,效率會大大提升。但很明顯,不現實:

當我們的數據達到PB級別時,按照每個節點96G內存計算,在內存完全裝滿的數據情況下,我們需要的機器是:1PB=1024T=1048576G
節點數=1048576/96=10922個
實際上,考慮到數據備份,節點數往往在2.5萬臺左右。成本巨大決定了其不現實!

爲解決以上問題,從源頭着手分析,通常會從以下方式來尋找方法:

  1. 存儲數據時按有序存儲;
  2. 將數據和索引分離;
  3. 壓縮數據;

這就引出了Elasticsearch。

二、ES基礎

2.1 ES定義

ES=elaticsearch簡寫, Elasticsearch是一個開源的高擴展的分佈式全文檢索引擎,它可以近乎實時的存儲、檢索數據;本身擴展性很好,可以擴展到上百臺服務器,處理PB級別的數據。

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

2.2 Lucene與ES關係

  • Lucene只是一個庫。想要使用它,你必須使用Java來作爲開發語言並將其直接集成到你的應用中,更糟糕的是,Lucene非常複雜,你需要深入瞭解檢索的相關知識來理解它是如何工作的。
  • Elasticsearch也使用Java開發並使用Lucene作爲其核心來實現所有索引和搜索的功能,但是它的目的是通過簡單的RESTful API來隱藏Lucene的複雜性,從而讓全文搜索變得簡單。

2.3 ES能解決什麼

  1. 檢索相關數據;
  2. 返回統計結果;
  3. 速度要快。

2.4 工作原理

當ElasticSearch的節點啓動後,它會利用多播(或者單播,如果用戶更改了配置)尋找集羣中的其它節點,並與之建立連接。這個過程如下圖所示:

在這裏插入圖片描述

2.5 ES核心概念

1、Cluster:集羣

ES可以作爲一個獨立的單個搜索服務器。不過,爲了處理大型數據集,實現容錯和高可用性,ES可以運行在許多互相合作的服務器上。這些服務器的集合稱爲集羣。

2、Node:節點

形成集羣的每個服務器稱爲節點。

3、Shard:分片

當有大量的文檔時,由於內存的限制、磁盤處理能力不足、無法足夠快的響應客戶端的請求等,一個節點可能不夠。這種情況下,數據可以分爲較小的分片。每個分片放到不同的服務器上。
當你查詢的索引分佈在多個分片上時,ES會把查詢發送給每個相關的分片,並將結果組合在一起,而應用程序並不知道分片的存在。即:這個過程對用戶來說是透明的。

4、Replia:副本

爲提高查詢吞吐量或實現高可用性,可以使用分片副本。
副本是一個分片的精確複製,每個分片可以有零個或多個副本。ES中可以有許多相同的分片,其中之一被選擇更改索引操作,這種特殊的分片稱爲主分片。
當主分片丟失時,如:該分片所在的數據不可用時,集羣將副本提升爲新的主分片。

5、全文檢索

全文檢索就是對一篇文章進行索引,可以根據關鍵字搜索,類似於mysql裏的like語句。
全文索引就是把內容根據詞的意義進行分詞,然後分別創建索引,例如”你們的激情是因爲什麼事情來的” 可能會被分詞成:“你們“,”激情“,“什麼事情“,”來“ 等token,這樣當你搜索“你們” 或者 “激情” 都會把這句搜出來。

2.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.

2.7 ELK是什麼

ELK=elasticsearch+Logstash+kibana

elasticsearch:後臺分佈式存儲以及全文檢索

logstash: 日誌加工、“搬運工”

kibana:數據可視化展示。

ELK架構爲數據分佈式存儲、可視化查詢和日誌解析創建了一個功能強大的管理鏈。 三者相互配合,取長補短,共同完成分佈式大數據處理工作。

三、ES特點和優勢

  1. 分佈式實時文件存儲,可將每一個字段存入索引,使其可以被檢索到。
  2. 實時分析的分佈式搜索引擎。
    分佈式:索引分拆成多個分片,每個分片可有零個或多個副本。集羣中的每個數據節點都可承載一個或多個分片,並且協調和處理各種操作;
    負載再平衡和路由在大多數情況下自動完成。
  3. 可以擴展到上百臺服務器,處理PB級別的結構化或非結構化數據。也可以運行在單臺PC上(已測試)
  4. 支持插件機制,分詞插件、同步插件、Hadoop插件、可視化插件等。

四、ES性能

4.1 性能結果展示

硬件配置:

CPU 16核 AuthenticAMD
內存 總量:32GB
硬盤 總量:500GB 非SSD

在上述硬件的基礎上測試性能如下:

平均索引吞吐量: 12307docs/s(每個文檔大小:40B/docs)
平均CPU使用率: 887.7%(16核,平均每核:55.48%)
構建索引大小: 3.30111 GB
總寫入量: 20.2123 GB
測試總耗時: 28m 54s.

五、爲什麼要用ES?

5.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+數據。

5.2 我們的需求

實際項目開發實戰中,幾乎每個系統都會有一個搜索的功能,當搜索做到一定程度時,維護和擴展起來難度就會慢慢變大,所以很多公司都會把搜索單獨獨立出一個模塊,用ElasticSearch等來實現。

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

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

六、ES的應用場景是怎樣的?

6.1 問題有兩個:

1)新系統開發嘗試使用ES作爲存儲和檢索服務器;
2)現有系統升級需要支持全文檢索服務,需要使用ES。

七、ES的部署

7.1 linux下的安裝

  1. 零配置,開箱即用
  2. 沒有繁瑣的安裝配置
  3. java版本要求:最低1.7,我使用的1.8
  4. 下載地址: https://www.elastic.co/cn/downloads
  5. 啓動
    cd /usr/local/elasticsearch-2.3.5
    ./bin/elasticsearch
    bin/elasticsearch -d(後臺運行)

7.2 ES windows下一鍵安裝

自寫bat腳本實現windows下一鍵安裝。
1)一鍵安裝ES及必要插件(head、kibana、IK、logstash等)
2)安裝後以服務形式運行ES。
3)比自己摸索安裝節省至少2小時時間,效率非常高。

八、ES對外接口(開發人員關注)

8.1 JAVA API接口

http://www.ibm.com/developerworks/library/j-use-elasticsearch-java-apps/index.html

8.2 RESTful API接口

常見的增、刪、改、查操作實現:

http://blog.csdn.net/laoyang360/article/details/51931981

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章