喬叔 Elasticsearch Index 管理技巧與效能優化

Elasticsearch
Index 管理與效能優化技巧
Joe Wu (喬叔)
喬叔 - Elastic Stack 技術交流
https://www.facebook.com/Joe.ElasticStack
Copyright © 2021 一隻狗狗有限公司

● 2021 Feb, 獲得 2021 Elastic Silver Contributor
● 2020 Oct, 第12屆 iThome 鐵人賽 Elastic Stack on Cloud 組冠軍 [系列文章]
● 2019 ~ 協助影音串流公司針對日文搜尋進行優化，推坑導入
App Search, APM,
Elastic Cloud
● 2019 協助大陸電商大數據分析公司優化Elastic Stack 架構, ES 大升級與 Data
Center Migration
● 2018 Nov, Distributed & Search Solution Consultant @ US Blockchain Startup
● 2018 Oct, 台灣第一位 Elastic Certified Engineer
● 2016 Mar, 開始教授 Elasticsearch 課程、協助企業內訓及提供顧問服務
● 2015 Oct, 創業，並大量使用Elastic Stack 在產品開發 + 數據分析 + 運維監控
● 2013 Oct, Core Elasticsearch Training @ SFO
● 2013 May, 導入 ES 0.90 版在跨國軟體產品實作多語系搜尋(5M+ MAU)
Joe Wu (喬叔) 的 Elastic 之旅

Elasticsearch 大家都怎麼用？

Search Engine
全文檢索、資料比對
NoSQL
Database
Document Based,
Time Series DB
Big Data
System
Hadoop Data
Source
Obseverability
Logs, Metrics, Open
Tracing, Monitoring
OLAP
Online Anlaytical
Processing
Enterprise
Enterprise Search,
SIEM

大家最常遇到的問題？

資料格式錯了不能改…
速度太慢資料怎麼管?
儲存空間不夠
東西查出來不如預期
系統資源吃好兇
喬叔的問題：功能出太快追不完 ...

Elasticsearch 的運作與 Schema 很有關的!
資料格式錯了不能改…
東西查出來不如預期
儲存空間不夠
喬叔的問題：功能出太快追不完 ...

Elasticsearch Index 管理技巧

Index 建立前你應該要知道資料該怎麼被處理
● Text 欄位與 Analyzer 的運作
○ 全文檢索機制運作的背後，文字是如何透過 Lucene 處理的。
● Dynamic Mapping
○ 當一份被 indexing 進入 Elasticsearch 的文件，若是有一個欄位沒有在 mapping 中被定義
，Elasticsearch 會自動的判斷他的資料型態，並且依照預設或指定的規則，來產生這個新欄位
的 mapping 設定。
● Index Template
○ 當新的 Index 要被建立時，若符合設定好的 Index Template 中的 index_patterns，就會依照
Template 裡的設定來建立 Index。
● Index Alias
○ 透過別名的方式來存取一個或多個 Index。

→ 這題內容太多，不在今天的範圍。
● Dynamic Mapping
● Index Template
● Index Alias
歡迎來上我的 Elasticsearch 基礎實務班 ! XD

● Dynamic Mapping
○ 當一份被 indexing 進入 Elasticsearch 的文件，若是欄位沒有在 mapping 中事先被定義
● Index Template
● Index Alias

Dynamic Mapping 的資料型態判斷方式
↓這是用空間換來的便利

Dynamic Mapping 的實用技巧 (1/3)
● 在 Dynamic Template 中定義好合適的預設資料型態
○ 若 log 的格式有先定義好，大部份的字串欄位都不用被搜尋，只有特定的字串欄位會是 text 的
話，可將預設的字串欄位指定成 keyword，只針對特定的字串欄位宣告成 text。
○ 如果預設會進入的字串資料很明確就是 text，不需要使用到 Aggregation, Sorting 或是 Script 的
操作，因此不必保留 keyword 的 sub-field，即可明確指定為 text，甚至可調整 index_options 節
省空間。
○ 如果資料特性大多數值的欄位都會是有小數點的，而空間不是最大的考量，可設定數值預設為
double 或是 float。

● 統一的欄位的命名規則，來套用資料形態
○ 若值是日期時間，則必需是 _datetime 結尾。(e.g., create_datetime, modify_datetime)
○ 若值是整數的次數，則必需是 _count 結尾。(e.g., play_count, browse_count)
○ 將特定型態定義在欄位的開頭，例如： long_, double_, int_, text_。(e.g. text_description)
=> 只要大家按照規則命名欄位，就不用擔心忘記先設定好 Mapping 了。

