摘要: 原創出處 https://www.bysocket.com 「公眾號:泥瓦匠BYSocket 」歡迎關注和轉載,保留摘要,謝謝!
ES 的安裝下載,網上一大片,我這邊不在重複。可以看看我以前做的小筆記:
Spring Boot 2.0 M7 整合 ES 5 、Kibana 和 X-pack
其中 ES 三大要素:
可見, _index 索引的重要性。避免某個索引存儲不相關的數據。
ES 集群搭建,文章很多。我這邊也不一一列舉了。先看 ES 集群分散式圖
跟伺服器集群類似,多個 ElasticSearch 運行實例(節點 Node)的組合體是 ElasticSearch 集群。
ElasticSearch 是天然分散式的,可以通過水平擴容為集群添加更多節點。
ElasticSearch 集群是去中心化的,只有一個主節點(Master)。而且主節點是動態選舉,因此不會出現單點故障。
那節點是什麼?
上面說過,一個 ElasticSearch 運行實例就是節點。任何節點都可以被選舉成為主節點。主節點負責集群內所以變更,比如文檔的增加、刪除等。所以集群不會因為主節點流量的增大成為瓶頸。因為任何節點都會成為主節點。
如圖,P1 P2 P0 是節點內的主分片,其他 R 是副分片。
那分片是什麼?
分片,是 ES 節點中最小的工作單元。分片僅保存全部數據的一部分。分片包括主分片和副分片,主分片是副分片的拷貝。主分片和副分片基本沒有大的區別。
如果是全文搜索,會查詢到每個分片,然後將每個分片的結果進行全局地收集,並處理返回。
舉個例子:比如新建了一個索引 project , 存儲項目相關的數據。那具體的某個 project A 的數據會被切分,存儲在不同的分片上。那麼根據 project A 的 _id 如何路由到具體的分片上呢?
分片的路由公式是這樣的:
shard = hash(routing) % number_of_primary_shards
倘若如果剛剛那個例子,一個索引 project , 存儲項目相關的數據。項目的數量級越來越大,億量級,萬億量級。那一個大索引的查詢啥的都會出現瓶頸。這時候該怎麼優化呢?
這時候是不是想到了,一句常說的:空間換時間。
所以大索引的拆分,也不是很難。類似分片的路由規則,根據具體業務指定即可。
這裡,我們可以定義 1000 個索引,分別名為 project_1、project_2、project_3…
然後在 ES 集群上面架一層簡單的 proxy 。裡面核心的業務路由規則可以這樣:
index_id = project_id % 1000
總結一張圖: