文章目錄
- 該業務為什么需要ElasticSearch? / 該業務需要ElasticSearch的核心功能是哪些？
- 正確示例
- 錯誤示例
- 如何快速驗證分詞是否能夠滿足業務需求？
- 分詞不滿足，如何自定義分詞？
- 業務數據的字段類型映射是否合理？
- 實踐中如何使用IndexTemplate，Index Alias？
- 業務數據是否可修改？
- 業務數據需要保留多長時間？/ 如何配置生命周期管理？
- 業務數據的增長情況估算？容量估算？
- 最后
本篇博文分享自己在實踐中使用ElasticSearch進行業務開發的一些心得。只討論應用程序和ElasticSearch交互，至于其他組件，例如Kafak和ElasticSearch的集成則不在本篇博文討論范圍之內。
在業務中使用ElasticSearch中時建議將下列事項作為檢查清單，根據實際情況來增減，確保自己在開發過程中思考了下列事項并結合實際情況來完成最終的設計、開發。
該業務為什么需要ElasticSearch? / 該業務需要ElasticSearch的核心功能是哪些？
在使用ES時，我們要問自己的第一個問題是，我為什么拿ES來解決當前業務中的問題？對于該業務的技術問題，團隊內的現有技術棧和ES相比有哪些不足？一定要有充足的理由。
正確示例
- 業務需要一個推薦系統，可以利用ES的分詞能力來做這件事
- 對于海量數據的模糊查詢，已經對數據庫索引和代碼進行了優化，查詢起來還是很慢。所以將數據庫的數據同步至ES中，利用ES強大的緩存能力來幫助我們提高模糊查詢的性能。
錯誤示例
- 我看ES好像能干這事，而且網上很多解決方案也是這個。那我們就用。（沒有結合當前情況進行思考，直接進行照搬的）
如何快速驗證分詞是否能夠滿足業務需求？
大部分使用ES場景還是和其分詞功能有關。
一個常見的錯誤開發流程是，上來就開干，直接寫代碼，周邊代碼擼完了，結果到最后發現分詞有各種各樣的問題。所以對于這種關鍵的問題，我們一開始就要對其驗證，只有核心分詞沒問題且能滿足我們的業務需求了，再寫代碼也不遲。
可以根據業務需求找到合適的內置分詞器。找到分詞器之后，用一些示例文本在Kibana > Dev Tool中測一下分詞效果，見如何測試分詞器，例如，我想測一下標準分詞器對我們業務的一些文本的分詞結果
POST _analyze
{"analyzer": "standard","text": "The 2 QUICK Brown-Foxes jumped over the lazy dog's bone."
}
這種方式你能在幾個小時之內快速知道哪些分詞器能滿足當前業務場景并及時反饋給產品團隊進行溝通，在需求前期就能快速辨別該需求能不能做，而不是拍著胸脯說，沒問題，然后擼了一堆代碼，發現業務核心根本沒辦法實現，自己給自己挖了一個坑。
分詞不滿足，如何自定義分詞？
有很多場景使用內置的分詞器可能不滿足，例如：使用ES完全達到和數據庫like的效果。
自定義分詞只需要看官方文檔下面幾個內容
- 創建自定義分詞器
- 為某個字段指定分詞器
創建完自定義分詞器切記不要忘了上面一條，要先測試過確保沒問題，才可進行下一步
業務數據的字段類型映射是否合理？
確定核心分詞字段沒問題了之后，接下來就要為整個index建立完整的mapping字段。關于字段類型可直接參考官方文檔field data types部分，根據實際業務數據類型選擇合適的字段類型。同時結合官方文檔中的優化索引速度和優化搜索速度中有關index的建議，設計出合理，高效的結構。
實踐中如何使用IndexTemplate，Index Alias？
- 建議使用IndexTemplate并按照業務的數據特點對index進行分區。例如，我們需要把每年的訂單數據導入到ES中以便快速檢索，我們只提供近5年的數據搜索。我們會將index按照年分區，可根據查詢區間直接搜索相關的年的index而不是所有index；刪除的時候直接將該index刪除即可。
- 無論現在用不用Index Alias，我都建議為index設置alias。
業務數據是否可修改？
如果你的業務數據不涉及到更新，寫進去就是之后就是查詢，類日志數據，強烈建議使用datastream
業務數據需要保留多長時間？/ 如何配置生命周期管理？
index結構創建好了之后，一個關鍵的問題是該數據需要在ES中保留多長時間，因為機器資源是有限的，不可能不加任何限制的存儲數據。
這個問題需要產品團隊給出明確的答案。有了明確的期限之后，我們要根據實際情況為index設置生命周期策略。雖然這些活編程式也能干，但是ES既然提供了這個工具，干嘛不用它的呢。有關生命周期的各配置細節解釋和具體配置可參考這篇博文
業務數據的增長情況估算？容量估算？
在業務上線之前，需要預估該業務上線后ES中數據容量情況，以便確定當前ES的機器資源是否滿足需要，如果不滿足應該擴充多少？預估容量也有助于避免由于數據量突增導致ES壓力增大，影響到其他使用到ES的業務。
如何正確的計算ES所需要的機器資源呢？我一開始的想法是，計算每條document在ES中的存儲大小，然后根據產品給出的預估量，簡單計算所需總存儲大小是多少。后來發現，社區問過類似的問題，回答是這樣沒辦法做也不建議這樣做。因為ES存儲會做各種優化、壓縮。不可能通過這種方式計算出來，即使算出來也是不準確的。
唯一的可行方法是，預估上線之后數據量有多大，然后按照這個數據量灌到ES里去，觀察ES的壓力情況，根據實際情況做調整
最后
上述所有項都是在業務開發中值得注意的地方。我并沒有把每一步的解決方案都詳細的寫出來，是因為解決方案里鏈接了大量的官方文檔，跟著官方做就可以實現。
真正寫代碼往往是上述大部分問題都已經確定了之后才開始。
如有更好的開發實踐，歡迎留言討論
)
