轉載請務必加上原作者：銘毅天下，原博客地址：http://blog.csdn.net/laoyang360
1、大文件是多大？
ES建立索引完成全文檢索的前提是將待檢索的信息導入Elaticsearch。
項目中，有時候需要將一些掃描件、PDF文檔、Word、Excel、PPT等文檔內容導入Elasticsearch。
比如：將《深入理解Elasticsearch》這邊書導入ES，而這邊書的全文內容被識別后的大小可能為3MB——5MB以上的字節。
存入ES后是一個content字段，對這個content執行全文檢索&高亮顯示，就存在檢索效率低的問題，會耗時30S以上的時間。
這點，作為習慣了搜索引擎極速體驗的用戶，是不能忍的。
本文，詳細記錄了大文件的全文檢索性能問題排查及提升實踐方式。
從檢索癥狀來看：
1）翻頁到1000+頁（每頁10條數據）以上，響應時間會比較長。
2）當遇到某些文件的時候（事后分析得知是大文件），響應時間尤其長，超過30S以上返回高亮結果。
baidu，360，搜狗等搜索引擎都不提供訪問末頁的請求方式。都是基于如下的請求方式：?
通過點擊上一下、下一頁逐頁訪問。?
這個從用戶的角度也很好理解，搜索引擎返回的前面都是相關度最高的，也是用戶最關心的信息。
Elasticsearch的默認支持的數據條數是10000條，可以通過post請求修改。
最終，本步驟將支持ES最大返回值10000條數據，每頁10條，也就是共顯示1000頁數據。
【from + size機制】：當Elasticsearch響應請求時，它必須確定docs的順序，排列響應結果。如果請求的頁數較少（假設每頁10個docs）, Elasticsearch不會有什么問題，但是如果頁數較大時，比如請求第100頁，Elasticsearch不得不取出第1頁到第100頁的所有docs，再去除第1頁到第99頁的docs，得到第100頁的docs。
【scroll機制】：相對于from和size的分頁來說，使用scroll可以模擬一個傳統數據的游標，記錄當前讀取的文檔信息位置。這個分頁的用法，不是為了實時查詢數據，而是為了一次性查詢大量的數據（甚至是全部的數據）。
因為這個scroll相當于維護了一份當前索引段的快照信息，這個快照信息是你執行這個scroll查詢時的快照。在這個查詢后的任何新索引進來的數據，都不會在這個快照中查詢到。但是它相對于from和size，不是查詢所有數據然后剔除不要的部分，而是記錄一個讀取的位置，保證下一次快速繼續讀取。
from+size方式以及scroll方式優缺點對比：
1）對于from+size方式：當結果足夠大的時候，會大大加大內存和CPU的消耗。但，該方式使用非常方便。
2）對于scroll方式： 當結果足夠大的時候， scroll 性能更佳。但是不靈活和 scroll_id 難管理問題存在。
【from網絡】個人測試：當 結果足夠大的時候 產生 scroll_id 性能也不低。如果只是一頁頁按照順序，scroll是極好的，但是如果是無規則的翻頁，那也是性能消耗極大的。
經過兩種機制對比，加之步驟1，限定了分頁數，最大1000頁。并且用戶支持主頁翻頁的方式，暫定還是采用from+size方式。
如果后面步驟有問題，再考慮換成scorll機制。
當出現卡頓、卡死等性能低、用戶體驗差問題時，查看ES的日志。?
分析日志如下：?
原因分析：卡頓、卡死都是堆內存設置不足導致。?
根據之間總結的高性能配置建議，果斷加堆內存，由16GB增加到最大值31GB。?
堆內存使用比率可以通過：cerebro 工具檢測性能。
1） 打印出DSL，可以通過接口： searchSourceBuilder.toString()。
2) 新增profile參數，查看到底哪里慢了。?
profile API的目的是：將ES高層的ES請求拉平展開，直觀的讓你看到請求做了什么，每個細分點花了多少時間。?
給你改善性能提供相關支撐工作。?
使用舉例如下：
GET/_search{"profile":true,"query": {"match": {"message":"message number"}? }}
1
2
3
4
5
6
7
3） 換了全文接口api ，query_string改成match query滿足要求且速度有提升。
4）刪除某些查詢條件，在基礎數據不變的條件下，查看查詢速度是否快了（返回時間短了）。
驗證發現，當不返回content字段（_source控制）時，速度會變快。?
當取消高亮字段處理，速度會更快。0.5秒之內返回結果。
至此，初步斷定和高亮處理有關系。
通過論壇中網友的建議來看，都推薦對于大文件高亮使用： fast-vector-highlighter。
查詢官網文檔得知：?
Elasticsearch高亮分為三種方式：
官網明確支持，該方式匹配慢，如果出現性能問題，請考慮其他高亮方式。
支持postings高亮方式，需要在mapping下添加如下信息：
"type":"text","index_options":"offsets"
1
2
添加完畢后，posting高亮方式將取代傳統的高亮方式。
posting高亮方式的特點：?
1）速度快，不需要對高亮的文檔再分析。文檔越大，獲得越高 性能 。?
2）比fvh高亮方式需要的磁盤空間少。?
3）將text文件分割成語句并對其高亮處理。對于自然語言發揮作用明顯，但對于html則不然。?
4）將文檔視為整個語料庫，并 使用BM25算法 為該語料庫中的文檔打分。?
使用舉例：
PUT /example{"mappings": {"doc": {"properties": {"comment": {"type":"text","index_options":"offsets"}? ? ? }? ? }? }}
1
2
3
4
5
6
7
8
9
10
11
12
13
方式3： fast-vector-highlighter 簡稱fvh高亮方式。
如果在mapping中的text類型字段下添加了如下信息：
"type":"text","term_vector":"with_positions_offsets"
1
2
fvh高亮方式將取代傳統的plain高亮方式。
fvh高亮方式的特點如下：?
1）當文件>1MB(大文件）時候，尤其適合fvh高亮方式。?
2）自定義為 boundary_scanner的掃描方式。?
3) 設定了 term_vector to with_positions_offsets會增加索引的大小。?
4）能聯合多字段匹配返回一個結果，詳見matched_fields。?
5）對于不同的匹配類型分配不同的權重，如：pharse匹配比term匹配高。?
舉例：
PUT /example{"mappings": {"doc": {"properties": {"comment": {"type":"text","term_vector":"with_positions_offsets"}? ? ? }? ? }? }}
1
2
3
4
5
6
7
8
9
10
11
12
13
最終選型：fvh高亮方式。首先：新建了索引，按照fvh的方式對content字段新設置了mapping；其次通過如下方式進行索引數據同步：
POST /_reindex{"source": {"index":"test_index"},"dest": {"index":"test_index_new"}}
1
2
3
4
5
6
7
8
9
實踐結果表明，同樣的大文件，原本檢索>40S，現在2S之內返回結果。?
沒有改一行代碼，只修改了mapping，效率提升了近20倍。
清醒認知，一切bug都是紙老虎。?
多年開發經驗讓我深深認知到：
這里包括所有技術問題，尤其是在測試人員、用戶之前發現的問題。
少瞎bb，少踢皮球。那些是市井“小市民”的專利，我們要敬而遠之，也不要成為那樣的人。?
“出淤泥而不染”是程序員恪守的寶貴品格。
你TM亂了，軍心就煥然了。?
不要板著臉，沒有程序員虧欠你的，就事說事，對事不對人。
到了上線階段，說選型不合理、架構不合理，打誰的臉？?
平時務必及時關注項目動態，提前關注技術難點和風險點，協調架構師等技術專家，和大家一起克服。?
一切馬后炮都是管理無能的體現！
解決問題的方法肯定比問題多。
