search(1)- elasticsearch結構概念

   上篇提到選擇了elasticsearch ES做爲專業化搜索引擎的核心,這篇討論一下ES的基本結構和應用概念。首先,從硬結構方面來說:ES是在一個集羣(cluster)環境裏運行的,因此ES應該具有高可用和高擴展特性,由於系統能夠分佈在機器內無數個節點(node)服務器上運行。ES的索引(index)分佈在集羣中各node上。ES的index又能夠向下分紅多個shard分片。由於ES是基於lucent的,ES的shard就是一個完整的lucent index。因此,ES index是一個shard集合,也就是lucent index集合。在定義ES index時必須指定該index的shard(primary)數量,以後不得修改。這就意味着每一個ES index須要佔用一個以上shard,而shard是ES index操做的最小單元,也就是說一個shard只能存放一種ES index索引文件(document)。前端

在ES7以前的版本表面上每一個index裏又分不一樣的document type,能夠分辨不一樣類型的document。但由於ES index是shard集合,或者lucent index集合,而lucent index並無document type的概念,基本上是一種nosql (schemaless)存儲結構,因此ES7以後就取消了_type這層,其結果就變成每一個ES index只能允許一種document操做。node

不少人認爲ES也是數據庫系統,ES7以前廣泛認識是:index -> database, type -> table, document -> row。ES7以後在某種意義上index就是table了。因此:把ES做爲應用系統的數據庫來使用是大大不妥的。由於應用系統由衆多數據表組成關係數據庫,在ES上就意味着必須構建衆多的index,會出現大量的細小shard(table)分佈在集羣節點上,嚴重影響效率。web

ES7是個集羣體系:cluster->nodes->index->shards。shard又分primary shard和replica shard  (pshard,rshard)。通常來講pshard和rshard相互應分佈在不一樣的node上。全部寫操做由pshard負責,或者說先在pshard上執行後再把結果分發到隸屬各rshard。讀取操做採起就近讀取策略以實現快速響應。sql

ES的底層操做是由lucent實現的。在lucent操做時shard又被細分一層到segment:luccent shard是由多個segment組成的,lucent的寫操做先寫入一塊緩存(write-buffer),而後以一種提交形式再以一個segment爲單元存寫入shard。數據庫

ES是某種nosql數據庫,但在存寫數據時又對數據,特別是字符text類型的數據進行了分拆處理,因此ES存寫便是更新索引indexing。從另外一個角度說明:ES是一個索引容器(index container),是一個完整封閉的容器。index的構建、維護、使用等都是經過ES提供的一些工具軟件以及一套HTTP-api來實現的。數據輸入能夠用工具(如logstash)進行批次型的indexing,實時indexing是經過HTTP-api實現的。api

ES自帶一套REST-api能夠對index進行更新、搜索、統計、提取。緩存

ES-REST-api的功能能夠說是至關全面,但複雜、不易掌握、使用要求門檻高,且不易做爲系統整合工具。爲了實現ES在行業IT系統的廣泛應用,應該繞過複雜的ES-REST-api,在ES之上設計一套鏈接ES-HTTP通道的REST-api做爲ES和前端(web,mobile)的橋樑,把前端搜索條件翻譯成ES JSON格式的搜索指令發送至ES,而後對搜索結果進行簡化、篩選處理,以某種簡潔通用的格式呈現給前端。最終目的實際上是爲了下降前端開發人員引用ES的技術門檻。服務器

相關文章
相關標籤/搜索