● 必要的嚴謹，以避免意外發生
○ 請小心設定 Dynamic Template，特別是修改原先的 Dynamic Template時，否則會發生 Runtime
Error，也就是 indexing 才會發現有錯。
○ 關閉 Dynamic fields mapping: 沒事先定義的欄位，若是 indexing 進入 Elasticsearch 時
■ dynamic: false => 還是會存在 _source ，但是不會被 index ，搜尋時沒有作用。
■ dynamic: strict => 在 indexing 時遇到沒有宣告的欄位會直接拋出 exception。
○ 關閉日期或數值的自動判斷。
=> 避免手誤產生未預期的 Mapping，並造成無法修改 Mapping 的狀況。

● Dynamic Mapping
● Index Template
● Index Alias

Index Template 使用的建議
● 可以針對 Index Template 的 index_pattern 及 priority 建立結構化的管理方式，
例如 logs 與 logs-xxxxx-* 這樣的子、從關係。(會有繼承的效果)
● version 一定要給，早期沒有 _meta 時可以考慮以日期來當版本號，不過有
_meta 後，會建議將此 index template 的基本描述及最後更新時間記錄在
_meta 中，以便於維護及管理。
● 可共用的設置抽出成 Component Template，可以當作某種角色的定義，讓管理
更容易。
● 在設計好之後，請多使用 Simulate API 來驗證這個 Index Template 的產生結果
及影響範圍。
● Elastic 官方還有其他的 Index Template 及 Component Template，在使用前可
以多參考官方或其他人的 Template 設計方式。

Index Alias 的 Best Practices (1/2)
● 盡量全面使用 Index Aliases 來存取 index
○ 若非 time series index，原 Index 可配合版本管理的小技巧，加上 _v1 之類的版本編號，而
Alias 則可用原名，例如：song alias 指向 song_v1 的 index。
=> 日後 Index 要修改、甚至要重建並 reindex 資料時，就不容易影響到使用端了。
● 善用 Index Aliases 搭配 Filter
○ 適度的將 filter 封裝在 alias 中，減少使用端的查詢複雜化。
○ 資料存取範圍的權限管理：限定使用者只能存取特定的子集合的資料、或是限定時間內的資料，
而配合 security 的權限處理，可避免使用者存取到不應取得的資料，或是一口氣查詢太多舊資
料導致效能的影響。

Index Alias 的 Best Practices (2/2)
● 配合 routing 來指定資料寫入到特定的 shard
○ 資料在 Indexing 進入 Elasticsearch 時，會依照 routing value 決定資料要寫入到哪個 shard 身
上，但如果有指定的 routing value，就可以決定同樣 routing value 的資料會被計算放到同樣的
shard 身上，這樣對於 performance 的優化或是資料的管理上都可以有許多應用的方式，而
alias 就能配合指定 routing 的值來達到這類型的運用。
=> 相同使用者或相同地區的資料寫到相同的 shard 來優化查詢效能。
● 配合 Index Lifecycle Management (ILM)
○ 隨著時間增長的資料，使用 ILM 來管理這些資料時，其中就是搭配 Index Alias 來切換寫入時要
指定到的實體 Index 在哪邊。

資料進入 Elasticsearch 之後呢？
儲存空間不夠

在 Elasticsearch 管理 Index 的資料時應該考量到…
Segment Files 的數量：數量愈多對查詢的速度與磁碟的空間愈不好。
Shard 的數量：愈多對 Indexing 的速度愈好，但對查詢成本較高，單一 Shard 愈大對 Cluster 的
Rebalance 的成本愈高。
Index 的大小：愈大對於查詢效率愈好，以 Time-based 資料來看的話，影響的是資料移轉到下一個階段的
等待時間。
資料的新舊程度：新的資料通常使用頻率較頻繁，會給較好的硬體資源、較舊的資料較少使用，可配置較差
的硬體資源。
時間顆粒度：當資料量很大時，在觀察過往的資料往往時間顆粒度會抓較大，並且觀察彙總的結果 (例如：
每天的 log 數量、每天的總銷售金額、每天每部影片各別的觀看次數 …等)。
Index 愈來愈多：資源總是有限，太舊的資料會面臨刪除，可保留彙總的結果。
資料的安全性：除了存取控制要妥善的限制之外，資料的備份也是非常重要的機制。

