在使用Loki + Grafana来做日志收集、展示时，往往会对每个项目的日志设置一组标签，例如:
A 模块：{job="A", level="info"}
B 模块：{job="B", level="info"}
C 模块：{job="C", level="info"}
假设其中C模块的日志量很大，例如是使用Netty开发的物联网通讯模块且设备数量较多时，这个项目模块每天会产生大量的日志，而相较于C的A和B则拥有较小的日志量。
由于存储空间的成本问题，现在我们需要进行细粒度的日志保留时长的设计，C保留7天的日志，A和B保留30天的日志。
此时，如果仍然使用基于Table Manager的日志保留--删除策略，则无法做到做到该需求，这里选择采用基于Compactor的日志保留策略。
以下是基于官方的示例说明：
compactor:
working_directory: /data/retention
shared_store: gcs
compaction_interval: 10m
retention_enabled: true
retention_delete_delay: 2h
retention_delete_worker_count: 150
schema_config:
configs:
- from: "2020-07-31"
index:
period: 24h
prefix: loki_index_
object_store: gcs
schema: v11
store: boltdb-shipper
limits_config:
retention_period: 744h
retention_stream:
- selector: '{job="C"}'
priority: 1
period: 168h
retention_enabled: true是必须写的，如果不写，Compactor 只会压缩表，不会启动保留策略。
retention_delete_delay: 2h是 Compactor 删除 marked chunks 的延迟时间，这里是出于相关引用的考虑。
retention_delete_worker_count: 150是 Compactor 删除chunk时，用到的线程数量
period: 24h这个值只能是24h，只有在为24h时，数据过期策略才会工作
retention_period是对全局生效的，retention_stream是对指定的Stream生效，
如果Stream匹配不到具体的selector，则会使用全局的过期时间
在使用如上提供的方式完成配置后，需要对loki进行重启，之后等待10~20分钟后过期的数据将无法被查询到
