InfluxDB存储用户时序数据应使用不同tag还是独立bucket？

绝大多数海量用户场景下，选择给用户标识设置独立tag的方案即可，绝对不要为每个用户创建单独的bucket，两种方案的差异、适用场景和踩坑点如下：

• 为什么不推荐单用户独立bucket
  • bucket是InfluxDB中承载存储策略、权限规则、索引配置的逻辑资源单元，本身有固定的元数据开销。如果你的用户量级达到十万、百万甚至更高，海量bucket带来的元数据压力会直接拖垮集群：后台的存储生命周期巡检、分片校验任务会占用绝大多数CPU和内存资源，正常的写入查询都会被阻塞。
  • 跨用户的全局统计类查询基本不可用：要做全平台的指标总量统计、平均上报频率计算这类需求时，你需要遍历所有bucket拼接查询逻辑，查询延迟会高到根本无法接受。
  • 运维成本会随着用户量线性上涨：每个bucket的保留策略、分片时长、写入配额、权限配置都要单独维护，用户注销时还要同步清理对应bucket，批量操作时极易出现误删、配置错配的故障。
• 用tag区分用户的正确配置方式
  • 不用过度担心高基数问题：只要你不把用户ID和其他无上限的高基数字段（比如请求traceID、单次上报的事件ID）绑定生成冗余series，单字段存储用户ID的tag基数是完全可控的，InfluxDB 2.x之后搭载的TSI时间序列索引，完全可以支撑千万级用户量级的单tag基数查询，性能不会有明显衰减。
  • 根据你的查询模式匹配分片组时长：如果90%以上的查询都是单用户维度、时间范围在7天以内的查询，把分片组时长设为1天即可，查询时只会扫描命中的少量分片，单用户查询的性能和独立bucket方案没有感知差异。
  • 权限隔离完全可以靠标签权限实现：给用户颁发的访问token直接绑定tag过滤规则，限制该token只能读写user_id = 对应用户ID的数据，就能达到和独立bucket一致的权限隔离效果，没有额外资源开销。
• 仅在以下场景可以考虑独立bucket方案
  你的用户总量在几百量级以内（基本都是ToB付费大客户），且不同用户的数据存储规则存在强差异：比如部分客户要求数据留存3年、部分客户只需要留存7天，或者部分客户有明确的物理资源隔离、单独加密要求，这种场景下独立bucket的投入产出比才是合理的。

实操踩坑提醒：不要为了追求虚无的“隔离性”上来就拆bucket，我见过至少3个团队在用户量涨到几万的时候，因为bucket数量过多打满元数据存储导致整个实例卡死，最后花了一到两周时间全量倒数据改成tag区分方案，纯纯的无效踩坑。

内容的提问来源于stack exchange，提问作者Chris_Gr