大部份存在 ES 的資料，都是隨著時間變化的…

Elasticsearch Index 管理架構
● Index Lifecycle
Management
○ Hot Warm Cold
Architecture
○ Rollover
○ Shrink + Compress
○ Force Merge
○ Freeze
● Rollup
● Transform
● Snapshot Lifecycle
Management

使用 Index Lifecycle Management (ILM) (ES 6.7 GA) 來管理資料的 Hot Warm Cold Architecture。
● Hot Phase: 新的資料大量寫入Hot Nodes，要快，就配置較多的 Primary shards。
● Rollover: 隨時間及資料量的成長，透過Rollover 將 Index 進行 rotate，產生新的 Index 來接新的資料，而原先的
Index 會進入下一個 Warm 的階段。
● Warm Phase: 進入到 Warm data 的階段，會進入read-only ，所以會透過 Force Merge 與 Shrink 將 Segment
Files 數量與 Shards 數量進行最佳化，也可同時配合Compress 進行儲存空間的優化。
● Cold Phase: 資料進入 Cold data 階段，會將 Index 進行 Freeze ，以減少 JVM heap 的使用量，提供較高的延遲反
應，但還是能即時使用的服務狀態。
● Delete: 再更久的資料，可再確認已經被備份過之後進行刪除。

使用 Rollup (ES 6.3 推出) 將資料以較大的時間顆粒度來儲存
● Rollup 可以從 Hot, Warm, Cold 任何的 Index 當中把資料讀出，並且以較大的時間顆粒度進行彙總運算，並將結果
儲存新的 Rollup Index 中。
● Rollup 是定時執行，同時Rollup 的資料在透過 _rollup_search 查詢時，可混搭 Live Data + Rollup Data，結果會自
動合併並去除掉重覆的，也因此當舊的資料被刪除後，存在Rollup 的資料一樣能提供彙總後的
查詢結果。
● Cron Job + Batch => Aggregation (Date Histogram, Histogram, Terms, Metrics)
● Experimental，目前是獨立的功能，因此Rollup Index 不能 Rollover，未來會轉成為ILM 當中的一個Action。
● 騰訊的 Practices:
○ 在原始的即時資料監控下，監控的時間顆粒度是10秒。
○ 在一個月以前的監控數據，時間顆粒度是1小時。

使用 Transform (ES 7.2 推出) 將資料以另外的分析結果來儲存：
● 將資料以 Pivot 的方式進行分析運算、並將結果儲存在獨立的Index 中。
● 適合複雜的 Aggregation 的運算及彙總報表的定期處理工作。
● 也可以這個機制從查詢的彙總結果建立成Index，並當作 Ingest 處理時 Enrich 資料的 Lookup Data Source。
=> 每月營銷報表、每月產品銷量分析、每日影片播放量
使用 Snapshot Lifecycle Management (SLM) 來管理資料的備份。
● 設定定期的備份。
● 設定備份的保存時間及數量，確保備份所佔用的空間不會無限增長。

了解 Index 的管理技巧之後，效能要怎麼調?

你知道 Elasticsearch 如何運作的嗎？
儲存空間不夠

Terminology
Cluster: A group of nodes that work together to operate Elasticsearch.
一群會互相合作、分工處理任務、互相備援的 ES nodes 們。
Node: A Java process that runs the Elasticsearch software.
Index: A group of shards that form a logical data store.
一個資料庫，並且擁有一或多個分片( shards )，資料被分配存放在這些分片之中。
Shard: A Lucene index that stores and processes a portion of an Elasticsearch index.
一個 Lucene 索引的儲存單位，裡面存有多個的Segments，同時也是 Cluster 資料搬
移時的最小單位。
Segment: A Lucene segment that immutably stores a portion of a Lucene index.
實際寫在 Disk 的 Lucene 索引檔案，是唯讀的。
Document: A record that is submitted to and retrieved from an Elasticsearch index.

How the indexing request works?
Shard 數量決定 Indexing
處理的分散能力
圖片來源：https://www.elastic.co/pdf/elasticsearch-sizing-and-capacity-planning.pdf

How the searching request works?
從許多 Segment Files
中進行查詢
查詢的方式決定記憶體用多少圖片來源：https://www.elastic.co/pdf/elasticsearch-sizing-and-capacity-planning.pdf

你知道 Elasticsearch 的資料是怎麼保存的嗎?

