Elasticsearch全文檢索實戰小結——覆盤我帶的第二個專案
一、專案概述
這是一個被我稱之為“沒有槍、沒有炮，硬著頭皮自己造”的專案。專案是和其它公司合作的三個核心模組開發。
使用ES的目的是：
1）、採集資料、網站資料清洗後存入ES；
2）、對外提供精確檢索、萬用字元檢索、模糊檢索、分詞檢索、全文檢索介面等二次封裝介面。
二、專案架構
如上圖所示，ES作為中間層，一方面儲存資料清洗後儲存的資料，另一方面對外提供插入、更新、刪除、檢索介面的。
三、ES使用小結
3.1 ES版本選型
1.X，2.X版本有太多侷限性，5.X做了較大效能提升的改進。比如：string欄位型別分成了keyword和text兩種型別，keyword用於精確匹配，text結合設定的分詞器用於全文檢索。
選擇5.X需要勇氣，實踐證明當時“向前一小步”的正確性。
3.2 ES安裝部署
ELK都有安裝。
ES安裝了head外掛，用途：檢視叢集狀態、檢視索引資訊、檢視mapping資訊、檢視每個索引下資料資訊、進行簡單欄位查詢操作；
安裝了ik分詞外掛，用途：分詞，實現全文檢索。
安裝了Kibana，用途：資料對接展示；用DevTool替代postman執行DSL驗證，以驗證增、刪、改、查功能。
安裝了logstash，用途：藉助“logstash-input-jdbc”實現資料庫到ES之間的同步。
3.3 ES API選型與使用
調研了ES提供的原生API以及Jest等，最終選擇Jest。將Maven工程相關jar包匯出到專案中使用。
3.4 後端框架選型
play new 工程名
play eclipsify 工程名
play clean
play deps
play run 測試模式
play start release模式
3.5 ES分頁處理
ES Java介面能返回的預設的最大記錄數為10000行。如果想返回超過1W+條的記錄，需要做如下設定：
PUT ting_index/_settings
{
"max_result_window" : 500000
}3.6 如何只刪除資料，而不刪除索引
類似Mysql等關係型資料庫的delete from mtable操作，而不是drop掉表，參考如下：
POST my_store/products/_delete_by_query
{
"query": {
"match_all": {}
}
}3.7 Jest update更新操作
資料前新增doc一層，如下所示：
strJson = “{” + ” \”doc\” :” + strJson + “}”;
3.8 叢集中所有節點都安裝ik分詞器
叢集裡每一個例項都要安裝ik外掛。
否則，當我們更新包含指定分詞的mapping的時候會報錯。
3.9 最大位元組數限制
報錯資訊如下：“whose UTF8 encoding is longer than the max length 32766 “,
這個問題是某個欄位size過大導致lucence不能索引引起的。
如果要儲存超過32766位元組的資料，那麼需要在mapping中設定欄位時，新增ignore_above = 256就可以了。
舉例，新增Mapping的操作如下：
POST tingindex/tingtype/_mapping
{
"tingtype":{
"properties":{
"content":{
"type":"text",
"analyzer":"ik_max_word",
"search_analyzer":"ik_max_word",
"fields":{
"keyword":{
"ignore_above":256,
"type":"keyword"
}
}
},
"publish_time":{
"type":"date",
"format":"YYYY-MM-dd HH:mm:ss"
},
"author":{
"ignore_above":256,
"type":"keyword"
},
}
}
}3.10 出現未分派， elasticsearch叢集，在新增節點調整分片數時，出現UNASSIGNED。
排查方案：
GET /_cluster/allocation/explain
3.11 kibana修改時區
kibana->management->advanced setting->dateFormat:tz, 編輯，改成GMT +0。
3.12 ES檢索（URL訪問方式）
3.13 ES高效能配置（from ES中文社群）
【1】分詞對效能的影響：
索引過程中，分詞會對索引速度有所影響，建議你可以優化一下你的mapping，不必要的就不必分詞，甚至不必設成可搜尋的了。
舉例：5.X中不必要分詞的設定為keyword型別。
【2】分片和副本對效能影響：
分片和副本的設計，應該根據節點數來調整，正常情況下 節點數= （副本數+1）*分片數，若是你希望提高搜尋效能，可是適當提高副本數。
【3】記憶體對效能的影響：
1）.節點的記憶體分配的不能太少了。
ES其實很佔記憶體，大部分的操作都是建立在記憶體足夠的基礎上。
舉例：你的資料量應該在150G-200G左右，我覺得可以把記憶體調整到10G左右。
2）. ES的記憶體使用分為兩部分ES快取和Lucene通過核心快取加速一些資料。
3）. 如果伺服器記憶體 nG > 64G,ES的記憶體儘量設定低於32G，建議最大31G.
因為es使用“記憶體指標壓縮”技術，一旦記憶體記憶體大於32G這項技術將失效，記憶體有效使用只有原來的60%~70%。
你不必為記憶體浪費而擔心，因為lucene會通過系統把一些聚合和排序的資料快取起來方便你快速查詢使用。
4） .如果伺服器記憶體 nG < 64G，建議給ES分配 記憶體 (n-2)/2G. 首先2G是給系統預留，然後es和lucene。
5） . 如果你想繼續你的實時查詢，儘量不要使用swap(交換分割槽)，建議關閉系統swap使用
【4】ES執行緒設定
執行緒數方法：執行緒數：=(核心數*3)/2+1
四、專案整體小結
4.1、需求要細化
切記：
1）不要拿到合同或需求就開發。
2）欲速則不達。
3）需求細化後形成《需求規格說明書》，並一定郵件或電話或當面找使用者確認。
對於需求，由頂向下知道需要實現的核心功能，團隊核心敲定分幾個模組？
逐個模組細化需求點。
4.2、預研要充分
對於新的技術點，在專案啟動後的需求細化階段即可同步進行。
作為專案經理的我，沒有事必躬親，多關注預研點方案選型、預研難點、預研報告，小細節如：下載、安裝部署、引數驗證、英文翻譯安排團隊其它成員執行。
4.3、文件要跟進
需求有需求文件，設計根據專案需要和進度安排有概要設計或詳細設計文件。
設計文件千萬不能少，設計的過程就是開發“路演”的過程。
設計文件一定要梳理清楚架構圖、模組圖、資料流圖、流程圖。
需求文件是設計的基礎，需求和設計文件是開發的基礎。
4.4、思維要活躍
技術方案的選型很重要，大的方面包括：
1）檢索儲存叢集部署，叢集節點個數選擇等。
2）前後端選型，前端用jquery，jsp還是js? 後端使用spring,tomcat,還是play框架？
3）開源方案選型，要提早預研可用性、需求點覆蓋程度、二次開發或封裝難度等。
4）前後端介面對接格式敲定。
5）對外提供檢索服務介面名稱，引數敲定。
思維活躍主要體現在：
1）方案選型、技術調研快刀斬亂麻，時間緊，不糾結。此路不通，另尋他路。
2）自己不能解決，不要太拖沓，及時google,stackoverflow解決或者和架構師討論解決。
4.5、開發要同步
1）介面對接溝通要充分。
介面提供方和介面使用方，要反覆多花時間溝通業務，要定義好資料介面。
此時的耗時，事後你會發現是好事，溝通越充分要好。
2）介面對接要實時同步。
一方修改了，要第一時間告訴對方。
五、專案管理小結
5.1、多方溝通要郵件
郵件是證據，避免不必要賴賬或扯皮。
qq溝通和微信都不是好方式，最主要原因是不利於檢視聊天記錄、不利於快速檢索。
5.2、進度彙報要詳細
包含但不限於專案整體情況、本週已完成、下週計劃、專案風險與應對。
5.3、任務分工要明確
團隊成員特點不同，切記口頭分工。團隊人少，我用excel做了詳細記錄。
5.4、每週例會要及時
周例會起到承上啟下的作用，有效協調控制專案進度、團隊成員工作飽和度。
六、後記
1、ES要學習的東西非常多。不糾結，多去官網、官方論壇、stackoverflow、Google檢索答案，
相信我，你並不孤獨。
2、ES還有很長的路要走，繼續精進閱讀與思考，繼續加油！
——————————————————————————————————
更多ES相關實戰乾貨經驗分享，請掃描下方【銘毅天下】微信公眾號二維碼關注。
（每週至少更新一篇！）
和你一起，死磕Elasticsearch！
——————————————————————————————————
2017年09月03日 16:09 於家中床前