如何進行Elasticsearch性能優化

這期內容當中小編將會給大家帶來有關如何進行Elasticsearch性能優化，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

Elasticsearch是目前大數據領域最熱門的技術棧之一，經過近8年的發展，已從0.0.X版升級至6.X版本，雖然增加了很多的特性和功能，但是在主體架構上，還是沒有太多的變化。下面就把我對于ES使用實踐的一些經驗總結一下，供大家參考；也請大家拍磚。

一、 硬件環境選擇：

如果有條件，盡可能使用SSD硬盤， 不錯的CPU。ES的厲害之處在于ES本身的分布式架構以及lucene的特性。IO的提升，會極大改進ES的速度和性能。

二、系統拓樸設計：

ES集群在架構拓樸時，一般都會采用Hot-Warm的架構模式，即設置3種不同類型的節點：Master節點、Hot 節點和 Warm節點。

Master節點設置：一般會設置３個專用的maste節點，以提供最好的彈性擴展能力。當然，必須注意discovery.zen.minimum_master_nodes 屬性的設置，以防split-brain問題，使用公式設置：N/2+1(N為候選master節點數）。 該節點保持: node.data: false ; 因為master節點不參與查詢、索引操作，僅負責對于集群管理，所以在CPU、內存、磁盤配置上，都可以比數據節點低很多。

Hot節點設置： 索引節點（寫節點），同時保持近期頻繁使用的索引。 屬于IO和CPU密集型操作，建議使用SSD的磁盤類型，保持良好的寫性能；節點的數量設置一般是大于等于3個。將節點設置為hot類型:

node.attr.box_type: hot

針對index, 通過設置index.routing.allocation.require.box_type： hot 可以設置將索引寫入hot節點。

Warm節點設置： 用于不經常訪問的read-only索引。由于不經常訪問，一般使用普通的磁盤即可。內存、CPU的配置跟Hot節點保持一致即可；節點數量一般也是大于等于3個。

當索引不再被頻繁查詢時，可通過index.routing.allocation.require.box_type： warm， 將索引標記為warm, 從而保證索引不寫入hot節點，以便將SSD磁盤資源用在刀刃上。一旦設置這個屬性，ES會自動將索引合并到warm節點。同時，也可以在elasticsearch.yml中設置 index.codec: best_compression 保證warm 節點的壓縮配置

Coordinating節點：協調節點用于做分布式里的協調，將各分片或節點返回的數據整合后返回。在ES集群中，所有的節點都有可能是協調節點，但是，可以通過設置node.master、node.data 、 node.ingest 都為 false 來設置專門的協調節點。需要較好的CPU和較高的內存。

三、ES的內存設置：

由于ES構建基于lucene, 而lucene設計強大之處在于lucene能夠很好的利用操作系統內存來緩存索引數據，以提供快速的查詢性能。lucene的索引文件segements是存儲在單文件中的，并且不可變，對于OS來說，能夠很友好地將索引文件保持在cache中，以便快速訪問；因此，我們很有必要將一半的物理內存留給lucene ; 另一半的物理內存留給ES（JVM heap )。所以， 在ES內存設置方面，可以遵循以下原則：

1. 當機器內存小于64G時，遵循通用的原則，50%給ES，50%留給lucene。

2.  當機器內存大于64G時，遵循以下原則：

a. 如果主要的使用場景是全文檢索, 那么建議給ES Heap分配 4~32G的內存即可；其它內存留給操作系統, 供lucene使用（segments cache), 以提供更快的查詢性能。

b.  如果主要的使用場景是聚合或排序， 并且大多數是numerics, dates, geo_points 以及not_analyzed的字符類型， 建議分配給ES Heap分配 4~32G的內存即可，其它內存留給操作系統，供lucene使用(doc values cache)，提供快速的基于文檔的聚類、排序性能。

c.  如果使用場景是聚合或排序，并且都是基于analyzed 字符數據，這時需要更多的 heap size, 建議機器上運行多ES實例，每個實例保持不超過50%的ES heap設置(但不超過32G，堆內存設置32G以下時，JVM使用對象指標壓縮技巧節省空間)，50%以上留給lucene。

3. 禁止swap，一旦允許內存與磁盤的交換，會引起致命的性能問題。 通過： 在elasticsearch.yml 中 bootstrap.memory_lock: true， 以保持JVM鎖定內存，保證ES的性能。

4. GC設置原則：

a. 保持GC的現有設置，默認設置為：Concurrent-Mark and Sweep (CMS)，別換成G1GC，因為目前G1還有很多BUG。

b. 保持線程池的現有設置，目前ES的線程池較1.X有了較多優化設置，保持現狀即可；默認線程池大小等于CPU核心數。如果一定要改，按公式（（CPU核心數* 3）/ 2）+ 1 設置；不能超過CPU核心數的2倍；但是不建議修改默認配置，否則會對CPU造成硬傷。

四、 集群分片設置：

ES一旦創建好索引后，就無法調整分片的設置，而在ES中，一個分片實際上對應一個lucene 索引，而lucene索引的讀寫會占用很多的系統資源，因此，分片數不能設置過大；所以，在創建索引時，合理配置分片數是非常重要的。一般來說，我們遵循一些原則：

1. 控制每個分片占用的硬盤容量不超過ES的最大JVM的堆空間設置（一般設置不超過32G，參加上文的JVM設置原則），因此，如果索引的總容量在500G左右，那分片大小在16個左右即可；當然，最好同時考慮原則2。

2. 考慮一下node數量，一般一個節點有時候就是一臺物理機，如果分片數過多，大大超過了節點數，很可能會導致一個節點上存在多個分片，一旦該節點故障，即使保持了1個以上的副本，同樣有可能會導致數據丟失，集群無法恢復。所以， 一般都設置分片數不超過節點數的3倍。

