Elasticsearch之介紹

BigSun丶發表於2024-04-08
Elasticsearch

目錄
  • 一、什麼是ES
  • 二、為什麼會用ES（要有ES）
    • 2.1 大規模資料檢索思考
    • 2.2 採用資料庫的應對解決方案
      • 2.2.1 採用關係型資料庫
      • 2.2.2 採用非關係型資料庫
      • 2.2.3 採用記憶體資料庫
  • 三、ES深入介紹
    • 3.1 Lucene與Elasticsearch關係
    • 3.2 Elasticsearch vs solr
      • 3.2.1 Elasticsearch 與 Solr 的比較總結
    • 3.3 ES的核心概念
      • 3.3.1 Cluster：叢集
      • 3.3.2 Node：節點
      • 3.3.3 Shard：分片
      • 3.3.4 Replia：副本
      • 3.3.5 全文檢索
    • 3.4 與關係型資料庫Mysql對比
    • 3.5 ES邏輯設計（文件-->型別-->索引）
      • 3.5.1 文件
      • 3.5.2 型別
      • 3.5.3 索引
    • 3.6 ES的物理設計
    • 3.7 ELK是什麼
    • 3.8 ES的特點和優勢
  • 四、為什麼使用Elasticsearch
    • 4.1 國內外優秀案例
    • 4.2 我們的業務場景
  • 五、ES索引到底能處理多大資料

一、什麼是ES

  • ES，即Elasticsearch是一個基於Lucene的分散式搜尋和分析引擎
  • Elasticsearch是一個開源的高擴充套件的分散式全文檢索引擎，它可以近乎實時的儲存、檢索資料；本身擴充套件性很好，可以擴充套件到上百臺伺服器，處理PB級別的資料。
  • Elasticsearch使用Java開發，在Apache許可條款下開放原始碼釋出，是當前流行的企業級搜尋引擎。設計用於雲端計算中，能夠達到實時搜尋，穩定，可靠，快速，安裝使用方便
  • 使用Lucene作為其核心來實現所有索引和搜尋的功能，但是它的目的是透過簡單的RESTful API來隱藏Lucene的複雜性，使得全文檢索變得簡單
  • 設計用途：用於分散式全文檢索，透過HTTP使用JSON進行資料索引，速度快

二、為什麼會用ES（要有ES）

  • 我們有個疑問：在大規模資料中要如何快速的檢索，基於這個問題，由此引出如下思考

2.1 大規模資料檢索思考

  • 當系統資料量上了10億、100億條的時候，我們在做系統架構的時候通常會從以下角度去考慮問題：
    1）用什麼資料庫好？(mysql、oracle、mongodb、hbase…)
    2）如何解決單點故障；(lvs、F5、A10、Zookeeper、MQ)
    3）如何保證資料安全性；(熱備、冷備、異地多活)
    4）如何解決檢索難題；(資料庫代理中介軟體：mysql-proxy、Cobar、MaxScale等;)
    5）如何解決統計分析問題；(離線、近實時)

2.2 採用資料庫的應對解決方案

2.2.1 採用關係型資料庫

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

2.2.2 採用非關係型資料庫

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

2.2.3 採用記憶體資料庫

  • 完全把資料放在記憶體中是不可靠的，實際上也不太現實，當我們的資料達到PB級別時，按照每個節點96G記憶體計算，在記憶體完全裝滿的資料情況下，我們需要的機器是：1PB=1024T=1048576G。節點數=1048576/96=10922個
  • 實際上，考慮到資料備份，節點數往往在2.5萬臺左右。成本巨大決定了其不現實！所以把資料放在記憶體也好，不放在記憶體也好，都不能完完全全解決問題。
  • 全部放在記憶體速度問題是解決了，但成本問題上來了。
  • 為解決以上問題，從源頭著手分析，通常會從以下方式來尋找方法：
    1、儲存資料時按有序儲存；
    2、將資料和索引分離；
    3、壓縮資料；
  • 這就引出了Elasticsearch

三、ES深入介紹

3.1 Lucene與Elasticsearch關係

  • 在上面的第一節中已經提到了：使用Lucene作為其核心來實現所有索引和搜尋的功能，但是它的目的是透過簡單的RESTful API來隱藏Lucene的複雜性，使得全文檢索變得簡單。那麼什麼是Lucene呢
    • 1）Lucene只是一個庫。想要使用它，你必須使用Java來作為開發語言並將其直接整合到你的應用中，更糟糕的是，Lucene非常複雜，你需要深入瞭解檢索的相關知識來理解它是如何工作的。
    • 2）Elasticsearch也使用Java開發並使用Lucene作為其核心來實現所有索引和搜尋的功能，但是它的目的是透過簡單的RESTful API來隱藏Lucene的複雜性，從而讓全文搜尋變得簡單

