查詢優化 · Elasticsearch 5.4 中文文檔

# 查詢優化原文鏈接 :[https://www.elastic.co/guide/en/elasticsearch/reference/5.3/tune-for-search-speed.html](https://www.elastic.co/guide/en/elasticsearch/reference/5.3/tune-for-search-speed.html) 譯文鏈接 : [查詢優化](/pages/viewpage.action?pageId=9405156) 貢獻者 : @李堅，[ApacheCN](/display/~apachecn)，[Apache中文網](/display/~apachechina) ## 使用文件系統緩存 **Elasticsearch** 快速搜索嚴重依賴于文件系統緩存。一般來說,應該確保至少有一半可用內存的文件系統緩存用于 **elasticsearch** 緩存熱門索引數據。 ## 使用更快的硬件如果索引受限于 _**I/O**_ ，應該增加文件系統緩存的內存或者購買更快的驅動設備。目前最快的是 _**SSD**_ 硬盤，比普通硬盤快很多。通常數據存儲在本地，避免使用 **_NFS & SMB_** 等遠程文件系統。還要小心虛擬化存儲，像亞馬遜的 _彈性塊存儲_（_Elastic Block Storage_）。**Elasticsearch** 在虛擬存儲上也有比較好的性能，具有搜索快，安裝便捷的特性；然而相對于本地專用存儲，他就要慢的多了。如果你在 _**EBS**_上使用 _index ，_一定要使用 _IOPS_ 否則操作會很快掛掉。如果搜索受限于 **_CPU_?**，更換更快的 _**CPUs**_。 ## 文檔建模為了盡可能的節省搜索時間，應該為 _Documents_ 創建模版。特別是要避開聯合查詢，嵌套查詢也會慢好幾倍，子查詢將會慢好幾百倍。同一個問題的結果不加入非規范化 _documents_ 加速效果是可以預期的。 ## 預索引數據利用索引查詢數據是最優的方式。例如，如果所有的文檔都有 _price_ 字段，并且大多數查詢都在一個固定的范圍列表中運行范圍聚合，那么可以通過將 _index_ 預索引到 _index_ 和使用 _terms_ 聚合來更快地實現聚合。例如，像下面這樣： ``` PUT index/type/1 { "designation": "spoon", "price": 13 } ``` 像這樣的查詢： ``` GET index/_search { "aggs": { "price_ranges": { "range": { "field": "price", "ranges": [ { "to": 10 }, { "from": 10, "to": 100 }, { "from": 100 } ] } } } } ``` 文檔在索引的時候要使用 **_price_range_** ，應該被映射為關鍵詞： ``` PUT index { "mappings": { "type": { "properties": { "price_range": { "type": "keyword" } } } } } PUT index/type/1 { "designation": "spoon", "price": 13, "price_range": "10-100" } ``` 然后這個請求就直接聚合新字段，而不是在 _price_ 字段運行范圍查詢： ``` GET index/_search { "aggs": { "price_ranges": { "terms": { "field": "price_range" } } } } ``` ## 映射一些數據是數字并不意味著它應該被映射為數值型字段。通暢情況下，字段存儲標識符如 ISBN（國際標準圖書編號）或者其他數據庫任何數字標識的記錄，可能受益于映射為 _關鍵詞_ 而不是 _整數（integer）_ 或者 _長整數（long）_。 ## 避免使用腳本通常避免使用腳本，如果他們是絕對必要的，你應該更喜歡 ?_**painless**_ 和 _**expressions**_ 引擎。 ## 根據日期查詢 _now_ 使用在 _date field_（日期字段）的查詢通常不可緩存，因為正在匹配的范圍始終會更改。然而，使用特定范圍日期查詢，在用戶體驗方面更佳，并且查詢時能夠更好地利用高速緩存。例如下面的查詢： ``` PUT index/type/1 { "my_date": "2016-05-11T16:30:55.328Z" } GET index/_search { "query": { "constant_score": { "filter": { "range": { "my_date": { "gte": "now-1h", "lte": "now" } } } } } } ``` 可以用以下查詢替換： ``` GET index/_search { "query": { "constant_score": { "filter": { "range": { "my_date": { "gte": "now-1h/m", "lte": "now/m" } } } } } } ``` 在這種情況下，我們四舍五入到分鐘，所以如果當前時間是16:31:29，范圍查詢將匹配 _my_date_ 字段的值在 15:31:00 到 16:31:59 之間的所有內容。如果有幾個用戶在同一分鐘內運行包含此范圍的查詢，查詢緩存可以幫助您加快速度。用于舍入的間隔越長，查詢緩存可以幫助越多，但要注意的是，太長時間的舍入也可能嚴重影響查詢性能。 **NOTE：** 將查詢內容分為一大部分可以緩存和一小部分不可以緩存；這樣能夠有效的利用緩存來查詢，如下所示： ``` GET index/_search { "query": { "constant_score": { "filter": { "bool": { "should": [ { "range": { "my_date": { "gte": "now-1h", "lte": "now-1h/m" } } }, { "range": { "my_date": { "gt": "now-1h/m", "lt": "now/m" } } }, { "range": { "my_date": { "gte": "now/m", "lte": "now" } } } ] } } } } } ``` ## 預加載 global ordinals _**global ordinals**?_是用于在 _keywords_ 字段上運行 _terms_ 聚合的數據結構。它們將會被加載到內存中，因為? _elasticsearch_ 不知道哪個字段將會用于 _terms_ 聚合，哪些字段不會被用到。像下面一樣在配置映射刷新的時候讓 _elasticsearch_ 去加載 _global ordinals_： ``` PUT index { "mappings": { "type": { "properties": { "foo": { "type": "keyword", "eager_global_ordinals": true } } } } } ``` ## 預加載文件系統緩存如果運行 _elasticsearch_ 的機器重啟了，那么文件系統緩存將會被清空。為了能查詢的更快一些，機器啟動后 _elasticsearch_ 需要花費一些時間將 index 的熱區域加載到內存中。可以通過設置 **_index.store.preload_**來告訴 _elasticsearch_ 哪些文件擴展名的文件將會被加載到內存中。 ?**WARNING：**如果加載了太多的索引或者文件到文件系統緩存中并且超出了文件系統緩存的大小，將會使搜索變得很慢，請**謹慎使用**此功能。