ElasticSearch入門(一)主要概念彙總

背景

最近項目中須要作一些大數據的全文檢索功能,之前項目中都是基於 Lucene 進行的開發。而隨着互聯網技術架構的發展,近幾年搜索引擎技術發展迅速,其中ElasticSearch進行技術的預演。 的熱度一直都在搜索引擎排在前面,它的實時搜索、穩定、分佈式、REST API 封裝都是它的特色。結合網上其餘資料對比,這個項目也打算使用 ElasticSearch 進行技術的預演。node

預演步驟

既然技術選型已經肯定,接下來就是圍繞這個目標進行一步一步的任務細化。並且由於時間線不能拉太長,因此目前是先可以和業務集成,對應一些底層的集羣、分片等原理性的內容,放到最後再去深刻了解。web

  1. 瞭解 ElasticSearch 基本概念,基本原理
  2. 瞭解 ElasticSearch 基本使用方法,如何安裝、建立索引、檢索,分佈式等。
  3. 和實際業務結合,開發集成 ElasticSearch 。
  4. 瞭解 ElasticSearch 更多細節的東西,優化,擴展等。

本文主要介紹一些 ElasticSearch 基本概念,以及和 Apache solr 的一些對比。數據庫

基本概念

什麼是elasticsearch?

ElasticSearch是一個基於Lucene的搜索服務器。它提供了一個分佈式多用戶能力的全文搜索引擎,基於RESTful web接口。Elasticsearch是用Java開發的,並做爲Apache許可條款下的開放源碼發佈,是當前流行的企業級搜索引擎。設計用於雲計算中,可以達到實時搜索,穩定,可靠,快速,安裝使用方便。-----百度百科json

爲何會用到elasticsearch?

涉及到like的大數據量模糊查詢,若是是直接對數據庫進行查詢的話,因爲like模糊查詢沒法對數據列應用索引,因此須要一條條字符串進行比對查詢,效率很是低下。因此在Java中,解決大數據量的模糊查詢,就會用到創建索引庫,全文檢索的查詢技術。服務器

Elasticsearch中的幾個核心概念

全文檢索

全文搜索引擎是目前普遍應用的主流搜索引擎。它的工做原理是計算機索引程序經過掃描文章中的每個詞,對每個詞創建一個索引,指明該詞在文章中出現的次數和位置,當用戶查詢時,檢索程序就根據事先創建的索引進行查找,並將查找的結果反饋給用戶的檢索方式。這個過程相似於經過字典中的檢索字表查字的過程。-----百度百科網絡

全文索引

採用分詞器,對文本每一個詞進行切分,創建詞條,方便進行查找數據結構

索引(index)

一個索引就是一個擁有幾分類似特徵的文檔的集合。好比說,你能夠有一個客戶數據的索引,另外一個產品目錄的索引,還有一個訂單數據的索引。一個索引由一個名字來標識(必須所有是小寫字母的),而且當咱們要對對應於這個索引中的文檔進行索引、搜索、更新和刪除的時候,都要使用到這個名字。在一個集羣中,若是你想,能夠定義任意多的索引。 這裏索引至關於關係型數據庫中的庫。架構

倒排索引

也常被稱爲反向索引,是一種索引方法,被用來存儲在全文搜索下某個單詞在一個文檔或者一組文檔中的存儲位置的映射。它是文檔檢索系統中最經常使用的數據結構。經過倒排索引,能夠根據單詞快速獲取包含這個單詞的文檔列表。倒排索引主要由兩個部分組成:「單詞詞典」和「倒排文件」。源於實際應用中須要根據屬性的值來查找記錄。這種索引表中的每一項都包括一個屬性值和具備該屬性值的各記錄的地址。因爲不是由記錄來肯定屬性值,而是由屬性值來肯定記錄的位置,於是稱爲倒排索引(inverted index)。帶有倒排索引的文件咱們稱爲倒排索引文件,簡稱倒排文件(inverted file)。這裏的倒排索引至關於關係型數據庫中的索引elasticsearch

類型(type)

