elasticsearch 大集羣,雙重別名，滾動更新分詞方案

elasticsearch 滾動更新分詞

公司輿情數據重度依賴 elasticsearch

關鍵點是分詞問題，中文分詞有比較多的選擇，但elasticsearch中文分詞方面，國內用ik、hanlp、ansj或基於其二次開發的比較多

輿情產品必然有分詞變動的操做(主要是是加詞)

reindex+別名能夠解決一部分問題，但在大集羣上會影響業務

elasticsearch寫入數據時會對原始數據做分詞，檢索時會對查詢條件做分詞，以兩次的分詞算匹配度打分

以加詞爲例

加詞後會致使數據大幅波動(由於查詢語句的的分詞結果變了，但原始數據的分詞信息並無變，一樣一條查詢條件，在加詞先後的結果並不一致)，影響產品應用和聚合統計結果，
輕微的波動，能夠解釋爲正常產品優化，致使50%以上甚至100%的數據波動，很難向用戶解釋

加詞只是致使數據波動的一個最多見的緣由，更改了原生的分詞算法，也會致使這種結果

所以動態加詞，熱更新不適於這種場景

而常見的reindex+別名操做，不適合reindex耗時嚴重的大數據集羣

常規的靜態加詞(把新增詞加入es ik plugin要求的目錄下，或直接打進jar包)須要

1暫停服務

2更新詞包

3滾動更新節點(使新增詞生效)，恢復es服務,這裏能夠恢復es服務，但恢得後會有數據波動問題存在

4重建歷史索引

理論上很簡單，但只限於數據量很小的狀況下，提早通知，暫停個小半天維護或選擇非工做日也能說得過去

數據量極大的狀況下，重建歷史索引耗時數週，影響正常使用，通常在國慶和春節這種長假期操做

es集羣爲基礎服務團隊維護，長久以來基本也是這種操做,基礎服務團隊一般只提供一個通用的解決方案，不會根據業務場景做優化調整，也不清楚產品和業務上的痛點

以前由致使的數據波動問題，嚴重的由專人負責，經過調整查詢規則，減小波動的影響，不嚴重的就徹底沒人負責

該方案畢竟不可控，之前這裏由運維統一負責，我的也懶得花心思，年前公司有放出風來要由產品線接手，我的也不想總這麼折騰，就得想辦法解決

實際辦法很簡單，沒有任何技術難度，只是些應用技巧

之因此有數據波動是由於同一個analyzer加詞先後行爲不一致，讓analyzer保持一致就能夠了，索引時分詞和查詢時分詞用的算法一致，就不會有波動問題

 

以ik的ik_max_word爲例

{
"properties": {
"content": {
"type": "text",
"analyzer": "ik_max_word",
"search_analyzer": "ik_max_word"
}
}

}'

先後不一致只是由於ik_max_word的行爲變了，但更新詞包又不是必需要變動ik_max_word

重建索引，是用加詞後的analyzer重建，而並非必定要用ik_max_word來實現