目录
集群版本: 7.17.6
解释几个概念:
段(Segment)
合并(Merge)
索引设置:
压缩方式(index.codec):
测试设置前提条件
对比 在创建的时候指定压缩类型(index.codec)
对比 在写入完成后的索引更改压缩类型
线上索引更改压缩方式前后对比
测试总结
API调用
查看状态
查看索引配置
创建索引配置
更新索引配置
强制合并索引
为什么默认启用 LZ4 压缩,而不是best_compression
通过共享存储的方式节省存储的成本
集群版本: 7.17.6
解释几个概念:
段(Segment)
可以理解为 是ES 索引存储数据的最小单位,索引 --> 分片--> 段,Elasticsearch 中的分片是 Lucene 索引,而 Lucene 索引又被分解为多个段。段是索引中的内部存储元素,用于存储索引数据,
合并(Merge)
主要指段合并,段是不可变的。较小的段会定期合并到较大的段中,以控制索引大小并清除删除的内容。段合并的触发一般会:
- 在索引的数据调整(写入/删除)操作
- 在后台定期触发,为了减少开销,不需要用户干预,比如说ILM 、refresh_interval
- 用户触发调整:强制合并(常用)、减少索引分片 和 分割索引分片
强制合并的几点建议:
不要并行过多请值合并,Merge是一项资源密集型操作。
不要合并出超过5G的段,影响性能
不要在hot节点上执行,影响写入速度,在cold节点 或者只读索引
索引设置:
配置分为为静态(static)和 动态(dynamic)
- static:只能在索引创建时 或 在关闭的索引上设置。
- dynamic:可以使用API 实时进行更改 。
7.17 版本中:关闭的索引更改其静态或者动态配置时可能会导致索引错误,只能不删除并重新创建索引。
8.17 版本中:索引reopen 设置true
(默认为false
)可以修改静态配置。
index.number_of_shards 此设置只能在创建索引时设置。无法在已关闭的索引上更改。8.17 版本 也是一样
压缩方式(index.codec):
Thedefault
value compresses stored data with LZ4 compression, but this can be set tobest_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.html
GET 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=0
PUT /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.html
POST /my-index-000001/_forcemerge?max_num_segments=1
为什么默认启用 LZ4
压缩,而不是best_compression
在许多情况下,人们会很乐意放弃压缩所需的额外 CPU 来换取磁盘空间 Part 2.0: The true story behind Elasticsearch storage requirements
通过共享存储的方式节省存储的成本
金山云:基于 JuiceFS 的 Elasticsearch 温冷热数据管理实践