Elasticsearch
Persistence Model
● Translog: 避免資料遺失
○ 預設 5秒寫入 Disk
● Refresh: 為了讓資料盡快能
被搜尋到
○ 預設 1秒呼叫 Lucene flush
● Flush: 讓 Segment Files 的
資料被保存到 Disk
○ 512 MB or 30分鐘觸發
Lucene Commit
https://www.elastic.co/blog/every-shard-deserves-a-home
1s
5s
512mb
or 30m
預設的配置上，你是有可能
會遺失資料的!
(Replica 是有幫助的)

Indexing 索引效能優化 (1/2)
● Indexing 大量資料時，善用 bulk request。(一次資料量太大也會吃光記憶體，要小心)
● 使用 multi-thread / multi-workers 來 indexing 資料進入 Elasticsearch。
● 調低或暫時關閉 refresh_interval。
● 指定 Routing 的方式，減少 Thread 的數量。(寫到多個 shards 時，每個 shard 會有對應的 thread。)
● 第一批資料 indexing 進入 Elasticsearch 之前，先不要設定 Replica。
● 關閉 java process swapping。

Indexing 索引效能優化 (2/2)
● 確保 Filesystem 有足夠的 memory cache。
● 使用 auto-generated ids。( ES 自動建立的 ID，因含有時間，所以不用檢查是否重覆，速度會快。)
● 使用更快速的儲存硬體。
● 調高 indexing buffer 大小。
● 使用 cross-cluster replication 的配置讓 searching 的處理不會佔用 indexing 的資源。
● 調整 Translog 的 Flush 設定，減少 Disk I/O。(大量 indexing 資料時，若系統 crash 會掉資料的風險)

Searching 搜尋效能優化 (1/2)
● 與相關性計分無關的Query，都使用 Filter 來處理，增加 Cache 利用率。
● 確保 Filesystem 有足夠的 memory cache。(JVM Heap vs. OS filesystem 1:1，只是最通用的建議)
● 使用更好的硬體。(看 search 處理是 I/O bound 或 CPU bound，I/O bound 可分給 filesysteme 更多記憶體)
● Document modeled。(少用 join, nested, parent-child, fuzzy, regex，多考慮空間換時間)
● 搜尋的欄位愈少愈好。
● 依照 Aggregation 的需求 Pre-index 資料。(空間換時間: 先把資料整理在新欄位中，讓 aggs 減少運算)
● 盡量使用 keyword 來當作 identifiers 的型態。
● Scripts 是昂貴的，應該盡量少用。
● 使用日期時間當搜尋條件時，可以取整點，增加Cache 利用率。
● 將 filter 條件切割來提高 Cache 利用率。( now-1h to now => now-1h ,now-1h/m, now/m, now)

Searching 搜尋效能優化 (2/2)
● 將不會再寫入的 Index 進行 force-merge。
● 將常使用到 Terms Aggregations 的欄位，設定 eager_global_ordinals: true (預設是 lazy loading)
● 預熱 filesystem cache。(index.store.preload)
● 使用 index sorting 的設定，來加速多個AND 或 OR 組合的搜尋。(針對重覆資料愈多的，愈有效)
● 使用 preference 控制 searching request 的 routing 來增加 cache 使用率。(導到同一台Node)
● Replica 數量愈多不見得對搜尋愈有幫助。
(評估好 availability 後，不要設過多的 replica)
● 管理好使用 Elasticsearch 的方式，不要讓使用者擁有太大的彈性。
(搜尋範圍的上限、 aggs的複雜度)
● 使用 Profile API 來優化 Search Request。
● 在 query 或 aggregation 處理需求量較高的環境中，安排特定的Coordinating Node。

Index 的儲存空間最佳化 (1/2)
● 優化 Mapping 的設定
○ disable 不需要被搜尋的欄位。
○ 不需計算 score 的欄位可以關掉 norms。
○ 調整 index_options 到需要的層級即可。
○ 避免使用預設的 dynamic string mapping。(text + keyword 很佔空間)
○ 減少 _source 裡儲存的資料。(還是可以搜尋，只是回傳值不在 _source 裡)
○ 設置 best_compression 來提升資料壓縮率。
○ 使用較省空間的資料型態。

Index 的儲存空間最佳化 (2/2)
● 減少 Shard 的數量，增加 Shard 的大小。
● 透過 Force Merge 來減少 Segment files 數量太多所佔用的空間。
● 將相似的文件透過 index sorting 排在一起以提升壓縮率。
● 讓 Document 的欄位順序保持一致以提升壓縮率。
● 使用 Rollup 的機制，將歷史資料的儲存顆粒度提升。
(這個可以差到數千、萬倍以上…)
● 使用 Hot Warm Cold Architecture 來分配合適的儲存硬體。

