2. Loki 存储模型：Chunk 存储原理、Index 存储原理（单 TSDB 与多 TSDB 模式）、对象存储（S3/GCS/MinIO）作为后端

Loki 的存储模型是其高性能与低成本的核心基石。与 Prometheus 或 Cortex 不同，Loki 不进行全文索引，而是采用 “仅索引元数据 + 压缩存储日志块” 的设计哲学。本章深入剖析 Chunk（数据块）与 Index（索引）的存储原理，并详解对象存储作为后端的最佳实践。

2.1 Chunk 存储原理

Chunk 是 Loki 中存储日志数据的最小物理单元。当日志流（Log Stream）被采集后，Ingester 组件会将多条日志条目压缩并封装为一个 Chunk。

2.1.1 Chunk 的生命周期

1. 写入阶段：Ingester 接收日志流，按 stream hash + labels 分组，将日志追加到内存中的 Chunk 缓冲区。
2. 压缩与封装：当 Chunk 达到目标大小（默认 1.5 MB）或最大超时时间（默认 1 小时）时，Ingester 使用 gzip（默认）或 snappy / lz4 压缩日志数据。
3. 上传：压缩后的 Chunk 被上传至对象存储（S3/GCS/MinIO），同时将 Chunk 元数据（如时间范围、标签集、Checksum）写入 Index。
4. 只读与查询：上传后的 Chunk 变为只读，Querier 通过 Index 定位 Chunk 并直接从对象存储读取。

2.1.2 Chunk 内部结构

2.2 Index 存储原理：单 TSDB 与多 TSDB 模式

Index 负责存储日志流的元数据（标签、Chunk 引用、时间范围），是查询加速的关键。Loki 从 2.8 版本开始引入 TSDB (Time Series Database) 索引格式，逐步替代旧的 BoltDB 索引。

2.2.1 单 TSDB 模式（Single TSDB）

• 架构：每个 Ingester 或 Compactor 维护一个全局的 TSDB 索引文件。
• 存储方式：索引文件以 TSDB 块 形式写入对象存储，每个块包含完整的标签倒排索引与 Chunk 引用列表。
• 适用场景：中小规模集群（< 100 个 Ingester），日志流数量 < 50 万。
• 优点：部署简单，索引查询延迟低（单文件顺序读取）。
• 缺点：索引文件可能过大（> 10GB），导致 Compactor 合并压力大，查询时需加载整个索引。

2.2.2 多 TSDB 模式（Multi TSDB / Sharded TSDB）

• 架构：将全局索引按 时间范围 + 标签哈希 拆分为多个独立的 TSDB 分片（Shard）。
• 存储方式：每个分片是一个独立的 TSDB 块，Compactor 定期合并小分片为更大块。
• 适用场景：大规模集群（> 100 个 Ingester），日志流数量 > 100 万。
• 优点：索引分片可并行查询，降低单文件大小；Compactor 可独立合并每个分片，提升吞吐。
• 缺点：需要配置分片策略（如 tsdb_shipper.resync_interval），查询时需合并多个分片结果。

2.3 对象存储作为后端：S3 / GCS / MinIO

Loki 将 Chunk 和 Index 统一存储在对象存储中，实现计算与存储分离。对象存储的高可用、低成本、无限扩展特性使其成为理想后端。

2.3.1 支持的存储后端对比

2.3.2 对象存储配置示例（MinIO）

storage_config:
  aws:
    s3: http://minio:9000
    bucketnames: loki-data
    access_key_id: minioadmin
    secret_access_key: minioadmin
    s3forcepathstyle: true
  boltdb_shipper:
    active_index_directory: /data/loki/index
    cache_location: /data/loki/index-cache
    shared_store: s3

2.4 存储架构总览

下图展示了 Loki 存储模型中 Chunk、Index 与对象存储的交互关系：

2.5 存储优化最佳实践

• Chunk 大小调优：设置 chunk_target_size: 2097152（2MB）可减少对象存储 PUT 请求次数，降低存储成本。
• 索引分片策略：多 TSDB 模式下，tsdb_shipper.resync_interval: 5m 控制索引同步频率；compactor.working_directory 需有足够磁盘空间（建议 100GB+）。
• 对象存储生命周期：配置 S3 生命周期策略，将超过 30 天的 Chunk 自动转为 Glacier 或 Deep Archive，节省 80% 存储费用。
• 本地缓存：启用 chunk_store_config.chunk_cache_config 和 index_cache_config，使用 Redis 或 Memcached 缓存热数据，减少对象存储读取延迟。
• 压缩算法选择：gzip 压缩比最高（~5:1），但 CPU 开销大；snappy 压缩比略低（~3:1），但速度更快。日志量大时推荐 snappy。