在使用 **Elasticsearch 作为日志数据库（LogDB）** 时，**压缩率与压缩比**是影响存储成本、磁盘 I/O 和查询性能的重要因素-优快云博客

在使用 Elasticsearch 作为日志数据库（LogDB） 时，压缩率与压缩比是影响存储成本、磁盘 I/O 和查询性能的重要因素。Elasticsearch 使用底层 Lucene 存储机制，默认对数据进行压缩，但可以通过配置进一步优化。

✅ 一、Elasticsearch 中的压缩机制

Elasticsearch 基于 Lucene，其段文件（segment files）默认使用 LZ4 块压缩算法，速度快但压缩率一般。
你也可以启用更高压缩率的编码方式：

编码类型	压缩算法	特点
`lucene_default`	LZ4	默认，写入快，压缩率中等
`best_compression`	DEFLATE (zlib)	更高压缩率，节省空间，读写略慢
`zstd`（7.3+ 支持）	Zstandard	平衡压缩率与速度，推荐新版本使用

🔍 所有源数据字段（_source）均会被压缩存储。

✅ 二、如何设置高压缩比？

方法：在索引设置中指定 `codec` 参数

PUT /logs-compressed-001
{
  "settings": {
    "index.codec": "best_compression",
    "number_of_shards": 1,
    "number_of_replicas": 1
  }
}

⚠️ 注意：

best_compression 只影响新创建的段（segments），已有段不会立即重写。
必须在索引创建前设置，无法动态更改。
适用于冷/归档阶段索引更佳。

✅ 三、实际压缩效果对比（示例）

假设原始日志 _source 数据为 100GB：

编码方式	典型压缩比	占用空间	CPU 开销	适用场景
`lucene_default` (LZ4)	~2.5:1	~40 GB	低	热节点，高频写入
`best_compression` (DEFLATE)	~4:1 ~ 5:1	~20–25 GB	中高	温/冷阶段归档
`zstd`	~3.8:1	~26 GB	中	新项目推荐（7.3+）

📌 示例：从 100GB 原始日志 → 最高可压缩至 20GB 左右，节省 80% 存储空间！

✅ 四、结合 ILM 实现分阶段压缩优化

最佳实践是在数据进入“温”或“冷”阶段后，再应用高压缩策略。

步骤如下：

热阶段：快速写入，使用默认压缩

"hot": {
  "actions": {
    "rollover": { "max_size": "50GB" },
    "set_priority": { "priority": 100 }
  }
}

温阶段：关闭写入，合并段并切换压缩方式（需通过 reindex 或 force merge + codec）
❗注意：不能直接修改现有索引的 codec，必须重建。

✅ 解决方案：使用 Shrink + Reindex 到新索引并设置 best_compression

POST _reindex
{
  "source": { "index": "logs-warm-000001" },
  "dest": {
    "index": "logs-archived-000001",
    "op_type": "create",
    "routing": "none"
  },
  "script": {
    "source": "ctx._source.remove('unneeded_field')"
  }
}

目标索引提前定义：

PUT /logs-archived-000001
{
  "settings": {
    "index.codec": "best_compression",
    "number_of_shards": 1
  }
}

✅ 五、查看当前索引的压缩情况

1. 查看段信息及使用的压缩编解码器

GET /logs-write/_segments?pretty

输出中查找 "version" 和 "compression" 相关字段。

2. 检查存储占用

GET _cat/indices/logs-*?v&s=index&h=index,pri.store.size,store.size

对比不同策略下存储差异。

✅ 六、其他提升压缩比的方法

方法	说明
移除无用字段	使用 Ingest Pipeline 删除不需要的字段（如临时变量）
禁用非必要字段索引	设置 `"index": false` 对无需搜索的字段
使用 keyword 替代 text	避免分词产生大量 term
启用 `_source` 过滤	使用 `includes/excludes` 减少摄入内容
字段别名统一命名	减少字段名本身带来的元数据开销