Shard 的最佳化管理
● Search 在執行時每個 Shard 有獨立的 Thread，數量太多會拖慢速度。(pool size: (cpu*3/2) + 1)
● 每個 Shard 都有基本運作的成本，數量太多成本愈高。
● 指定 Shard 在 Cluster 中的分配方式，以優化儲存硬體的資源。
(shard allocation awareness)
● 刪除整批資料時，以Index 為單位來刪除，而不要從一批Documents 來刪除。(segment files)
● 建議使用 Data Stream 或 Index Lifecycle Management (ILM) 來管理 time series 資料。
● 一般會建議讓單一 Shard 的大小在 10 ~ 50 GB 左右。(太大的成本是 rebalance)
● 1GB 的 Heap Memory 大約能處理 20 個 Shards。(主要還是依 cluster 規格與使用方式來評估)
● 一個 Index 有多個 Shard 時，避免大多數的 Shard 都被分配在同一台 Node 身上。
● 定期 review 是否有 oversharding 的狀況，並且進行調整。

另外很重要的一點，升到最新版！

來說一點新東西 - Elasticsearch 7.x

Off Heap
● 7.3 released & 7.7 enhanced.
● 將本來存在 Heap 中的 Term Index (tip)，寫到 off heap，透過 MMAP 在需要時
載入到 OS filesystem 記憶體中處理。
● 與 7.6 相比，7.7 在 Geonames 的 benchmark 資料集跑 benchmark，記憶體使
用減少 3 ~ 7倍，NYC taxis 與 HTTP logs 減少近100倍。
● 可增加 OS filesystem memory 的使用分配，減少 JVM heap，在存放 log 與
metric 的巨量資料 Cluster 中，常常 JVM heap size 使用率 > OS filesystem
cache，這部份的調整是很好的優化。(32G 的 JVM Compressed OOPS 限制)

● Elasticsearch 7.0 released
● Introduced Lucene 8.0 with Block-max WAND 演算法
● 效能優化
○ term queries between 3x and 7x faster
○ conjunctions between 3% and 7x faster
○ disjunctions between -8% (slightly slower) and 15x faster
○ Other queries such as phrases and constant-scoring queries like prefix queries got speedups
too
● 透過 track_total_hits 參數調整。
Search Result Hits.Total 不再預設回傳所有比對結果的筆數

Searchable Snapsnot
● 致敬 AWS Elasticsearch Service 的 Ultrawarm。
● 7.10 釋出，目前還在 Beta 版。
● 更省錢!!

黑科技 - 不用先定義 Schema 的 Runtime Field
● since 7.11, available in Beta
● 不受限於 index.mapping.total_fields.limit 限制。
● 可動態修改 Mapping 的型態，日後決定 schema 時，可配合 Index Template +
Rollover 讓之後的資料 follow schema 的設定。
● 因為執行查詢的時間會變得很慢，所以建議使用另個新推出的 asynchronous
search。

● 喬叔帶你上手 Elastic Stack https://ithelp.ithome.com.tw/users/20129543/ironman
● Elasticsearch sizing and capacity planning webinar:
https://www.elastic.co/webinars/elasticsearch-sizing-and-capacity-planning
● 官方 Benchmark 工具 - ES Rally: https://esrally.readthedocs.io
● 喬叔的實體課程，請至 FB 粉絲頁查看。
○ 喬叔 - Elastic Stack 技術交流: https://www.facebook.com/Joe.ElasticStack
○ 最近一期 2021 年 7 月預計將開設二天的 ES 基礎實務班。 → 聽完今天分享，想要加強自己的 ES 基礎，快來哦!
■ 詳細資訊與報名連結： https://forms.gle/WdchC3trqS6T61Zg7
○ 有企業包班、進階課程需求，請洽 courses@onedoggo.com
● 喬叔的顧問服務、專案合作，請洽 joe@onedoggo.com
可以幫助你的一些資源與工具

喬叔 Elasticsearch Index 管理技巧與效能優化

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (20)

Semelhante a 喬叔 Elasticsearch Index 管理技巧與效能優化

Semelhante a 喬叔 Elasticsearch Index 管理技巧與效能優化 (20)

喬叔 Elasticsearch Index 管理技巧與效能優化