此文章要對ES有一些基礎
應用背景：官網重建，需要全網站檢索所有的文章、服務、附件等；數據庫設計上，由於業務隔離的原因，數據被分散在各個表中
技術選型：在開發週期限制條件下，準備了兩個方案：
1、查詢直接打到數據庫，對各個需要查詢的數據做union彙總
2、使用ES全文檢索工具
針對第一個方案，從查詢速度和數據庫壓力上考慮放棄實施此方案，首先所有的查詢都是模糊搜索，模糊搜索在數據庫層面是不走索引的， 其次排序規則也會直接影響查詢速度，並且網站對外開放，所有的查詢壓力都給到了數據庫，增加了數據的宕機風險；
針對第二個方案，在研究了ES的特性之後，決定採用此工具做搜索引擎，ES對會所有需要檢索的字段信息創建反向索引，根據需要檢索的信息定位到反向索引，進而定位到所有包含此信息的所有數據信息，非常適合我們的全網站檢索功能。
應用過程：ES要和kibana工具配合使用，並且有嚴格的版本要求，不兼容的版本，kibana是啓動不起來的；一開始考慮的是使用logstash工具將表數據以及結構直接同步到ES中去，然後利用ES可以使用sql的查詢方式，直接連表查詢；於是我將ES 6.7版本下載下來解壓縮，配置好端口數據， 啓動boot服務器的時候報錯版本不兼容，經過百度才知道，SpringBoot1.X的版本不兼容ES高版本，於是我在github上找到適用我們架構的ES2.2版本，對於要將數據庫中的全量數據都同步到ES中去，就用到了上面的logstash初始化全量數據進ES
重要知識點：ES有兩個主要的端口，9300給服務器鏈接使用，9300給kibana連接使用；Es跟關係型數據庫對照如下
關係型數據庫(MySQL) 非關係型數據庫（ElasticSearch）
數據庫Database 索引Index
表Table 類型Type
數據行Row 文檔Dpcument
數據列Column 字段Field
主要的概念對照關係，ES查詢的時候可以只查詢指定的Index，在不指定的時候查詢的是ES裏面所有的數據；至於爲什麼ES這麼快，那就要介紹一下反向索引這個概念，在介紹這個概念之前，先說一下分詞器，我們存入的數據，在指定的搜索字段都會帶有一個分詞器，就是將對應字段的數據進行分詞存儲（比如“我是中國人” 會被默認的分詞器分成多個詞存儲），而反向索引就是在這個分詞的基礎上實現的；反向索引的的實現是由1、單詞詞典 2、倒排列表3、倒排文件 。單詞詞典就是分詞器分詞後的結果數據，每個單詞存儲了一個只想倒排列表的指針而所有的倒排列表存儲的文件叫做倒排文件，倒排列表裏面的單詞對應着文檔的位置信息；這裏最重要的是利用對我們業務要求有利的分詞器，並且對應的Javaapi的模糊字符串精準匹配，這個精準都是相對分詞器分詞後的結果來精準匹配的，如果分詞器中沒有就不會查詢到結果數據。
應用總結：從一開始的需求到最終確定使用ES是一個對業務理解和新技術探索的過程，充分體現了技術和業務是相輔相成的；在業務的基礎上要擴展 技術的廣度，在具體的技術應用上要增加技術的深度，像這次使用ES的結果上，由於沒有深刻理解精準匹配的前提是分詞後的分詞結果，對分析器沒有準確的使用，導致在搜索的時候，如果搜索某個字段的全量信息，搜索結果就出不來，因爲我使用的是漢語分詞器，顧名思義漢語分詞器就是會根據漢語的習性將對應的詞語分開，如果不是詞語的話是不會出現在分析結果裏面的，這才導致搜索結果有誤。在使用新技術之後，在對新技術理解和把控上不是很強的時候，一定有要多測試跟新技術有關的功能，今早暴露問題，儘早解決，避免線上事故。