五、 Mapping建模:

1. 盡量避免使用nested或 parent/child，能不用就不用；nested query慢， parent/child query 更慢，比nested query慢上百倍；因此能在mapping設計階段搞定的（大寬表設計或采用比較smart的數據結構），就不要用父子關系的mapping。

2. 如果一定要使用nested fields，保證nested fields字段不能過多，目前ES默認限制是50。參考：

index.mapping.nested_fields.limit ：50

因為針對1個document, 每一個nested field, 都會生成一個獨立的document, 這將使Doc數量劇增，影響查詢效率，尤其是JOIN的效率。

3. 避免使用動態值作字段(key),  動態遞增的mapping，會導致集群崩潰；同樣，也需要控制字段的數量，業務中不使用的字段，就不要索引。控制索引的字段數量、mapping深度、索引字段的類型，對于ES的性能優化是重中之重。以下是ES關于字段數、mapping深度的一些默認設置：

index.mapping.nested_objects.limit :10000

index.mapping.total_fields.limit:1000

index.mapping.depth.limit: 20

六、 索引優化設置：

1.設置refresh_interval 為-1，同時設置number_of_replicas 為0，通過關閉refresh間隔周期，同時不設置副本來提高寫性能。

2. 修改index_buffer_size 的設置，可以設置成百分數，也可設置成具體的大小，大小可根據集群的規模做不同的設置測試。

indices.memory.index_buffer_size：10%（默認）

indices.memory.min_index_buffer_size： 48mb（默認）

indices.memory.max_index_buffer_size

3. 修改translog相關的設置：

a. 控制數據從內存到硬盤的操作頻率，以減少硬盤IO。可將sync_interval的時間設置大一些。

index.translog.sync_interval：5s(默認)。

b. 控制tranlog數據塊的大小，達到threshold大小時，才會flush到lucene索引文件。

index.translog.flush_threshold_size：512mb(默認)

4. _id字段的使用，應盡可能避免自定義_id, 以避免針對ID的版本管理；建議使用ES的默認ID生成策略或使用數字類型ID做為主鍵。

5. _all字段及_source字段的使用，應該注意場景和需要，_all字段包含了所有的索引字段，方便做全文檢索，如果無此需求，可以禁用；_source存儲了原始的document內容，如果沒有獲取原始文檔數據的需求，可通過設置includes、excludes 屬性來定義放入_source的字段。

6. 合理的配置使用index屬性，analyzed 和not_analyzed，根據業務需求來控制字段是否分詞或不分詞。只有 groupby需求的字段，配置時就設置成not_analyzed, 以提高查詢或聚類的效率。

七、 查詢優化：

1. query_string 或 multi_match的查詢字段越多， 查詢越慢。可以在mapping階段，利用copy_to屬性將多字段的值索引到一個新字段，multi_match時，用新的字段查詢。

2. 日期字段的查詢， 尤其是用now 的查詢實際上是不存在緩存的，因此， 可以從業務的角度來考慮是否一定要用now, 畢竟利用query cache 是能夠大大提高查詢效率的。

3. 查詢結果集的大小不能隨意設置成大得離譜的值， 如query.setSize不能設置成 Integer.MAX_VALUE， 因為ES內部需要建立一個數據結構來放指定大小的結果集數據。

4. 盡量避免使用script，萬不得已需要使用的話，選擇painless & experssions 引擎。一旦使用script查詢，一定要注意控制返回，千萬不要有死循環（如下錯誤的例子），因為ES沒有腳本運行的超時控制，只要當前的腳本沒執行完，該查詢會一直阻塞。

如： {

    “script_fields”：{

        “test1”：{

            “lang”：“groovy”，

            “script”：“while（true）{print 'don’t use script'}”

        }

    }

}

5. 避免層級過深的聚合查詢， 層級過深的group by , 會導致內存、CPU消耗，建議在服務層通過程序來組裝業務，也可以通過pipeline的方式來優化。

6. 復用預索引數據方式來提高AGG性能：

如通過 terms aggregations 替代 range aggregations， 如要根據年齡來分組，分組目標是: 少年（14歲以下） 青年（14-28） 中年（29-50） 老年（51以上）， 可以在索引的時候設置一個age_group字段，預先將數據進行分類。從而不用按age來做range aggregations, 通過age_group字段就可以了。

7. Cache的設置及使用：

a) QueryCache: ES查詢的時候，使用filter查詢會使用query cache, 如果業務場景中的過濾查詢比較多，建議將querycache設置大一些，以提高查詢速度。

indices.queries.cache.size： 10%（默認），可設置成百分比，也可設置成具體值，如256mb。

當然也可以禁用查詢緩存（默認是開啟）， 通過index.queries.cache.enabled：false設置。

b) FieldDataCache: 在聚類或排序時，field data cache會使用頻繁，因此，設置字段數據緩存的大小，在聚類或排序場景較多的情形下很有必要，可通過indices.fielddata.cache.size：30% 或具體值10GB來設置。但是如果場景或數據變更比較頻繁，設置cache并不是好的做法，因為緩存加載的開銷也是特別大的。

c) ShardRequestCache: 查詢請求發起后，每個分片會將結果返回給協調節點(Coordinating Node), 由協調節點將結果整合。

如果有需求，可以設置開啟;  通過設置index.requests.cache.enable: true來開啟。

不過，shard request cache只緩存hits.total, aggregations, suggestions類型的數據，并不會緩存hits的內容。也可以通過設置indices.requests.cache.size: 1%（默認）來控制緩存空間大小。

上述就是小編為大家分享的如何進行Elasticsearch性能優化了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。