在一個索引中,你能夠定義一種或多種類型。一個類型是你的索引的一個邏輯上的分類/分區,其語義徹底由你來定。一般,會爲具備一組共同字段的文檔定義一個類型。好比說,咱們假設你運營一個博客平臺而且將你全部的數據存儲到一個索引中。在這個索引中,你能夠爲用戶數據定義一個類型,爲博客數據定義另外一個類型,固然,也能夠爲評論數據定義另外一個類型。這裏的類型至關於關係型數據庫中的表分佈式

文檔(document)

一個文檔是一個可被索引的基礎信息單元。好比,你能夠擁有某一個客戶的文檔,某一個產品的一個文檔,固然,也能夠擁有某個訂單的一個文檔。文檔以JSON(Javascript Object Notation)格式來表示,而JSON是一個處處存在的互聯網數據交互格式。在一個index/type裏面,只要你想,你能夠存儲任意多的文檔。注意,儘管一個文檔,物理上存在於一個索引之中,文檔必須被索引/賦予一個索引的type。這裏的文檔至關於關係型數據庫中表的記錄

文檔元數據(Field)

文檔元數據_index:文檔在哪存放_type:文檔表示的對象類別_id:文檔惟一標識ID 是一個字符串,當它和 _index 以及 _type 組合就能夠惟一肯定 Elasticsearch中的一個文檔。 當你建立一個新的文檔,要麼提供本身的 _id ,要麼讓 Elasticsearch 幫你生成。這裏的文檔元數據至關於關係型數據庫中的表中的字段

分詞

分詞就是把一段連續的文本按照語義拆分紅多個單詞,而後Es按照單詞來給記錄作索引,分詞後的集合就是做爲倒排索引的key值。 ES 內部內置了多種分詞器,若是要對中文分詞則須要ik分詞器。例如:蘋果手機,經過分詞器分析可能被拆分爲蘋果、手機。

分片和複製(shards & replicas)

一個索引能夠存儲超出單個結點硬件限制的大量數據。好比,一個具備10億文檔的索引佔據1TB的磁盤空間,而任一節點都沒有這樣大的磁盤空間;或者單個節點處理搜索請求,響應太慢。爲了解決這個問題,Elasticsearch提供了將索引劃分紅多份的能力,這些份就叫作分片。當你建立一個索引的時候,你能夠指定你想要的分片的數量。每一個分片自己也是一個功能完善而且獨立的「索引」,這個「索引」能夠被放置到集羣中的任何節點上。 分片之因此重要,主要有兩方面的緣由:

  • 容許你水平分割/擴展你的內容容量
  • 容許你在分片(潛在地,位於多個節點上)之上進行分佈式的、並行的操做,進而提升性能/吞吐量 至於一個分片怎樣分佈,它的文檔怎樣聚合回搜索請求,是徹底由Elasticsearch管理的,對於做爲用戶的你來講,這些都是透明的。在一個網絡/雲的環境裏,失敗隨時均可能發生,在某個分片/節點不知怎麼的就處於離線狀態,或者因爲任何緣由消失了,這種狀況下,有一個故障轉移機制是很是有用而且是強烈推薦的。爲此目的,Elasticsearch容許你建立分片的一份或多份拷貝,這些拷貝叫作複製分片,或者直接叫複製。 複製之因此重要,有兩個主要緣由:
  • 在分片/節點失敗的狀況下,提供了高可用性。由於這個緣由,注意到複製分片從不與原/主要(original/primary)分片置於同一節點上是很是重要的。
  • 擴展你的搜索量/吞吐量,由於搜索能夠在全部的複製上並行運行

集羣(cluster)

一個集羣就是由一個或多個節點組織在一塊兒,它們共同持有你整個的數據,並一塊兒提供索引和搜索功能。一個集羣由一個惟一的名字標識,這個名字默認就是「elasticsearch」。這個名字是重要的,由於一個節點只能經過指定某個集羣的名字,來加入這個集羣。在產品環境中顯式地設定這個名字是一個好習慣,可是使用默認值來進行測試/開發也是不錯的。

節點(node)

一個節點是你集羣中的一個服務器,做爲集羣的一部分,它存儲你的數據,參與集羣的索引和搜索功能。和集羣相似,一個節點也是由一個名字來標識的,默認狀況下,這個名字是一個隨機的漫威漫畫角色的名字,這個名字會在啓動的時候賦予節點。這個名字對於管理工做來講挺重要的,由於在這個管理過程當中,你會去肯定網絡中的哪些服務器對應於Elasticsearch集羣中的哪些節點。 一個節點能夠經過配置集羣名稱的方式來加入一個指定的集羣。默認狀況下,每一個節點都會被安排加入到一個叫作 「elasticsearch」 的集羣中,這意味着,若是你在你的網絡中啓動了若干個節點,並假定它們可以相互發現彼此,它們將會自動地造成並加入到一個叫作 「elasticsearch」 的集羣中。 在一個集羣裏,只要你想,能夠擁有任意多個節點。並且,若是當前你的網絡中沒有運行任何Elasticsearch節點,這時啓動一個節點,會默認建立並加入一個叫作 「elasticsearch」 的集羣。

elasticsearch與 Apache solr的比較

Apache solr 優勢

  1. Solr有一個更大、更成熟的用戶、開發和貢獻者社區。
  2. 支持添加多種格式的索引,如:HTML、PDF、微軟 Office 系列軟件格式以及 JSON、XML、CSV 等純文本格式。
  3. Solr比較成熟、穩定。
  4. 不考慮建索引的同時進行搜索,速度更快。

solr缺點

創建索引時,搜索效率降低,實時索引搜索效率不高。

Elasticsearch 優勢

  1. Elasticsearch 是分佈式的。不須要其餘組件,分發是實時的,被叫作」Push replication」。
  2. Elasticsearch 徹底支持 Apache Lucene 的接近實時的搜索。
  3. 處理多租戶(multitenancy)不須要特殊配置,而Solr則須要更多的高級設置。
  4. Elasticsearch 採用 Gateway 的概念,使得完備份更加簡單。
  5. 各節點組成對等的網絡結構,某些節點出現故障時會自動分配其餘節點代替其進行工做。

缺點

  1. 只有一名開發者(當前 Elasticsearch GitHub 組織已經不僅如此,已經有了至關活躍的維護者)
  2. 還不夠自動(不適合當前新的Index Warmup API)

對比結果

  1. 當單純的對已有數據進行搜索時,Solr 更快。
  2. 當實時創建索引時, Solr會產生io阻塞,查詢性能較差, Elasticsearch 具備明顯的優點。
  3. 隨着數據量的增長,Solr的搜索效率會變得更低,而 Elasticsearch 卻沒有明顯的變化。
  4. Solr 的架構不適合實時搜索的應用。
  5. Solr 支持更多格式的數據,而 Elasticsearch 僅支持 json 文件格式
  6. Solr 在傳統的搜索應用中表現好於 Elasticsearch,但在處理實時搜索應用時效率明顯低於 Elasticsearch
  7. Solr 是傳統搜索應用的有力解決方案,但 Elasticsearch 更適用於新興的實時搜索應用。

關於ELKB

先說下ELK,ELK是一個流行的日誌系統解決方案,注意,ELK不是一個軟件名,而是一個解決方案的縮寫,即Elasticsearch+Logstash+Kibana(ELK Stack)這三個軟件的集合。

  1. Elasticsearch:分佈式搜索和分析引擎,具備高可伸縮、高可靠和易管理等特色。基於 Apache Lucene 構建,能對大容量的數據進行接近實時的存儲、搜索和分析操做。一般被用做某些應用的基礎搜索引擎,使其具備複雜的搜索功能。
  2. Logstash:數據收集額外處理和數據引擎。它支持動態的從各類數據源蒐集數據,並對數據進行過濾、分析、豐富、統一格式等操做,而後存儲到用戶指定的位置。
  3. Kibana:數據分析和可視化平臺。一般與 Elasticsearch 配合使用,對其中數據進行搜索、分析和以統計圖表的方式展現。

總結

這篇文章主要是對一些基本概念進行總結,要引入一門新的技術棧,就必須先對這門技術的基本概念有必定了解,而後和市場經常使用技術進行對比,瞭解優點和劣勢,在有必定的瞭解以後,就能夠進入下一階段了,下一階段將介紹如何安裝 Elasticsearch 如何使用它的Api進行查詢。 若是以爲有用,能夠關注公衆號:科比可比克。 原文連接:ES 入門

相關文章
相關標籤/搜索