目錄

集群版本： 7.17.6

解釋幾個概念：

段（Segment）

合并(Merge)

索引設置：

壓縮方式(index.codec)：

測試設置前提條件

對比 在創建的時候指定壓縮類型（index.codec）

對比 在寫入完成后的索引更改壓縮類型

線上索引更改壓縮方式前后對比

測試總結

API調用

查看狀態

查看索引配置

創建索引配置

更新索引配置

強制合并索引

為什么默認啟用 LZ4 壓縮，而不是best_compression

通過共享存儲的方式節省存儲的成本

---

集群版本： 7.17.6

解釋幾個概念：

段（Segment）

可以理解為 是ES 索引存儲數據的最小單位，索引 --> 分片--> 段，Elasticsearch 中的分片是 Lucene 索引，而 Lucene 索引又被分解為多個段。段是索引中的內部存儲元素，用于存儲索引數據，

合并(Merge)

主要指段合并，段是不可變的。較小的段會定期合并到較大的段中，以控制索引大小并清除刪除的內容。段合并的觸發一般會:

1. 在索引的數據調整（寫入/刪除）操作
2. 在后臺定期觸發，為了減少開銷，不需要用戶干預，比如說ILM 、refresh_interval
3. 用戶觸發調整：強制合并（常用）、減少索引分片 和 分割索引分片

強制合并的幾點建議：
? ? 不要并行過多請值合并，Merge是一項資源密集型操作。
? ? 不要合并出超過5G的段，影響性能
? ? 不要在hot節點上執行，影響寫入速度，在cold節點 或者只讀索引

索引設置：

配置分為為靜態（static）和 動態（dynamic）

• static:只能在索引創建時 或 在關閉的索引上設置。
• dynamic:可以使用API 實時進行更改 。

7.17 版本中：關閉的索引更改其靜態或者動態配置時可能會導致索引錯誤，只能不刪除并重新創建索引。
8.17 版本中：索引reopen 設置 true(默認為 false)可以修改靜態配置。
index.number_of_shards 此設置只能在創建索引時設置。無法在已關閉的索引上更改。8.17 版本 也是一樣

壓縮方式(index.codec)：

The default value compresses stored data with LZ4 compression, but this can be set to best_compression which uses DEFLATE for a higher compression ratio, at the expense of slower stored fields performance. If you are updating the compression type, the new one will be applied after segments are merged. Segment merging can be forced using force merge.

• 存儲數據壓縮方式 ，屬于靜態（static）配置
• 存儲數據默認是 LZ4壓縮，best_compression 壓縮率比LZ4 要好(8.17 版本中最多可降低約 28% 的存儲使用量)，
• 代價是讀寫性能會降低，優先 選擇cold 狀態的 只讀索引測試
• 在新建索引和段合并過程中更改壓縮類型

測試設置前提條件

• es-lucene本身的壓縮率受index字段的影響，暫不討論，只討論best_compression、default兩種方式的壓縮后存儲存在多大的差別。
• 計算存儲：是計算的store.size大小， 包含副本索引，測試中所有的副本(number_of_replicas)都設置為1。
• max_num_segments=1 不是整個索引的segments.count等于1 ，而是每個分片的segments.count等于1。所以測試中索引_forcemerge后 segments.count等于4 是正常的。
• 在已有索引情況下更改壓縮類型，如果索引比較大，就不適合使用max_num_segments=1強制合并成一個大的段，這樣就有可能涉及到某些比較大的段不再觸發段合并。所以可能存在一個索引存在兩種壓縮方式

對比 在創建的時候指定壓縮類型（index.codec）

best_compression、 default
不存在指定lz4的選項 "unknown value for [index.codec] must be one of [default, best_compression] but was: lz4"

#創建my-index-00【1-4】四個索引，分別10000條寫入相同的數據。
my-index-001，my-index-004    best_compression
my-index-002，my-index-003    default#寫入前GET /_cat/indices/my-index-*?v&h=index,pri,rep,docs.count,store.size,pri.store.size,segments.count&bytes=b
index        pri rep docs.count store.size pri.store.size segments.count
my-index-001   2   1          0       904b           452b              0
my-index-002   2   1          0       904b           452b              0
my-index-003   2   1          0       904b           452b              0
my-index-004   2   1          0       904b           452b              0寫入后  best_compression方式存儲使用為default方式的 91% 左右。
index        pri rep docs.count store.size pri.store.size segments.count
my-index-001   2   1     100000    6328997        3118873             24
my-index-002   2   1     100000    6954883        3464912             28
my-index-003   2   1     100000    6934591        3433258             28
my-index-004   2   1     100000    6328400        3112546             26#進行強制合并 max_num_segments=1 后, best_compression方式存儲使用為default方式的 88% 左右。
index        pri rep docs.count store.size pri.store.size segments.count
my-index-001   2   1     100000    6058071        3015574              4
my-index-002   2   1     100000    6817828        3408515              4
my-index-003   2   1     100000    6810228        3402639              4
my-index-004   2   1     100000    6036888        3004366              4

結論：在創建索引的時候就指定best_compression 壓縮方式 只占用default方式的 91% 左右的存儲空間，通過段合并存儲空節省能提升到12% 左右

對比 在寫入完成后的索引更改壓縮類型

