大流量下的 ElasticSearch 搜索演進

這是泥瓦匠（bysocket.com）的第27篇精華分享

ES （ElasticSearch）是分佈式搜索引擎。引擎太晦澀，其實相似一個 MySQL ，一個存儲。方便提供下面功能：

• 近實時搜索
• 全文檢索，結構化搜索，統計分析

那麼存儲在 ES 數據哪裏來？

答案是數據同步。方式推薦以下：

1. 數據傳輸(Data Transmission)是阿里雲提供的一種支持RDBMS(關係型數據庫)、NoSQL、OLAP等多種數據源之間數據交互的數據服務。【阿里的】 https://help.aliyun.com/product/26590.html

2. 有贊億級訂單同步的探索與實踐【小弟我呆的小組搞的】 https://mp.weixin.qq.com/s/33KACMxXkgzZyIL9m6q4YA

迴歸到 ES 演進

1、小流量階段

當時在創業公司，同步每次都是全量的，而後凌晨任務跑一下便可。或者直接同步往 ES CRUD 數據。

單機僞集羣，也能夠跑。具體全文檢索思路：

• 基於「短語匹配」並設置最小匹配權重值
• 哪來的短語，利用 IK 分詞器分詞
• 基於 Fiter 實現篩選
• 基於 Pageable 實現分頁排序

具體看我係列 ES 博客和 GitHub。

2、流量慢慢大了

這個量級預估是 百萬 / 千萬數據同步和查詢。

就不能單機僞集羣了，運維層面能解決這個量：

• 多個 ElasticSearch 運行實例（節點 Node）的組合體是 ElasticSearch 集羣
• 經過水平擴容爲集羣添加更多節點

如何水平擴容

主分片在索引建立已經肯定。讀操做能夠同時被主分片和副分片處理。所以，更多的分片，會擁有更高的吞吐量。天然，須要增長更多的硬件資源支持吞吐量。說明，這裏沒法提升性能，由於每一個分片得到的資源會變少。動態調整副本分片數，按需伸縮集羣，好比把副本數默認值爲 1 增長到 2：

PUT /blogs/_settings
{
"number_of_replicas" : 2
}

基本一個集羣 Cluster 含着各個業務搜搜：訂單、商品等

3、忽然訂單流量暴增了

忽然發現一個問題：

• A 集羣裏面的大索引慢查會影響 A 集羣的其餘小索引。

好比如今同一個 訂單 索引大了，慢查。影響了其餘業務。那不該該呀，咋辦？

答案是：物理隔離爲多集羣：

• 分爲不少集羣：集羣訂單、集羣商品等隔離
• 多機房支持

---

每每這時候問題由來了：業務單點如何優化升級？

一個索引 project , 存儲項目相關的數據。項目的數量級愈來愈大，億量級，萬億量級。那一個大索引的查詢啥的都會出現瓶頸。這時候該怎麼優化呢？

解決方案：冷熱分離；拆分

大索引的拆分，也不是很難。相似分片的路由規則，根據具體業務指定便可。

這裏，咱們能夠定義 1000 個索引，分別名爲 project_一、project_二、project_3…

而後在 ES 集羣上面架一層簡單的 proxy 。裏面核心的業務路由規則能夠這樣：

project_id 項目自增 ID index_id 得出來的索引對應的 ID

index_id = project_id % 1000

• ES proxy 層：作總索引和真正分索引的映射
• ES 索引配置管理：作索引與業務的映射
• ES 集羣

冷熱分離；也是相似的就是中間狀態的數據最熱獨立集羣獨立索引。按期從裏面刪除終態數據。那麼這個索引數據量少，支持搜搜查詢量賊大。何樂而不爲。

• 完 -