> Index用不好，麻煩事不會少；

# 一、管理方式

ElasticSearch作為最常用的搜尋引擎元件，在系統架構中發揮極其重要的能力，可以極大的提升資料的載入和檢索效率；但不可否認的是，在長期的應用實踐中，也發現很多不好處理的流程和場景；

![](http://img.blog.itpub.net/blog/2022/11/03/c7ed474f38611f1d.png?x-oss-process=style/bb)

從直觀感覺上說，業務中對索引的使用主要涉及如圖的幾個流程，其核心也就是索引的結構維護與資料的流動管理兩個模組；

如果資料結構比較簡單且體量小，那麼使用起來可能很順手；如果資料主體複雜且會動態擴充套件，並且體量偏大，那麼就很容易踩中一些比較坑的點；

比如：索引中欄位一旦有誤，調整的流程十分複雜；資料流向索引中的方式，需要根據場景靈活選擇；以及資料查詢時的深度分頁問題；下面將圍繞這些問題來總結下應對策略；

順帶補充一句，其實很多元件在應用的時候都有不太符合預期的地方，所以在整合時可以考慮編寫自定義的管理程式，來解決使用時可能存在的問題；

# 二、結構維護

對於ES索引的結構維護，資料主體如果相對簡單的話，可以考慮手動管理，但實際上使用索引時，通常主體結構都比較複雜，欄位個數超過三五十都很常見，所以基於流程化的管理很有必要；

![](http://img.blog.itpub.net/blog/2022/11/03/e9f546e32282a632.png?x-oss-process=style/bb)

**結構對映**：將需要構建索引的主體結構，在欄位庫中統一維護，值得注意的是欄位名稱和型別，欄位可以與關係型資料庫的查詢一致，但是不同元件型別的描述不一樣，尤其對ES來說，如果欄位型別不合理，會影響搜尋的使用；

**索引結構**：在實際的業務場景中，欄位的資訊是會動態變化的，這就會給索引結構的維護帶來很多麻煩，欄位的增減都好管理，但是如果涉及型別的變動，則存在索引重建的過程，會導致資料多次重新排程，這也是風險較高的操作；

**程式維護**：這種結構維護的機制，其核心目的是把整個流程進行程式化管理，避免人工進行干預，以此來確保索引結構的穩定擴充套件；

不得不提的一個經驗教訓，曾經在管理業務日誌的索引結構時，出現過一次誤刪動作，好在可以重新構建和資料備份恢復，但是依舊給心裡留下了幾釐米的陰影，此後也將維護流程徹底程式化，避免失誤動作發生；

# 三、資料排程

## 1、同步方案

資料的排程管理，其本質就是將資料從一個容器向另一個容器搬運或者複製，其核心操作就是讀和寫兩個動作，但是為了讓流程具備容錯和穩定性，通常需要做策略和方案的設計；

![](http://img.blog.itpub.net/blog/2022/11/03/cc00c5fca89f17cb.png?x-oss-process=style/bb)

**同步雙寫**：對資料的實時性要求極高，通常在一個事務中完成資料的雙寫動作，保證資料層面的強一致性；

**非同步解耦**：在完成資料庫的寫動作之後，基於MQ訊息解耦索引的寫入，流程存在輕微的延遲，如果消費失敗會導致資料缺失；

**定時任務**：透過任務排程的方式，以指定的時間週期執行新增資料的同步機制，存在明顯的時效問題；

**元件同步**：採用合適的同步元件，比如官方提供的元件或者一些第三方開源的元件，在原理上與任務同步類似；

資料同步的選型方案有多種，如何選擇完全看具體的場景，在過往的使用過程中，對於核心業務會採用同步雙寫，對於內部的活動類業務會採用非同步的方式，對於業務日誌會採用任務排程，對於系統的監控或執行日誌則多是依賴同步元件；

## 2、中斷和恢復

無論採用何種方式將資料同步到索引中，都不得不面對一個靈魂問題，如果流程突然異常中斷，恢復後如何保證索引資料不丟失？這個問題適應於很多複雜的流程；

![](http://img.blog.itpub.net/blog/2022/11/03/4f48c48c5a8256fb.png?x-oss-process=style/bb)

容錯性是衡量一個複雜流程的核心指標，比如在索引資料同步的過程，需要短暫性的暫停，或者流程被迫中斷時，都應該具備恢復後自動修復索引中資料缺失的能力；

ES實踐中一個非常經典的問題，修改索引的結構時需要進行索引重建，此時要將當前索引遷入臨時索引中，在完成索引結構調整之後，需要從臨時索引中遷回資料，在此過程中，可以對服務互動的索引名稱動態調整；

![](http://img.blog.itpub.net/blog/2022/11/03/71eab624e6234bb1.png?x-oss-process=style/bb)

當然也可以直接使用臨時索引作為互動索引，避免一次遷移動作，這種動態的識別需要在服務中嵌入，在整個`reindex`過程中要避免手動干預，個人還是更相信程式的安全性和準確性；

# 四、重新整理策略

在向ES索引中寫資料時，存在三種不同的資料重新整理機制，檢視`6.8`版本的設定中，引數`refresh_interval`設定的是1s時間，即執行寫入動作1秒後資料才可以被搜尋到，避免頻繁寫入消耗過多的資源；

**NONE**：預設的重新整理策略，請求提交之後不會等待資料重新整理，降低資源消耗但資料實時性低；

**IMMEDIATE**：請求提交後立即重新整理索引，資料的實時性很高但是資源消耗過大，API文件中建議測試使用；

**WAIT_UNTIL**：請求提交之後會等待索引重新整理完成才會結束，相對來說是一種比較平衡的策略；

重新整理機制對於索引的資料維護來說，主要在增刪改的動作中，對即時查詢有直接的影響，至於如何選擇還是要結合具體的場景，尤其與同步方案關聯密切，也可以在索引互動中動態維護策略，來應對不時之需；

# 五、深度分頁

對於資料查詢來說，幾乎都存在分頁的需求，在常見的應用中，不斷下拉的功能都是存在最大的極限值；

ES中常用From/Size進行分頁查詢，但是存在一個限制，在索引的設定中存在`max_result_window`分頁深度的限制，`6.8`版本預設值是10000條，即10000之後的資料無法使用From/Size翻頁；

先從實際應用場景來分析，大多數的翻頁需求最多也就前10頁左右，所以從這個角度考慮，ES的翻頁限制在合理區間，在實踐中也存在對部分索引調高的情況，暫未出現明顯問題；

再從技術角度來思考一下，如果翻頁的引數過大意味著更多的資料過濾，那計算資源的佔用也會升高，ES引擎的強大在於搜尋能力，檢索出符合要求的資料即可；

![](http://img.blog.itpub.net/blog/2022/11/03/2819b72d8f85e159.png?x-oss-process=style/bb)

不管是ES還是其它類似的分散式儲存元件，甚至是MySQL分庫分表模式，其本質都是資料分佈在不同服務節點的不同資料片上；常規的執行原理都是給請求分配一個主節點，協調各個節點執行相同的查詢，並完成結果彙總和響應，深度分頁時計算資源的佔用自然非常高；

如果一定需要深度分頁，在`6.8`的版本中提供了`Scroll`或`Search-After`兩種其他的方式，用法參考相關文件即可。

# 六、參考原始碼

```
程式設計文件：
https://gitee.com/cicadasmile/butte-java-note

應用倉庫：
https://gitee.com/cicadasmile/butte-flyer-parent
```

ElasticSearch這些坑記得避開

相關文章