問題：
an't update non dynamic settings [[index.codec]] for open indices [[my-index-002/WYo5u-cITcuOWQH3P3RQ6A]]
需要對先進行關閉處理，配置完成后打開，8.17的reopen策略可以自動幫助用戶關閉切重新打開，7.17沒有此功能。

#創建my-index-00【5-6】四個索引，分別10000條寫入相同的數據。ps:my-index-*6個索引的數據都是重復且相同
my-index-002，my-index-003    index.codec:default寫入后存儲情況
index        pri rep docs.count store.size pri.store.size segments.count
my-index-001   2   1     100000    6058071        3015574              4
my-index-002   2   1     100000    6817828        3408515              4
my-index-003   2   1     100000    6810228        3402639              4
my-index-004   2   1     100000    6036888        3004366              4
my-index-005   2   1     100000    6823873        3430651             14
my-index-006   2   1     100000    6836865        3434722             16關閉索引
POST /my-index-005,my-index-006/_close?wait_for_active_shards=0
#更改壓縮類型
PUT /my-index-005,my-index-006/_settings
{"index.codec" : "best_compression"
}
#重新打開
POST /my-index-005,my-index-006/_open#進行強制合并 max_num_segments=1 后, 與創建是的壓縮方式就指定為best_compression 空間存儲使用基本保持一致。
index        pri rep docs.count store.size pri.store.size segments.count
my-index-001   2   1     100000    6058071        3015574              4
my-index-002   2   1     100000    6817828        3408515              4
my-index-003   2   1     100000    6810228        3402639              4
my-index-004   2   1     100000    6036888        3004366              4
my-index-005   2   1     100000    6012083        3007382              4
my-index-006   2   1     100000    6001636        3001571              4

結論：在寫入完成后的索引更改壓縮方式與創建是的壓縮方式就指定為best_compression 空間存儲使用基本保持一致，基本都節省 10% 左右的存儲空間

線上索引更改壓縮方式前后對比

更改前index.codec:default
index              pri rep docs.count  store.size pri.store.size segments.count
applog-2025.02.15   1   1   10514847  6809313634     3404656817             58
applog-2025.02.16   1   1    9974249  6491719356     3245859678             46
applog-2025.02.23   1   1   11139687  7139016590     3569508295             56
applog-2025.02.22   1   1   10958802  7089500416     3544750208             52#下面兩個所以通過重啟的方式更改壓縮方式
applog-2025.02.16，applog-2025.02.23    index.codec:best_compression#進行強制合并 max_num_segments=1 后
index              pri rep docs.count  store.size pri.store.size segments.count
applog-2025.02.15   1   1   10514847  6776067954     3388033977              4
applog-2025.02.16   1   1    9974249  4963880914     2481940457              4
applog-2025.02.23   1   1   11139687  5358329648     2679164824              4
applog-2025.02.22   1   1   10958802  7056313752     3528156876              4

結論：更改best_compression壓縮方式與強制合并后，applog-2025.02.16，applog-2025.02.23兩個索引 存儲空間節省可以達到24%~25%。

測試總結

• 關于讀性能: 多次查詢測試，性能基本不受best_compression壓縮方式的影響。
• 關于寫性能: 集群寫入壓力較小，沒有明顯差別。生產環境建議還是需要使用只讀索引。
• 關于降存儲使用量:可降低約 25%~10% 的存儲使用量。
• 關于操作：將index.codec 配置到template模版中是比較方便的，修改已完成寫入操作的索引需要額外的管理操作，7.17版本涉及到手動重啟

API調用

查看狀態

GET /_cat/indices/my-index?v   #查看索引信息
GET /_cat/shards/my-index?v    #查看分片信息
GET /_cat/segments/my-index?v   #查看段信息
GET /_cat/indices/my-index-*?v&h=index,pri,rep,docs.count,store.size,pri.store.size,segments.count  #查看索引/段/分片信息

查看索引配置

#https://www.elastic.co/guide/en/elasticsearch/reference/7.17/indices-get-settings.htmlGET my-index-*/_settings?pretty&include_defaults&flat_settings=true..."index.codec" : "default",...

創建索引配置

PUT /my-index-000001
{"settings": {"index": {"number_of_shards": 2,  "number_of_replicas": 1,"codec": "best_compression",  "refresh_interval" : "2s"}}
}#刪除索引
DELETE  my-index-000001

更新索引配置

#https://www.elastic.co/guide/en/elasticsearch/reference/7.17/indices-update-settings.html#更新動態配置不需要關閉索引#更新靜態配置的前提條件 該索引必須是只讀的
POST /my-index-000001/_close?wait_for_active_shards=0PUT /my-index-000001/_settings
{"index.codec" : "best_compression"
}POST /my-index-000001/_open

強制合并索引

#https://www.elastic.co/guide/en/elasticsearch/reference/7.17/indices-forcemerge.htmlPOST /my-index-000001/_forcemerge?max_num_segments=1

為什么默認啟用 LZ4 壓縮，而不是best_compression

在許多情況下，人們會很樂意放棄壓縮所需的額外 CPU 來換取磁盤空間 Part 2.0: The true story behind Elasticsearch storage requirements

通過共享存儲的方式節省存儲的成本

金山云：基于 JuiceFS 的 Elasticsearch 溫冷熱數據管理實踐