目录

集群版本： 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 温冷热数据管理实践