保留、降采样与性能
时序系统的数据量近似由写入频率、Series 数量、每点大小和保留时间共同决定。保留策略和降采样不是后期清理工作，而是容量与查询模型的一部分。
容量关系
text
Point 数量 ≈ Series 数量 × 每 Series 每秒写入点数 × 保留秒数实际磁盘还受到压缩率、Tag/Field 长度、索引、WAL、Compaction、备份和副本数影响。
Retention
| 产品线 | 主要概念 |
|---|---|
| 1.x | Retention Policy 与 Database 组合 |
| 2.x | Bucket 同时包含数据与 Retention 配置 |
| 3.x | Database 与保留配置按具体产品能力管理，不沿用 2.x Bucket 语义 |
过期删除通常是后台、分区或文件级处理，不保证到期瞬间逐点消失。合规要求若需要精确删除时限，应验证任务周期、对象存储生命周期和备份保留。
降采样
原始秒级数据可以只保留短周期，把分钟、小时聚合结果保留更久：
降采样必须确定：
- 聚合函数是 Mean、Sum、Min/Max、Last 还是分位数。
- Counter 是否需要先计算增量或 Rate。
- 空窗口、设备离线和迟到数据如何处理。
- 重算时如何避免重复写入或覆盖错误窗口。
- Dashboard 查询何时切换不同粒度。
Cardinality
在 1.x/2.x 中，Series Cardinality 等于 Measurement 与 Tag Set 组合数量。高基数会扩大索引和规划成本。典型风险包括把 Request ID、随机 UUID、完整 URL 或时间戳写成 Tag。
InfluxDB 3 重新设计了存储和查询架构，传统 Series Cardinality 不再以完全相同方式形成瓶颈，但高基数维度仍会增加列值、分区、缓存和查询成本。应根据目标版本评估，而不是把“无限基数”理解成无成本。
性能检查
- 写入是否批量化，是否存在大量小 HTTP 请求。
- Tag/列是否能让查询快速缩小数据范围。
- 查询是否始终带时间边界，窗口是否过细。
- Compaction、对象存储读取或查询 Spill 是否形成 I/O 压力。
- Dashboard 是否同时触发大量高基数分组。
- 最近值查询是否使用对应缓存能力。