3.2 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有一個外掛架構，以支援更多的高階定製

3.2.1 Elasticsearch 與 Solr 的比較總結

  1. 二者安裝都很簡單
  2. Solr 利用 Zookeeper 進行分散式管理，而 Elasticsearch 自身帶有分散式協調管理功能
  3. Solr 支援更多格式的資料，而 Elasticsearch 僅支援json檔案格式
  4. Solr 官方提供的功能更多，而 Elasticsearch 本身更注重於核心功能，高階功能多有第三方外掛提供
  5. Solr 在傳統的搜尋應用中表現好於 Elasticsearch，但在處理實時搜尋應用時效率明顯低於 Elasticsearch
  6. Solr 是傳統搜尋應用的有力解決方案，但 Elasticsearch 更適用於新興的實時搜尋應用

3.3 ES的核心概念

  • ES共有5大核心概念：
    • Cluster：叢集
    • Node：節點
    • Shard：分片
    • Replia：副本
    • 全文檢索

3.3.1 Cluster：叢集

  • ES可以作為一個獨立的單個搜尋伺服器。不過，為了處理大型資料集，實現容錯和高可用性，ES可以執行在許多互相合作的伺服器上。這些伺服器的集合稱為叢集

3.3.2 Node：節點

  • 形成叢集的每個伺服器稱為節點

3.3.3 Shard：分片

  • 當有大量的文件時，由於記憶體的限制、磁碟處理能力不足、無法足夠快的響應客戶端的請求等，一個節點可能不夠。這種情況下，資料可以分為較小的分片。每個分片放到不同的伺服器上。
  • 當你查詢的索引分佈在多個分片上時，ES會把查詢傳送給每個相關的分片，並將結果組合在一起，而應用程式並不知道分片的存在。即：這個過程對使用者來說是透明的

3.3.4 Replia：副本

  • 為提高查詢吞吐量或實現高可用性，可以使用分片副本。
  • 副本是一個分片的精確複製，每個分片可以有零個或多個副本。ES中可以有許多相同的分片，它們中的其中一個會被選擇更改索引操作，這種特殊的分片稱為主分片。
  • 當主分片丟失時，如：該分片所在的資料不可用時，叢集將副本提升為新的主分片

3.3.5 全文檢索

  • 全文檢索就是對一篇文章進行索引，可以根據關鍵字搜尋，類似於mysql裡的like語句。
  • 全文索引就是把內容根據詞的意義進行分詞，然後分別建立索引，例如”今日是週日我們出去玩” 可能會被分詞成：“今天“，”週日“，“我們“，”出去玩“ 等token，這樣當你搜尋“週日” 或者 “出去玩” 都會把這句搜出來

3.4 與關係型資料庫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

3.5 ES邏輯設計（文件-->型別-->索引）

  • 一個索引型別中，包含多個文件，比如說文件1，文件2。
  • 當我們索引一篇文件時，可以透過這樣的順序找到它：索引▷型別▷文件ID，透過這個組合我們就能索引到某個具體的文件。
    • 注意：ID不必是整數，實際上它是個字串

3.5.1 文件

  • 之前說elasticsearch是面向文件的，那麼就意味著索引和搜尋資料的最小單位是文件，elasticsearch中，文件有幾個重要屬性：

    • 自我包含，一篇文件同時包含欄位和對應的值，也就是同時包含key:value

    • 可以是層次型的，一個文件中包含文件，複雜的邏輯實體就是這麼來的

    • 靈活的結構，文件不依賴預先定義的模式，我們知道關係型資料庫中，要提前定義欄位才能使用，在elasticsearch中，對於欄位是非常靈活的，有時候，我們可以忽略該欄位，或者動態的新增一個新的欄位。

    • 文件是無模式的，也就是說，欄位對應值的型別可以是不限型別的。

  • 儘管我們可以隨意的新增或者忽略某個欄位，但是，每個欄位的型別非常重要，比如一個年齡欄位型別，可以是字串也可以是整型。因為elasticsearch會儲存欄位和型別之間的對映及其他的設定。這種對映具體到每個對映的每種型別，這也是為什麼在elasticsearch中，型別有時候也稱為對映型別

