00-ElasticSearch之-介紹
ElasticSearch之介紹
一 Elasticsearch產生背景
1.1 大規模資料如何檢索
如:當系統資料量上了10億、100億條的時候,我們在做系統架構的時候通常會從以下角度去考慮問題:
1)用什麼資料庫好?(mysql、oracle、mongodb、hbase…)
2)如何解決單點故障;(lvs、F5、A10、Zookeeper、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
二 Elasticsearch介紹
2.1Elasticsearch是什麼
Elasticsearch 是一個基於Lucene的分散式搜尋和分析引擎。
ES是elaticsearch簡寫, Elasticsearch是一個開源的高擴充套件的分散式全文檢索引擎,它可以近乎實時的儲存、檢索資料;本身擴充套件性很好,可以擴充套件到上百臺伺服器,處理PB級別的資料。
Elasticsearch使用Java開發,在Apache許可條款下開放原始碼釋出,是當前流行的企業級搜尋引擎。設計用於雲端計算中,能夠達到實時搜尋,穩定,可靠,快速,安裝使用方便
使用Lucene作為其核心來實現所有索引和搜尋的功能,但是它的目的是通過簡單的RESTful API來隱藏Lucene的複雜性,使得全文檢索變得簡單
設計用途:用於分散式全文檢索,通過HTTP使用JSON進行資料索引,速度快
2.2 Lucene與Elasticsearch關係
1)Lucene只是一個庫。想要使用它,你必須使用Java來作為開發語言並將其直接整合到你的應用中,更糟糕的是,Lucene非常複雜,你需要深入瞭解檢索的相關知識來理解它是如何工作的。
2)Elasticsearch也使用Java開發並使用Lucene作為其核心來實現所有索引和搜尋的功能,但是它的目的是通過簡單的RESTful API來隱藏Lucene的複雜性,從而讓全文搜尋變得簡單。
2.3 Elasticsearch vs solr
1)Solr是Apache Lucene專案的開源企業搜尋平臺。其主要功能包括全文檢索、命中標示、分面搜尋、動態聚類、資料庫整合,以及富文字(如Word、PDF)的處理。
2)Solr是高度可擴充套件的,並提供了分散式搜尋和索引複製。Solr是最流行的企業級搜尋引擎,Solr4 還增加了NoSQL支援。
3)Solr是用Java編寫、執行在Servlet容器(如 Apache Tomcat 或Jetty)的一個獨立的全文搜尋伺服器。 Solr採用了 Lucene Java 搜尋庫為核心的全文索引和搜尋,並具有類似REST的HTTP/XML和JSON的API。
4)Solr強大的外部配置功能使得無需進行Java編碼,便可對 其進行調整以適應多種型別的應用程式。Solr有一個外掛架構,以支援更多的高階定製
Elasticsearch 與 Solr 的比較總結
- 二者安裝都很簡單
- Solr 利用 Zookeeper 進行分散式管理,而 Elasticsearch 自身帶有分散式協調管理功能
- Solr 支援更多格式的資料,而 Elasticsearch 僅支援json檔案格式
- Solr 官方提供的功能更多,而 Elasticsearch 本身更注重於核心功能,高階功能多有第三方外掛提供
- Solr 在傳統的搜尋應用中表現好於 Elasticsearch,但在處理實時搜尋應用時效率明顯低於 Elasticsearch
- Solr 是傳統搜尋應用的有力解決方案,但 Elasticsearch 更適用於新興的實時搜尋應用
2.4 Elasticsearch核心概念
2.4.1 Cluster:叢集
ES可以作為一個獨立的單個搜尋伺服器。不過,為了處理大型資料集,實現容錯和高可用性,ES可以執行在許多互相合作的伺服器上。這些伺服器的集合稱為叢集。
2.4.2 Node:節點
形成叢集的每個伺服器稱為節點。
2.4.3 Shard:分片
當有大量的文件時,由於記憶體的限制、磁碟處理能力不足、無法足夠快的響應客戶端的請求等,一個節點可能不夠。這種情況下,資料可以分為較小的分片。每個分片放到不同的伺服器上。
當你查詢的索引分佈在多個分片上時,ES會把查詢傳送給每個相關的分片,並將結果組合在一起,而應用程式並不知道分片的存在。即:這個過程對使用者來說是透明的。
2.4.4 Replia:副本
為提高查詢吞吐量或實現高可用性,可以使用分片副本。
副本是一個分片的精確複製,每個分片可以有零個或多個副本。ES中可以有許多相同的分片,其中之一被選擇更改索引操作,這種特殊的分片稱為主分片。
當主分片丟失時,如:該分片所在的資料不可用時,叢集將副本提升為新的主分片。
2.4.5 全文檢索
全文檢索就是對一篇文章進行索引,可以根據關鍵字搜尋,類似於mysql裡的like語句。
全文索引就是把內容根據詞的意義進行分詞,然後分別建立索引,例如”今日是週日我們出去玩” 可能會被分詞成:“今天“,”週日“,“我們“,”出去玩“ 等token,這樣當你搜索“週日” 或者 “出去玩” 都會把這句搜出來。
2.5 與關係型資料庫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
2.6 ES邏輯設計(文件-->型別-->索引)
一個索引型別中,包含多個文件,比如說文件1,文件2。
當我們索引一篇文件時,可以通過這樣的順序找到它:索引
▷型別
▷文件ID
,通過這個組合我們就能索引到某個具體的文件。
注意:ID不必是整數,實際上它是個字串。
文件
之前說elasticsearch是面向文件的,那麼就意味著索引和搜尋資料的最小單位是文件,elasticsearch中,文件有幾個重要屬性:
- 自我包含,一篇文件同時包含欄位和對應的值,也就是同時包含
key:value
- 可以是層次型的,一個文件中包含自文件,複雜的邏輯實體就是這麼來的
- 靈活的結構,文件不依賴預先定義的模式,我們知道關係型資料庫中,要提前定義欄位才能使用,在elasticsearch中,對於欄位是非常靈活的,有時候,我們可以忽略該欄位,或者動態的新增一個新的欄位。
- 文件是無模式的,也就是說,欄位對應值的型別可以是不限型別的。
儘管我們可以隨意的新增或者忽略某個欄位,但是,每個欄位的型別非常重要,比如一個年齡欄位型別,可以是字串也可以是整型。因為elasticsearch會儲存欄位和型別之間的對映及其他的設定。這種對映具體到每個對映的每種型別(詳見擴充套件閱讀:17-擴充套件閱讀-刪除對映型別.md),這也是為什麼在elasticsearch中,型別有時候也稱為對映型別。
型別
型別是文件的邏輯容器,就像關係型資料庫一樣,表格是行的容器。
型別中對於欄位的定義稱為對映,比如name
對映為字串型別。
我們說文件是無模式的,它們不需要擁有對映中所定義的所有欄位,比如新增一個欄位,那麼elasticsearch是怎麼做的呢?elasticsearch會自動的將新欄位加入對映,但是這個欄位的不確定它是什麼型別,elasticsearch就開始猜,如果這個值是18,那麼elasticsearch會認為它是整型。
但是elasticsearch也可能猜不對,所以最安全的方式就是提前定義好所需要的對映,這點跟關係型資料庫殊途同歸了,先定義好欄位,然後再使用,別整什麼么蛾子。後面在討論更多關於對映的東西。
索引
索引是對映型別的容器,elasticsearch中的索引是一個非常大的文件集合。索引儲存了對映型別的欄位和其他設定。然後它們被儲存到了各個分片上了。
2.7 ES物理設計
一個叢集包含至少一個節點,而一個節點就是一個elasticsearch程序。節點內可以有多個索引。
預設的,如果你建立一個索引,那麼這個索引將會有5個分片(primary shard,又稱主分片)構成,而每個分片又有一個副本(replica shard,又稱複製分片),這樣,就有了10個分片。
那麼這個索引是如何儲存在叢集中的呢?
圖中有3個節點的叢集,可以看到主分片和對應的複製分片都不會在同一個節點內,這樣有利於某個節點掛掉了,資料也不至於丟失。
實際上,一個分片是一個Lucene索引,一個包含倒排索引的檔案目錄,倒排索引的結構使得elasticsearch在不掃描全部文件的情況下,就能告訴你哪些文件包含特定的關鍵字
2.6 ELK是什麼
ELK=elasticsearch+Logstash+kibana
elasticsearch:後臺分散式儲存以及全文檢索
logstash: 日誌加工、“搬運工”
kibana:資料視覺化展示。
ELK架構為資料分散式儲存、視覺化查詢和日誌解析建立了一個功能強大的管理鏈。 三者相互配合,取長補短,共同完成分散式大資料處理工作。
2.7 Elasticsearch特點和優勢
1)分散式實時檔案儲存,可將每一個欄位存入索引,使其可以被檢索到。
2)實時分析的分散式搜尋引擎。
分散式:索引分拆成多個分片,每個分片可有零個或多個副本。叢集中的每個資料節點都可承載一個或多個分片,並且協調和處理各種操作;
負載再平衡和路由在大多數情況下自動完成。
3)可以擴充套件到上百臺伺服器,處理PB級別的結構化或非結構化資料。也可以執行在單臺PC上(已測試)
4)支援外掛機制,分詞外掛、同步外掛、Hadoop外掛、視覺化外掛等。
三 為什麼使用Elasticsearch
3.1 國內外優秀案例
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)新浪ES 如何分析處理32億條實時日誌
6)阿里ES 構建挖財自己的日誌採集和分析體系
7)有贊ES 業務日誌處理
3.2 我們的業務場景
實際專案開發實戰中,幾乎每個系統都會有一個搜尋的功能,當搜尋做到一定程度時,維護和擴充套件起來難度就會慢慢變大,所以很多公司都會把搜尋單獨獨立出一個模組,用ElasticSearch等來實現。
近年ElasticSearch發展迅猛,已經超越了其最初的純搜尋引擎的角色,現在已經增加了資料聚合分析(aggregation)和視覺化的特性,如果你有數百萬的文件需要通過關鍵詞進行定位時,ElasticSearch肯定是最佳選擇。當然,如果你的文件是JSON的,你也可以把ElasticSearch當作一種“NoSQL資料庫”, 應用ElasticSearch資料聚合分析(aggregation)的特性,針對資料進行多維度的分析。
嘗試使用ES來替代傳統的NoSQL,它的橫向擴充套件機制太方便了
應用場景:
1)新系統開發嘗試使用ES作為儲存和檢索伺服器;
2)現有系統升級需要支援全文檢索服務,需要使用ES
四 Elasticsearch索引到底能處理多大資料
單一索引的極限取決於儲存索引的硬體、索引的設計、如何處理資料以及你為索引備份了多少副本。
通常來說,一個Lucene索引(也就是一個elasticsearch分片,一個es索引預設5個分片)不能處理多於21億篇文件,或者多於2740億的唯一詞條。但達到這個極限之前,我們可能就沒有足夠的磁碟空間了!
當然,一個分片如何很大的話,讀寫效能將會變得非常差