ElasticSearch索引數據優(yōu)化的方法

本文小編為大家詳細介紹“ElasticSearch索引數據優(yōu)化的方法”，內容詳細，步驟清晰，細節(jié)處理妥當，希望這篇“ElasticSearch索引數據優(yōu)化的方法”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。

為深州等地區(qū)用戶提供了全套網頁設計制作服務，及深州網站建設行業(yè)解決方案。主營業(yè)務為成都做網站、網站制作、深州網站設計，以傳統(tǒng)方式定制建設網站，并提供域名空間備案等一條龍服務，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！

1. 索引數據優(yōu)化

搜索引擎（以ES為例），是將一個查詢拆分為最細粒度的單位條件之后，按照單位條件檢索倒排索引得到單位結果集，然后對所有單位結果取交集得到最終的查詢結果，也就是說雖然一個查詢看起來只返回了10條記錄，但是有可能其中間結果是（100w）∩（100w）∩（100w）＝10，所以看起來滿足條件的結果很少，但是查詢性能卻上不去。

這時要優(yōu)化性能，我們需要做的就是盡量減少中間結果集大小，讓取交集的時間盡可能短：

• 冷熱隔離

查詢倒排表是搜索引擎在執(zhí)行查詢時必需要做的，單個條件得到的結果集（id set）越小，當然loop執(zhí)行獲取交集的時間越短，所以大致上查詢性能與索引數據量的大小成正比。

當索引數據量變大之后，按照二八定律，80%的查詢落在最熱的20%數據上，那么將這20%數據單獨放到一個熱索引，可以有效減少單條件結果集大小，從而提高查詢性能；

ElasticSearch也會利用緩存來提高排序性能，比如fielddata，如果一個查詢命中了未緩存的冷字段，系統(tǒng)會自動加載該字段內容（fielddata）到內存，所以就冷查詢來說，通常帶排序的查詢要遠遠慢于普通查詢，如果做到冷熱隔離，命中熱索引的冷查詢加載fielddata的時間會大大減少，就算是冷查詢也能基本滿足低rt的查詢需求。

• 水平拆分

冷熱隔離有時候并不一定能完美解決業(yè)務需求，比如店內搜索，商品編輯很多，冷熱交替頻繁，而且80%的店鋪商品量都不大。

對于此類數據，有個明顯的特點是所有的查詢都帶有店鋪屬性，也就是只查詢單店鋪內的數據，這時候就可以考慮索引水平拆分了，按照店鋪維度將所有的商品數據拆分為n個子索引。

這樣原本一次查詢需要加載全部字段數據（fielddata），就可以變?yōu)橹患虞d店鋪所在的某個子索引的字段數據（1/n），所耗費的資源能下降幾個數量級，另外單條件匹配倒排索引得到的結果集也可以縮小到原本的1/n，能夠濾掉很多其它店鋪的數據（對于本次查詢來說就是廢數據）。

當然拆分策略可以視具體的業(yè)務而定，比如也可以按照時間范圍來拆分。

另外補充一點，之所以沒有垂直拆分是因為搜索引擎沒有辦法做在線join操作，要實現join需要自己動手取不同索引的數據做交集，如果跨度范圍大或者帶了排序條件，那么跨索引的查詢基本是無解。

• 引擎配置

配置調優(yōu)一般是搜索引擎性能優(yōu)化的第一步，這里又可以分為server配置和索引配置兩方面：

• server配置

Lucene系的搜索引擎都是跑在jvm上的，所以合適的jvm啟動參數對搜索引擎的表現有著重要的影響，如果分配的heap內存很大則更是如此，這里我就拋磚引玉把我們目前用到的一些jvm參數列一下，理念也就是盡量控制garbage內存在ygc時就回收掉，控制臨時的大對象不進入old區(qū)（當然優(yōu)化查詢讓這些臨時大對象少生成也是一方面，下文會講到）：

    -XX:MaxGCPauseMillis=2000

    -XX:+PrintGCDateStamps

    -XX:+G1PrintHeapRegions

    -XX:+UnlockDiagnosticVMOptions

    -XX:+UnlockExperimentalVMOptions

    -XX:+PrintAdaptiveSizePolicy

    -XX:G1HeapRegionSize=32m

    -XX:G1ReservePercent=15

    -XX:InitiatingHeapOccupancyPercent=60

在集群規(guī)模擴大之后，將各個node按角色拆分為master/data/client也是需要做

的，將全集群的狀態(tài)同步/選舉過程等任務剝離到master，將結果聚合（內存開銷很大）/客戶端連接交互（http協(xié)議如果有大量短連接創(chuàng)建/銷毀，開銷也很大）等任務剝離到client，盡量減輕data node的負載（查詢/索引執(zhí)行過程都是data node負責的），以提高服務性能。

針對ElasticSearch，其緩存配置和breaker配置也需要根據業(yè)務應用場景調整，比如寫多讀少并且索引量比較大的場景可以適當降低filter cache大小，調高field data大?。ūM量讓加載到內存的字段內容保留，冷加載一次field data是有比較大開銷的，而且失效的field data eviction也會加重gc的負擔）；

而讀多寫少并且索引量也比較小的場景就可以降低field data的大小，調高filter的比例（提高緩存復用率）；

breaker配置最好寫定比例，盡量讓緩存不要在堆內存互相擠兌，避免加重gc負擔。

• 索引配置

索引配置比較靈活，粒度也比較細，當我們查詢索引時其實都是查詢某個時間的一個快照數據，只有index searcher重載一次索引文件，這期間（兩次reopen index searcher之間）對索引進行的操作才會可見，這段時間也叫做刷新時間（refresh_interval）；

需要注意的是重載索引文件（reopen index searcher）的開銷很大，所以一般搜索引擎都是提供近實時的查詢服務，以減少重載索引文件的次數，降低系統(tǒng)負載，有個案例：曾經將一個索引的刷新時間從1s調整到5s，整個搜索響應時間從200ms降低到20ms以內，效果可見一斑。

字段配置是索引配置的一方面，簡而言之就是能不索引的就不索引，能不存到引擎的就不存，也要避免出現大面積的稀疏數據分布，目的就是減少資源消耗／減小索引文件大小，以提高內存使用率，降低merge時間（索引文件需要定期merge，清理碎片文件）；

有條件也可以指定查詢routing，讓某個查詢能夠直接命中特定的shard，而不必去所有shard收集數據，減少等待時間；

到5.x版本，ES還是可以配置一個索引包含多個type的，實際上同一個索引的多個type物理上是存儲在同一個索引文件目錄內，也就是共享同一批索引文件，僅僅是通過隱藏的_uid/_type字段來區(qū)分。

那么問題來了，如果某個type的數據量遠遠大于其他type，數據量最大的type就會成為其他type性能表現的瓶頸（merge受影響，如果字段不相同還會導致稀疏數據問題，浪費寶貴的mem資源）。

因此生產中我們是禁止一個索引包含多個type的，而在ES6.x版本預告中也表示7.0版本中將使用默認type，不再允許同一個索引配置多type了。

順便提一句：多type在字段映射（mapping）上也有所限制，同名字段必須使用相同的類型 。

讀到這里，這篇“ElasticSearch索引數據優(yōu)化的方法”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內容的文章，歡迎關注創(chuàng)新互聯行業(yè)資訊頻道。

文章標題：ElasticSearch索引數據優(yōu)化的方法
分享URL：http://muchs.cn/article22/jpgojc.html

成都網站建設公司_創(chuàng)新互聯，為您提供ChatGPT、靜態(tài)網站、移動網站建設、微信公眾號、動態(tài)網站、域名注冊

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