資料的增刪改查一直都是網際網路最基本的需求！而這些操作的90%都是查！！！

上世紀60年代，資料查詢需求旺盛，關係型資料查詢蓬勃發展，誕生了各種各樣的資料庫和SQL語言！資料庫查詢效率極高，建立索引也只能為欄位的粒度！如果是想要對欄位中的某些資料做查詢，只能使用like語句，逐字匹配，查詢效率不高！

這時候全文搜尋就能體現出更為強大的效率！

全文搜尋是對所有的資料進行拆分，對每一個詞都分別建立索引，記錄詞語所在的位置和出現的次數，然後在查詢的時候能快速找到文件所在處，實現快速查詢！

比如1，我是一個兵！2，我愛你！兩句話會分別拆分之後儲存到一個索引文件中進行維護，比如說我字就會儲存有兩次的頻率，並且在兩句話中都有出現，在搜尋"我"字的時候，就能把兩句話搜尋出來！

比如下圖:

不管是淘寶，百度網頁等都是透過對連結或者標題等進行索引儲存，在關鍵字搜尋的時候就能選擇出關鍵詞所在的標題，根據相關度進行排序，最後查詢出所有需要的標題進行顯示！

而全文搜尋的實現都很多，包括底層的lucence，企業級應用solr，elasticsearch等等！elasticsearch因為其天然的分佈特性，和便於大量水平擴充套件的特性，restful的服務介面收到廣泛關注和使用！

瞭解全文搜尋基本原理以後，本文不對elasticsearch的原理，叢集使用，索引分片，傳輸協議展開來講，而且因為elasticsearch是開源的，可以透過簡單的配置就能方便使用，而不用關注其內部實現，回到問題所在，怎麼才能更快的搜尋？

1，伺服器記憶體要大一點，因為索引載入需要大量記憶體，並且最大最小記憶體設定相同值，防止GC時候的大量stop the world！

2，設定合理的索引重新整理時間，indwx.fresh_interval如果設定過大，索引查不到容易導致異常，設定太小，伺服器壓力會很大！

3，禁用_all，開啟會導致複製增加，查詢效率變低！

4，防止設定過多的分片副本，增大合併時間，影響查詢效率！

5，最佳化查詢返回欄位，減少記憶體佔用！

6，新增查詢快取！

參與過搜尋、資料分析等專案的開發者對於ElasticSearch較為熟悉，雖說ES目前應用廣泛，但其實它的效能並非我們想像的那麼好。

ElasticSearch（簡稱ES）是用Java程式語言開發的基於Lucene的一款企業級搜尋引擎伺服器。它支援分散式部署，而且對外提供了RESTful API，便於各類程式語言呼叫。

ES資料量一大時，特別是第一次搜尋的時候耗時會很久（甚至10s以上）。也不要認為改個引數就能改善所有效能慢的場景。

ES提供了慢日誌，但預設是沒有開啟的。ES中的慢日誌主要分兩類：索引慢日誌、搜尋慢日誌。如何開啟呢？參考如下：

{

"index.search.slowlog.threshold.query.warn" : "10s",

"index.search.slowlog.threshold.fetch.debug": "500ms",

"index.indexing.slowlog.threshold.index.info": "5s"

}

1、升級硬體配置（硬碟、記憶體）

對於硬碟建議選用SSD，它比機械硬碟讀寫速度更快，另外記憶體需要適時調整。

2、JVM引數調優

要知道ES是用Java開發的，跑在JVM中，如果JVM引數設定不當也會影響ES的效能！ES安裝後預設的堆記憶體是1G，這個值太小了，需要適當調大。

3、加大檔案系統快取設定

ES依懶底層的FileSystem Cache，檔案系統快取值若太小則會導致ES查詢時會從硬碟中查詢，效率低。若檔案系統快取大小設定合理，則很多查詢可以直接從快取內查詢。

4、減少副本數量

ES預設副本是3個，副本越多雖然能提高叢集的可用性，但是也增加了搜尋的併發數、也會影響索引寫入效率。所以建議副本不要過多，一般1~3個足夠了。

5、禁止深度分頁

ES它的分頁效率很低（若每頁10條，查詢第100頁時，ES實際查詢的是每個Shard中的1000條資料進行處理後再返回第100頁裡的10條資料），頁數越靠後，CPU消耗越大，查詢效率越低！所以我們要禁止深度分頁。

6、Filter 比 Query 效率好

Filter查詢結果可以快取，而且不需要像Query那樣計算相關性分值，所以Filter效率更高。