## 選擇恰當的分片數量和分片副本數量 <div style="text-indent:2em"> <p> 最開始使用ElasticSearch時，一般都是創建一個索引，導入數據，然后發送查詢命令檢索數據。我們確信系統運行庚子，至少在最開始，數據量不大而且QPS(Query Per Second)也不高的時候運行良好。在幕后，ElasticSearch創建了一些分片來存儲數據，也可能還會創建分片副本(例如，如果用默認配置)，而且用戶在配置方面也不用過多地操心。</p> <p>當應用程序規模增長起來，越來越多的數據需要進行索引，QPS也變得越來越高。這個時候，量變就引起質變了。慢慢地問題也就出現了(讀者可以閱讀 <i>知識的靈活運用</i>一節的內容來了解應用程序規模增長的對應方法) 。這時候，就該思想如何規劃索引數據、優化配置使得應用程序的處理能力與規模增長相同步。在本章，作者將給出一些應對相關問題的指導方針。然而對應問題并沒有一個統一的標準，不同的應用場景有著不同的特點和需求，這些特點和需求不僅體現在索引結構上，同時也體現在配置上面。例如：整個索引的數據規模、查詢類型、預期的吞吐量都是不盡相同的。</p> <h3 style="text-indent:0em;">分片和過度分配(over allocation)</h3> <p> 關于索引分片，在<i>第一章&nbsp;&nbsp;認識ElasticSearch</i>里面已經有介紹，這里簡單回顧一下。索引分片就是把索引數據切分成多個小的索引塊，這些小的索引塊能夠分發到同一個集群中的不同節點。在檢索時，檢索的結果是該索引每個分片上檢索結果的總和(盡管在某些場景中“總和”并不成立：單個分片有可能存儲了所有的目標數據)。默認情況下，ElasticSearch會為每個索引創建5個主分片，就算是單結點集群亦是如此。像這樣的冗余就稱為過度分配：這種場景下，這種分配方式似乎是多此一舉，而且只會在索引數據(把文檔分發到多個分片上)和檢索(必須從多個分片上查詢數據然后全并結果)的時候增加復雜度，樂享其成的是，這些復雜的事情是自動處理的，但是為什么ElasticSearch要這樣做呢？</p> <p>假定我們有一個構建在單個分片上的索引。這意味著如果我們的應用程序規模增長到單機無法處理的情況下時，問題就來了。當索引中有數據時，當前版本的ElasticSearch是無法將分片中的數據切分成多個小塊的：我們只能在創建索引的時候指定好分片的數量。唯一的解決辦法就是重新創建一份多個分片的索引，然后將原來的數據重新索引(動詞)到新的索引(名詞)中。然而這樣的處理方案需要時間和服務器資源，比如CUP時間、內存、大容量存儲器。而且有可能我們并沒有時間和上面提到的那些資源。換個角度，通過使用過度分配策略，我們可以在必要的時候添加一臺新的安裝了ElasticSearch的服務器。當新的節點添加進來時，ElasticSearch會自動對集群進行負載均衡，在不需要重新索引數據的前提下將部分索引數據轉移到新的機器上。ElasticSearch作者設置的默認配置(5個主分片和一個分片副本)是權衡了數據增長的可能性和合并不同分片數據的最終開之后的最終選擇。</p> <p>默認配置適用于大部分場合。那么問題來了：當我們在什么時個需要增加或者減少分片數量，讓分片數量盡可能少一些？</p> <p>第一個問題的答案顯而易見。如果數據集的大小有限制而且嚴格定義好的，可以只使用一個分片。如果不是的，大拇指法則表明最佳的分片數量取決于節點數量。所以，如果計劃將會到10個節點，那么就需要配置10個分片。需要記住的重點是：考慮到高可用性和吞吐量，分片副本也是需要聲配置的。分片副本像普通分片一樣也占用空間。如果為每個分片指定一個拷貝(number_of_shards =1 ),那么就需要20個分片：10個主分片和10個分片副本。這個簡單的公式可以總結如下： </p> <p style="font-family:optimal;font-style:italic;">Max number of nodes = Number of shards * (number of replicas +1) </p> <p>換句話說，如果你計劃用10個分片和2個分片副本，那么最大的節點數是30。</p> <h3>一個關于過度分配的正例</h3> <p>如果讀者仔細閱讀了本章前面部分的內容，應該確信配置最小數量的分片是明智的選擇。但是有時分配更多的分片卻比較方便，因為每個分片都是獨立的Lucene索引，更多的分片意味著在單個較小的索引上進行操作(特別是數據索引操作)會比較高效。對于有的應用場景來說，上文是選擇多分片不錯的理由。當然多分片同時也帶了額外的開銷：分發搜索命令到每個分片以及分片結果的合并。這個開銷在某些特定的應用場景是可以避免的，這類應用場景的一個特點是：查詢命令總是會被具體的參數過濾。像多租戶系統，每個查詢命令都被限定在確定用戶上下文中。解決問題的思想很簡單：把每個用戶的數據都存儲在一個分片上，而且只在查詢的時候使用該分片。這也是ElasticSearch的路由功能大顯身手的地方(我們將在本章的 <i>&nbsp;路由功能淺談&nbsp;</i>一節詳細討論這一知識點)。</p> <h3>多分片 vs 多索引</h3> <p>也許讀者會感到疑惑，如果說分片實際上是一段小的Lucene索引，那么真實的ElasticSearch索引是什么呢？它們之間的區別是什么呢？從技術上來說，它們是一樣的，但是會有一個額外的特性只能工作在多索引 或者 多分片結構上。對于數據分片，可以通過路由功能或者在指定的分片上執行查詢命令功能實現將查詢命令定位到特殊的分片上去。對于多索引結構，更通用的機制在于多索引地址的處理上，查詢語句可以通過/index1,index2.../符號聯合多個索引進行查詢。在查詢時，用戶也可以通用使用別名(aliasing)特性將多個索引以一個索引的方式呈現給用戶，索引分片時也可以用別名這個功能。在負載均衡處理邏輯上，容易發現兩者之間更多的不同點，然而自動化程度較低的多索引可以在索引數據時，以通過人工操作強行將多個索引部署在一個節點上的方式部分地隱藏這一點。 </p> <h3>分片副本</h3> <p>索引分片機制用來存儲超過單個節點存儲容量的數據，分片副本用來應對不斷攀升的吞吐量以及確保數據的安全性。當一個節點的主分片丟失，ElasticSearch可以把任意一個可用的分片副本推舉為主分片。在默認情況下，ElasticSearch會創建一個分片副本。然而分片副本的數量可以通過設置相關的API隨時更新，這一點與主分片是不同的。分片副本的動態更新功能使得創建應用程序時十分方便，查詢吞吐量可以隨著分片副本數量的增加而增長，與此同時，使用分片副本還可以處理查詢的發并量。使用分片副本的缺點也是顯而易見的：額外的存儲空間開銷，從主分片復制數據到分片副本時的開銷。選定分片副本的數量時，還需要考慮到現階段需要多少副本。如果分片副本的數量太多，那么就會浪費存儲空間和ElasticSearch的資源，實際上一些分片副本并沒有起作用。相反地，如果沒有設置分片副本，如果主分片出現了故障，數據就會丟失。</p> </div>