上篇提到選擇了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操作。
很多人認爲ES也是數據庫系統，ES7之前普遍認識是：index -> database, type -> table, document -> row。ES7之後在某種意義上index就是table了。所以：把ES作爲應用系統的數據庫來使用是大大不妥的。因爲應用系統由衆多數據表組成關係數據庫，在ES上就意味着必須構建衆多的index，會出現大量的細小shard（table）分佈在集羣節點上，嚴重影響效率。
ES7是個集羣體系：cluster->nodes->index->shards。shard又分primary shard和replica shard (pshard,rshard)。一般來說pshard和rshard相互應分佈在不同的node上。所有寫操作由pshard負責，或者說先在pshard上執行後再把結果分發到隸屬各rshard。讀取操作採取就近讀取策略以實現快速響應。
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實現的。
ES自帶一套REST-api可以對index進行更新、搜索、統計、提取。
ES-REST-api的功能可以說是相當全面，但複雜、不易掌握、使用要求門檻高，且不易作爲系統整合工具。爲了實現ES在行業IT系統的普遍應用，應該繞過複雜的ES-REST-api，在ES之上設計一套連接ES-HTTP通道的REST-api作爲ES和前端（web,mobile）的橋樑，把前端搜索條件翻譯成ES JSON格式的搜索指令發送至ES，然後對搜索結果進行簡化、篩選處理，以某種簡潔通用的格式呈現給前端。最終目的其實是爲了降低前端開發人員引用ES的技術門檻。