3.5.2 型別

  • 型別是文件的邏輯容器，就像關係型資料庫一樣，表格是行的容器。
  • 型別中對於欄位的定義稱為對映，比如name對映為字串型別。
  • 我們說文件是無模式的，它們不需要擁有對映中所定義的所有欄位，比如新增一個欄位，那麼elasticsearch是怎麼做的呢
    • elasticsearch會自動的將新欄位加入對映，但是這個欄位的不確定它是什麼型別，elasticsearch就開始猜，如果這個值是18，那麼elasticsearch會認為它是整型。
    • 但是elasticsearch也可能猜不對，所以最安全的方式就是提前定義好所需要的對映，這點跟關係型資料庫殊途同歸了，先定義好欄位，然後再使用，別整什麼么蛾子。後面在討論更多關於對映的東西

3.5.3 索引

  • 索引是對映型別的容器，elasticsearch中的索引是一個非常大的文件集合。索引儲存了對映型別的欄位和其他設定。然後它們被儲存到了各個分片上了

3.6 ES的物理設計

ES叢集的簡單示例

  • 一個叢集包含至少一個節點，而一個節點就是一個elasticsearch程序。節點內可以有多個索引。

  • 每個索引會被分成多個分片shards進行儲存，elasticsearch預設建立索引是分配5個主分片進行儲存（需要注意的是es7.0預設索引分片數調整為1了），而每個分片又有一個副本（replica shard，又稱複製分片），這樣，就有了10個分片。上圖只是展示了ES叢集的簡單樣例

  • 分片的建立多少比較合適：分片可以按照叢集的數量相乘5，例如有2臺叢集，那麼分片設定的數量為10（number_of_shards）是比較合適，分片會均勻分配到所有的叢集，每個叢集節點都有5主5副的分片，共10主，10副。

  • 預設標準是每個節點5個分片。

    • 為什麼是每個節點單個索引最多五個分片？這是因為es官方為了保證節點的安全，而去設定的一個限制。一次檢索，單個索引在一個節點上命中的分片數只能有5個。假如單個節點大於5個分片，則需要序列去處理資料了

  • 那麼這個索引是如何儲存在叢集中的呢？

  • 圖中有3個節點的叢集，可以看到主分片和對應的複製分片都不會在同一個節點內，這樣有利於某個節點掛掉了，資料也不至於丟失。

  • 實際上，一個分片是一個Lucene索引，一個包含倒排索引的檔案目錄，倒排索引的結構使得elasticsearch在不掃描全部文件的情況下，就能告訴你哪些文件包含特定的關鍵字

3.7 ELK是什麼

  • ELK=elasticsearch+Logstash+kibana

  • elasticsearch：後臺分散式儲存以及全文檢索

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

    • kibana：資料視覺化展示。

  • ELK架構為資料分散式儲存、視覺化查詢和日誌解析建立了一個功能強大的管理鏈。 三者相互配合，取長補短，共同完成分散式大資料處理工作。

3.8 ES的特點和優勢

  • 1）分散式實時檔案儲存，可將每一個欄位存入索引，使其可以被檢索到。

  • 2）實時分析的分散式搜尋引擎。

    • 分散式：索引分拆成多個分片，每個分片可有零個或多個副本。叢集中的每個資料節點都可承載一個或多個分片，並且協調和處理各種操作；
    • 負載再平衡和路由在大多數情況下自動完成。

  • 3）可以擴充套件到上百臺伺服器，處理PB級別的結構化或非結構化資料。也可以執行在單臺PC上（已測試）

  • 4）支援外掛機制，分詞外掛、同步外掛、Hadoop外掛、視覺化外掛等。

四、為什麼使用Elasticsearch

4.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 業務日誌處理

4.2 我們的業務場景

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

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

  • 嘗試使用ES來替代傳統的NoSQL，它的橫向擴充套件機制太方便了

  • 應用場景：

    • 新系統開發嘗試使用ES作為儲存和檢索伺服器；
    • 現有系統升級需要支援全文檢索服務，需要使用ES

五、ES索引到底能處理多大資料

  • 單一索引的極限取決於儲存索引的硬體、索引的設計、如何處理資料以及你為索引備份了多少副本。

  • 通常來說，一個Lucene索引（也就是一個elasticsearch分片，一個es索引預設5個分片）不能處理多於21億篇文件，或者多於2740億的唯一詞條。但達到這個極限之前，我們可能就沒有足夠的磁碟空間了！當然，一個分片如何很大的話，讀寫效能將會變得非常差

相關文章