我們之前一直是在windows環境下去啟動一個單節點的es進程，然后去學習和練習各種es的高階的搜索技術，聚合技術。這些主要針對的是es的開發，你可以認為是，如果你是一個java工程師的話，然后你們公司已經有人去維護和搭建一個es集群了，那么你直接掌握之前的內容，就足夠了，你就可以建立需要的索引，寫入數據，搜索，聚合。
很多同學，還是需要自己去規划、設計和搭建一個es集群出來，然后才能基於es去做一些開發這樣的事情。
肯定不是在windows操作系統上去搞了，肯定是在linux集群上面去部署咯
規划一下，比如你需要幾台機器，物理機，還是虛擬機呢？每台機器要多大的資源，多少G內存，多少個cpu，多大的磁盤空間，等等，然后對生產環境的機器相關的配置有沒有什么特殊的要求，對於es來說。你需要處理多大的數據量？需要多大的集群才能支撐的住？
這塊規划好之后，就是搞到一堆你需要的機器，符合你的需求和要求的機器，機器弄好之后，就可以開始在上面部署和玩兒你的es了。
是這樣的，我們的課程，肯定是只能用虛擬機去演練和模擬，在機器的配置上，能夠在課程現場支撐的數據量上，是絕對達不到生產環境的。
盡量保證，給大家用虛擬機去還原和模擬一些場景，然后講解各種相關的技術知識。
一般來說，如果我們剛開始用es，都是先在自己的筆記本電腦上，或者是幾個虛擬機組成的小集群上，安裝一個es，然后開始學習和試用其中的功能。但是如果我們要將es部署到生產環境中，那么是由很多額外的事情要做的。需要考慮我們部署的機器的內存、CPU、磁盤、JVM等各種資源和配置。
1、內存
es是很吃內存的，es吃的主要不是你的jvm的內存，一般來說es用jvm heap（堆內存）還是用的比較少的，主要吃的是你的機器的內存。
es底層基於lucene，lucene是基於磁盤文件來讀寫和保存你的索引數據的，倒排索引，正排索引，lucene的特點就是會基於os filesystem cache，會盡量將頻繁訪問的磁盤文件的數據在操作系統的內存中進行緩存，然后盡量提升磁盤文件讀寫的性能。
很多同學都問我說，es的性能感覺不太理想，es的性能80%取決於說，你的機器上，除了分配給jvm heap內存以外，還剩下多少內存，剩下的內存會留給es的磁盤索引文件做緩存，如果os cache能夠緩存更多的磁盤文件的數據，索引文件的數據，索引讀寫的性能都會高很多，特別是檢索。
但是如果你的大量的索引文件在os cache中放不下，還是停留在磁盤上，那么搜索、聚合的時候大量的都是讀寫磁盤文件，性能當然低了，一個數量級，ms級，s級
問我，es上千萬數據的搜索，要耗費10s，大量讀寫磁盤了。
如果在es生產環境中，哪種資源最容易耗盡，那么就是內存了。排序和聚合都會耗費掉很多內存，所以給es進程分配足夠的jvm heap內存是很重要的。除了給jvm heap分配內存，還需要給予足夠的內存給os filesystem cache。因為lucene用的數據結構都是給予磁盤的格式，es是通過os cache來進行高性能的磁盤文件讀寫的。
關於機器的內存相關的知識，后面會有很深入的講解，這里先簡單提一下，一般而言，除非說你的數據量很小，比如就是一些os系統，各種信息管理系統，要做一個內部的檢索引擎，幾萬，幾十萬，幾百萬的數據量，對機器的資源配置要求還是蠻低的。一般而言，如果你的數據量過億，幾億，幾十億。那么其實建議你的每台機器都給64G的內存的量。
如果一個機器有64G的內存，那么是比較理想的狀態，但是32GB和16GB的內存也是ok的。具體的內存數量還是根據數據量來決定。但是如果一個機器的內存數量小於8G，那么就不太適合生產環境了，因為我們可能就需要很多小內存的機器來搭建集群。而大於64G的機器也不是很有必要。
2、CPU
大多數的es集群對於cpu的要求都會比較低一些，因此一台機器有多少個cpu core其實對生產環境的es集群部署相對來說沒有那么的重要了，至少沒有內存來的重要。當然，肯定是要用多核處理器的，一般來說2個cpu core~8個cpu core都是可以的。
此外，如果要選擇是較少的cpu core但是cpu性能很高，還是較多的cpu core但是cpu性能較為一般，那么肯定是選擇性能較為一般但是更多的cpu core。因為更多的cpu core可以提供更強的並發處理能力，遠比單個cpu性能高帶來的效果更加明顯。
3、磁盤
對於es的生產環境來說，磁盤是非常重要的，尤其是對那些大量寫入的es集群，比如互聯網公司將每天的實時日志數據以高並發的速度寫入es集群。在服務器上，磁盤是最慢的那個資源，所以對於大量寫入的es集群來說，會很容易因為磁盤的讀寫性能造成整個集群的性能瓶頸。
如果我們能夠使用SSD固態硬盤，而不是機械硬盤，那么當然是最好的，SSD的性能比機械硬盤可以高很多倍，可以讓es的讀寫性能都高很多倍。所以，如果公司出的起錢大量使用固態硬盤，那么當然是最好的。
如果我們在用SSD硬盤的化，那么需要檢查我們的I/O scheduler，需要正確的配置IO scheduler。當我們將數據寫入磁盤時，IO scheduler會決定什么時候數據才會真正的寫入磁盤，而不是停留在os cache內存緩沖中。大多數機器上，默認的IO scheduler是cfq，也就是completely fair queuing。
這個scheduler會給每個進程都分配一些時間分片，time slice，然后會優化每個進程的數據如何寫入磁盤中，優化的思路主要是根據磁盤的物理布局來決定如何將數據寫入磁盤，進而提升寫入磁盤的性能。這是針對機械硬盤做出的優化，因為機械硬盤是一種旋轉存儲介質，是通過機械旋轉磁盤+磁頭進行磁盤讀寫的機制。
但是scheduler的這種默認的執行機制，對於SSD來說是不太高效的，因為SSD跟機械硬盤是不一樣的，SSD不涉及到機械磁盤旋轉和磁頭讀取這種傳統的讀寫機制。對於SSD來說，應該用deadline/noop scheduler。deadline scheduler會基於寫操作被pending了多長時間來進行寫磁盤優化，而noop scheduler就是一個簡單的FIFO隊列先進先出的機制。
調整io scheduler可以帶來很大的性能提升，甚至可以達到數百倍。
如果我們沒有辦法使用SSD，只能使用機械硬盤，那么至少得盡量正確讀寫速度最快的磁盤，比如高性能的服務器磁盤。
此外，使用RAID 0也是一種提升磁盤讀寫速度的高效的方式，無論是對於機械硬盤，還是SSD，都一樣。RAID 0也被稱之為條帶式存儲機制，striping，在RAID各種級別中性能是最高的。RAID 0的基本原理，是把連續的數據分散存儲到多個磁盤上進行讀寫，也就是對數據進行條帶式存儲。這樣系統的磁盤讀寫請求就可以被分散到多個磁盤上並行執行。但是沒有必要使用鏡像或者RAID的其他模式，因為我們不需要通過RAID來實現數據高可用存儲，es的replica副本機制本身已經實現了數據高可用存儲。
最后，我們要避免跟網絡相關的存儲模式，network-attached storage，NAS，比如基於網絡的分布式存儲模式。雖然很多供應商都說他們的NAS解決方案性能非常高，而且比本地存儲的可靠性更高。但是實際上用起來會有很多性能和可靠性上的風險，一般因為網絡傳輸會造成較高的延時，同時還有單點故障的風險。
4、網絡
對於es這種分布式系統來說，快速而且可靠的網絡是非常的重要的。因為高速網絡通信可以讓es的節點間通信達到低延時的效果，高帶寬可以讓shard的移動和恢復，以及分配等操作更加的快速。現代的數據中心的網絡對於大多數的集群來說，性能都足夠高了。比如千兆網卡，這都是可以的。
但是要避免一個集群橫跨多個數據中心，比如異地多機房部署一個集群，因為那樣的話跨機房，跨地域的傳輸會導致網絡通信和數據傳輸性能較差。es集群是一種p2p模式的分布式系統架構，不是master-slave主從分布式系統。在es集群中，所有的node都是相等的，任意兩個node間的互相通信都是很頻繁和正常的。因此如果部署在異地多機房，那么可能會導致node間頻繁跨地域進行通信，通信延時會非常高，甚至造成集群運行頻繁不正常。
就跟NAS存儲模式一樣，很多供應商都說跨地域的多數據中心是非常可靠的，而且低延時的。一般來說，可能的確是這樣，但是一旦發生了網絡故障，那么集群就完了。通常來說，跨地域多機房部署一個es集群帶來的效益，遠遠低於維護這樣的集群所帶來的額外成本。
5、自建集群 vs 雲部署
現在一般很容易就可以拿到高性能的機器來部署集群：很多高性能的機器可以有上百G的內存資源，還有幾十個cpu core。但是同時我們也可以再雲供應商上，比如阿里雲，租用大量的小資源的虛擬機。那么對於自己購買昂貴高性能服務器自建集群，以及租用雲機器來部署，該選擇哪種方案呢？
你是自己購買5台，比如說，8核64G的物理機，搭建es集群
或者是，比如說，上阿里雲，或者其他的雲服務，購買了2核4G，16台，虛擬機，搭建es集群
你上阿里雲，也可以買到大資源量的虛擬機，4/8/16核64G
一般來說，對於es集群而言，是建議擁有少數機器，但是每個機器的資源都非常多，盡量避免擁有大量的少資源的虛擬機。因為對於運維和管理來說，管理5個物理機組成的es集群，遠遠比管理100個虛擬機組成的es集群要簡單的多。
同時即使是自建集群，也要盡量避免那種超大資源量的超級服務器，因為那樣可能造成資源無法完全利用，然后在一個物理機上部署多個es節點，這會導致我們的集群管理更加的復雜。
6、JVM
對於最新的es版本，一般多建議用最新的jvm版本，除非es明確說明要用哪個jdk版本。es和lucene都是一種滿足特殊需求的軟件，lucene的單元測試和集成測試中，經常會發現jvm自身的一些bug。這些bug涵蓋的范圍很廣，因此盡量用最新的jvm版本，bug會少一些。
就目前es 5.x版本而言，建議用jdk 8，而不是jdk 7，同時jdk 6已經不再被支持了。
如果我們用java編寫es應用程序，而且在使用transport client或者node client，要確保運行我們的應用程序的jvm版本跟es服務器運行的jvm版本是一樣的。在es中，有些java的本地序列化機制都被使用了，比如ip地址，異常信息，等等。而jvm可能在不同的minor版本之間修改序列化格式，所以如果client和server的jvm版本不一致，可能有序列化的問題。
同時官方推薦，絕對不要隨便調整jvm的設置。雖然jvm有幾百個配置選項，而且我們可以手動調優jvm的幾乎方方面面。同時遇到一個性能場景的時候，每個人都會第一時間想到去調優jvm，但是es官方還是推薦我們不要隨便調節jvm參數。因為es是一個非常復雜的分布式軟件系統，而且es的默認jvm配置都是基於真實業務場景中長期的實踐得到的。隨便調節jvm配置反而有可能導致集群性能變得更加差，以及出現一些未知的問題。反而是很多情況下，將自定義的jvm配置全部刪除，性能是保持的最好的。
7、容量規划
在規划你的es集群的時候，一般要規划你需要多少台服務器，每台服務器要有多少資源，能夠支撐你預計的多大的數據量。但是這個東西其實不是一概而論的，要視具體的讀寫場景，包括你執行多么復雜的操作，讀寫QPS來決定的。不過一般而言，根據講師的實際經驗，對於很多的中小型公司，都是建議es集群承載的數據量在10億規模以內。用最合理的技術做最合理的事情。
這里可以給出幾個在國內es非常適合的幾個場景，es是做搜索的，當然可以做某個系統的搜索引擎。比如網站或者app的搜索引擎，或者是某些軟件系統的搜索引擎，此外es還可以用來做數據分析。那么針對這幾個不同的場景，都可以給出具體建議。比如做網站或者app的搜索引擎，一般數據量會相對來說大一些，但是通常而言，一個網站或者app的內容都是有限的，不會無限膨脹，通常數據量從百萬級到億級不等，因此用於搜索的數據都放在es中是合理的。
然后一些軟件系統或者特殊項目的搜索引擎，根據項目情況不同，數據量也是從百萬量級到幾十億，甚至幾百億，或者每日增量幾億，都有可能，那么此時就要根據具體的業務場景來決定了。如果數據量特別大，日增量都幾億規模，那么其實建議不要將每天全量的數據都寫入es中，es也不適合這種無限規模膨脹的場景。es是很耗費內存的，無限膨脹的數據量，會導致我們無法提供足夠的資源來支撐這么大的數據量。可以考慮是不是就將部分熱數據，比如最近幾天的數據，放到es中做高頻高性能搜索，然后將大量的很少訪問的冷數據放大數據系統做離線批量處理，比如hadoop系統里面。
比如說，你預計一下，你的數據量有多大，需要多少台機器，每台機器要多少資源，來支撐，可以達到多大的性能
數據量 -> 性能，10億 -> 1s
es達到ms級的化，你必須要有足夠的os cache去緩存幾乎大部分的索引數據
10億，每條數據是多大，比如多少個字節，1k -> 100G
5台，64G，8核，總共有300G內存 -> 100G總數據量，300G，一半要分給es jvm heap，150G -> 100G，100G落地到磁盤文件加入很多es自己的信息，100G -> 200G
200G落地磁盤的數據，物理內存剩余的只有150G，可能還有一些操作系統，還有其他的損耗100G。
200G落地磁盤的數據，100G物理內存可以用來做os cache，50%的概率是基於os cache做磁盤索引文件的讀寫，幾秒，很正常啦。。。
根據我們的實踐經驗而言，一般來說，除非是你的機器的內存資源，完全可以容納所有的落地的磁盤文件的os cache，ms，否則的話，如果不是的話，會大量走磁盤，幾秒
同時如果數據量在10億以內的規模，那么一般而言，如果提供5台以上的機器，每台機器的配置到8核64G的配置，一般而言都能hold住。當然，這個也看具體的使用場景，如果你讀寫特別頻繁，或者查詢特別復雜，那么可能還需要更多的機器資源。如果你要承載更大的數據量，那么就相應的提供更多的機器和資源。
要提升你的es的性能，最重要的，還是說規划合理的數據量，物理內存資源大小，os cache。