elasticsearch路由一個文檔到一個分片的方法是什么

這篇文章主要講解了“elasticsearch路由一個文檔到一個分片的方法是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“elasticsearch路由一個文檔到一個分片的方法是什么”吧！

當索引一個文檔的時候，文檔會被存儲到一個主分片中。 Elasticsearch 如何知道一個文檔應該存放到哪個分片中呢？當我們創建文檔時，它如何決定這個文檔應當被存儲在分片 1 還是分片 2 中呢？

首先這肯定不會是隨機的，否則將來要獲取文檔的時候我們就不知道從何處尋找了。實際上，這個過程是根據下面這個公式決定的：

shard = hash(routing) % number_of_primary_shards

routing 是一個可變值，默認是文檔的 _id ，也可以設置成一個自定義的值。 routing 通過 hash 函數生成一個數字，然后這個數字再除以 number_of_primary_shards （主分片的數量）后得到 余數 。這個分布在 0 到 number_of_primary_shards-1 之間的余數，就是我們所尋求的文檔所在分片的位置。

所有的文檔 API（ get 、 index 、 delete 、 bulk 、 update 以及 mget ）都接受一個叫做 routing的路由參數 ，通過這個參數我們可以自定義文檔到分片的映射。一個自定義的路由參數可以用來確保所有相關的文檔——例如所有屬于同一個用戶的文檔——都被存儲到同一個分片中。

一個分片并不是沒有代價的。記住：

• 一個分片的底層即為一個 Lucene 索引，會消耗一定文件句柄、內存、以及 CPU 運轉。

• 每一個搜索請求都需要命中索引中的每一個分片，如果每一個分片都處于不同的節點還好， 但如果多個分片都需要在同一個節點上競爭使用相同的資源就有些糟糕了。

• 用于計算相關度的詞項統計信息是基于分片的。如果有許多分片，每一個都只有很少的數據會導致很低的相關度。

  
  

在特定場景下這是一個容易回答的問題，尤其是你自己的場景：

1. 基于你準備用于生產環境的硬件創建一個擁有單個節點的集群。

2. 創建一個和你準備用于生產環境相同配置和分析器的索引，但讓它只有一個主分片無副本分片。

3. 索引實際的文檔（或者盡可能接近實際）。

4. 運行實際的查詢和聚合（或者盡可能接近實際）。

基本來說，你需要復制真實環境的使用方式并將它們全部壓縮到單個分片上直到它“掛掉。” 實際上 掛掉 的定義也取決于你：一些用戶需要所有響應在 50 毫秒內返回；另一些則樂于等上 5 秒鐘。

一旦你定義好了單個分片的容量，很容易就可以推算出整個索引的分片數。 用你需要索引的數據總數加上一部分預期的增長，除以單個分片的容量，結果就是你需要的主分片個數。

在索引寫入時，副本分片做著與主分片相同的工作。新文檔首先被索引進主分片然后再同步到其它所有的副本分片。增加副本數并不會增加索引容量。

無論如何，副本分片可以服務于讀請求，如果你的索引也如常見的那樣是偏向查詢使用的，那你可以通過增加副本的數目來提升查詢性能，但也要為此 _增加額外的硬件資源_。

一個擁有兩個主分片一份副本的索引可以在四個節點中橫向擴展

通過調整副本數來均衡節點負載

感謝各位的閱讀，以上就是“elasticsearch路由一個文檔到一個分片的方法是什么”的內容了，經過本文的學習后，相信大家對elasticsearch路由一個文檔到一個分片的方法是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！