ES架構及原理

本文轉載自https://www.cnblogs.com/tgzhu/p/6098339.html
Elasticsearch 是一個兼有搜索引擎和NoSQL數據庫功能的開源系統,基於Java/Lucene構建,能夠用於全文搜索,結構化搜索以及近實時分析。能夠說Lucene是當今最早進,最高效的全功能開源搜索引擎框架。 說明: Lucene:只是一個框架,要充分利用它的功能,須要使用JAVA,而且在程序中集成Lucene,學習成本高,Lucene確實很是複雜。 Elasticsearch 是 面向文檔型數據庫,這意味着它存儲的是整個對象或者 文檔,它不但會存儲它們,還會爲他們創建索引,這樣你就能夠搜索他們了html

目錄:node

應用場景
solr VS ES
核心概念
ES模塊結構
分片示例
應用場景mongodb

站內搜索:主要和 Solr 競爭,屬於後起之秀
NoSQL json文檔數據庫:主要搶佔 Mongo 的市場,它在讀寫性能上優於 Mongo ,同時也支持地理位置查詢,還方便地理位置和文本混合查詢,屬於歪打正着 (對比測試參見:http://blog.quarkslab.com/mongodb-vs-elasticsearch-the-quest-of-the-holy-performances.html
監控:統計以及日誌類時間序的數據的存儲和分析以及可視化,這方面是引領者
國外:Wikipedia使用 ES 提供全文搜索並高亮關鍵字、StackOverflow結合全文搜索與地理位置查詢、Github使用Elasticsearch檢索1300億行的代碼
國內:百度(在casio、雲分析、網盟、預測、文庫、直達號、錢包、風控等業務上都應用了ES,單集羣天天導入30TB+數據,總共天天60TB+)、新浪 (見大數據架構--log),阿里巴巴、騰訊等公司均有對ES的使用
使用比較普遍的平臺ELK(ElasticSearch, Logstash, Kibana)
solr VS ES數據庫

Solr是Apache Lucene項目的開源企業搜索平臺。其主要功能包括全文檢索、命中標示、分面搜索、動態聚類、數據庫集成,以及富文本(如Word、PDF)的處理。
Solr是高度可擴展的,並提供了分佈式搜索和索引複製。Solr是最流行的企業級搜索引擎,Solr4 還增長了NoSQL支持。
Solr是用Java編寫、運行在Servlet容器(如 Apache Tomcat 或Jetty)的一個獨立的全文搜索服務器。 Solr採用了 Lucene Java 搜索庫爲核心的全文索引和搜索,並具備相似REST的HTTP/XML和JSON的API。
Solr強大的外部配置功能使得無需進行Java編碼,即可對 其進行調整以適應多種類型的應用程序。Solr有一個插件架構,以支持更多的高級定製
Elasticsearch 與 Solr 的比較總結
兩者安裝都很簡單
Solr 利用 Zookeeper 進行分佈式管理,而 Elasticsearch 自身帶有分佈式協調管理功能
Solr 支持更多格式的數據,而 Elasticsearch 僅支持json文件格式
Solr 官方提供的功能更多,而 Elasticsearch 自己更注重於核心功能,高級功能多有第三方插件提供
Solr 在傳統的搜索應用中表現好於 Elasticsearch,但在處理實時搜索應用時效率明顯低於 Elasticsearch
Solr 是傳統搜索應用的有力解決方案,但 Elasticsearch 更適用於新興的實時搜索應用
核心概念json

集羣(Cluster): 包含一個或多個具備相同 cluster.name 的節點.
集羣內節點協同工做,共享數據,並共同分擔工做負荷。
因爲節點是從屬集羣的,集羣會自我重組來均勻地分發數據.
cluster Name是很重要的,由於每一個節點只能是羣集的一部分,當該節點被設置爲相同的名稱時,就會自動加入羣集。
集羣中經過選舉產生一個mater節點,它將負責管理集羣範疇的變動,例如建立或刪除索引,添加節點到集羣或從集羣刪除節點。master 節點無需參與文檔層面的變動和搜索,這意味着僅有一個 master 節點並不會因流量增加而成爲瓶頸。任意一個節點均可以成爲 master 節點。咱們例舉的集羣只有一個節點,所以它會扮演 master 節點的角色。
做爲用戶,咱們能夠訪問包括 master 節點在內的集羣中的任一節點。每一個節點都知道各個文檔的位置,並可以將咱們的請求直接轉發到擁有咱們想要的數據的節點。不管咱們訪問的是哪一個節點,它都會控制從擁有數據的節點收集響應的過程,並返回給客戶端最終的結果。這一切都是由 Elasticsearch 透明管理的
節點(node): 一個節點是一個邏輯上獨立的服務,能夠存儲數據,並參與集羣的索引和搜索功能, 一個節點也有惟一的名字,羣集經過節點名稱進行管理和通訊.
索引(Index): 索引與關係型數據庫實例(Database)至關。索引只是一個 邏輯命名空間,它指向一個或多個分片(shards),內部用Apache Lucene實現索引中數據的讀寫
文檔類型(Type):至關於數據庫中的table概念。每一個文檔在ElasticSearch中都必須設定它的類型。文檔類型使得同一個索引中在存儲結構不一樣文檔時,只須要依據文檔類型就能夠找到對應的參數映射(Mapping)信息,方便文檔的存取
文檔(Document) :至關於數據庫中的row, 是能夠被索引的基本單位。例如,你能夠有一個的客戶文檔,有一個產品文檔,還有一個訂單的文檔。文檔是以JSON格式存儲的。在一個索引中,您能夠存儲多個的文檔。請注意,雖然在一個索引中有多分文檔,但這些文檔的結構是一致的,並在第一次存儲的時候指定, 文檔屬於一種 類型(type),各類各樣的類型存在於一個 索引 中。你也能夠經過類比傳統的關係數據庫獲得一些大體的類似之處:
關係數據庫 ⇒ 數據庫 ⇒ 表 ⇒ 行 ⇒ 列(Columns)
Elasticsearch ⇒ 索引 ⇒ 類型 ⇒ 文檔 ⇒ 字段(Fields)
模擬示意圖如:服務器

Mapping: 至關於數據庫中的schema,用來約束字段的類型,不過 Elasticsearch 的 mapping 能夠自動根據數據建立
分片(shard) :是 工做單元(worker unit) 底層的一員,用來分配集羣中的數據,它只負責保存索引中全部數據的一小片。
分片是一個獨立的Lucene實例,而且它自身也是一個完整的搜索引擎。
文檔存儲而且被索引在分片中,可是咱們的程序並不會直接與它們通訊。取而代之,它們直接與索引進行通訊的
把分片想象成一個數據的容器。數據被存儲在分片中,而後分片又被分配在集羣的節點上。當你的集羣擴展或者縮小時,elasticsearch 會自動的在節點之間遷移分配分片,以便集羣保持均衡
分片分爲 主分片(primary shard) 以及 從分片(replica shard) 兩種。在你的索引中,每個文檔都屬於一個主分片
從分片只是主分片的一個副本,它用於提供數據的冗餘副本,在硬件故障時提供數據保護,同時服務於搜索和檢索這種只讀請求
索引中的主分片的數量在索引建立後就固定下來了,可是從分片的數量能夠隨時改變。
一個索引默認設置了5個主分片,每一個主分片有一個從分片對應
ES模塊結構網絡

模塊結構圖以下架構

Gateway: 表明ES的持久化存儲方式,包含索引信息,ClusterState(集羣信息),mapping,索引碎片信息,以及transaction log等
對於分佈式集羣來講,當一個或多個節點down掉了,可以保證咱們的數據不能丟,最通用的解放方案就是對失敗節點的數據進行復制,經過控制複製的份數能夠保證集羣有很高的可用性,複製這個方案的精髓主要是保證操做的時候沒有單點,對一個節點的操做會同步到其餘的複製節點上去。
ES一個索引會拆分紅多個碎片,每一個碎片能夠擁有一個或多個副本(建立索引的時候能夠配置),這裏有個例子,每一個索引分紅3個碎片,每一個碎片有2個副本,以下:
$ curl -XPUT http://localhost:9200/twitter/ -d '
index :
number_of_shards : 3
number_of_replicas : 2
每一個操做會自動路由主碎片所在的節點,在上面執行操做,而且同步到其餘複製節點,經過使用「non blocking IO」模式全部複製的操做都是並行執行的,也就是說若是你的節點的副本越多,你網絡上的流量消耗也會越大。複製節點一樣接受來自外面的讀操做,意義就是你的複製節點越多,你的索引的可用性就越強,對搜索的可伸縮行就更好,可以承載更多的操做app

第一次啓動的時候,它會去持久化設備讀取集羣的狀態信息(建立的索引,配置等)而後執行應用它們(建立索引,建立mapping映射等),每一次shard節點第一次實例化加入複製組,它都會從長持久化存儲裏面恢復它的狀態信息
Lucence Directory: 是lucene的框架服務發現以及選主 ZenDiscovery: 用來實現節點自動發現,還有Master節點選取,假如Master出現故障,其它的這個節點會自動選舉,產生一個新的Master
它是Lucene存儲的一個抽象,由此派生了兩個類:FSDirectory和RAMDirectory,用於控制索引文件的存儲位置。使用FSDirectory類,就是存儲到硬盤;使用RAMDirectory類,則是存儲到內存框架

一個Directory對象是一份文件的清單。文件可能只在被建立的時候寫一次。一旦文件被建立,它將只被讀取或者刪除。在讀取的時候進行寫入操做是容許的Discovery節點啓動後先ping(這裏的ping是 Elasticsearch 的一個RPC命令。若是 discovery.zen.ping.unicast.hosts 有設置,則ping設置中的host,不然嘗試ping localhost 的幾個端口, Elasticsearch 支持同一個主機啓動多個節點)Ping的response會包含該節點的基本信息以及該節點認爲的master節點選舉開始,先從各節點認爲的master中選,規則很簡單,按照id的字典序排序,取第一個若是各節點都沒有認爲的master,則從全部節點中選擇,規則同上。這裏有個限制條件就是 discovery.zen.minimum_master_nodes,若是節點數達不到最小值的限制,則循環上述過程,直到節點數足夠能夠開始選舉最後選舉結果是確定能選舉出一個master,若是隻有一個local節點那就選出的是本身若是當前節點是master,則開始等待節點數達到 minimum_master_nodes,而後提供服務, 若是當前節點不是master,則嘗試加入master.ES支持任意數目的集羣(1-N),因此不能像 Zookeeper/Etcd 那樣限制節點必須是奇數,也就沒法用投票的機制來選主,而是經過一個規則,只要全部的節點都遵循一樣的規則,獲得的信息都是對等的,選出來的主節點確定是一致的. 但分佈式系統的問題就出在信息不對等的狀況,這時候很容易出現腦裂(Split-Brain)的問題,大多數解決方案就是設置一個quorum值,要求可用節點必須大於quorum(通常是超過半數節點),才能對外提供服務。而 Elasticsearch 中,這個quorum的配置就是 discovery.zen.minimum_master_nodes 。memcached經過memecached協議來訪問ES的接口,支持二進制和文本兩種協議.經過一個名爲transport-memcached插件提供Memcached命令會被映射到REST接口,而且會被一樣的REST層處理,memcached命令列表包括:get/set/delete/quitRiver : 表明es的一個數據源,也是其它存儲方式(如:數據庫)同步數據到es的一個方法。它是以插件方式存在的一個es服務,經過讀取river中的數據並把它索引到es中,官方的river有couchDB的,RabbitMQ的,Twitter的,Wikipedia的,river這個功能將會在後面的文件中重點說到

相關文章
相關標籤/搜索