基于Firestore的IoT温湿度数据分析存储优化方案咨询

针对你的场景，核心问题是单文档存储上限导致的扩展性不足，以下是几个基于Firestore原生能力的优化方案，完全不用切换Firebase：

1. 按时间维度拆分聚合文档 #

放弃将所有小时数据追加到单个文档的做法，改为每个时间单元（小时/天/周/月）对应一个独立文档：

• 小时级聚合：创建hourly_aggregations集合，每个文档ID用格式化时间字符串（比如2024-10-01-14），文档内容仅存储该小时的温湿度平均值：

  {
    "datetime": "2024-10-01T14:00:00Z",
    "avg_temp": 23.5,
    "avg_humidity": 62.1
  }
  

• 天/周/月级聚合：同理创建daily_aggregations、weekly_aggregations、monthly_aggregations集合，每个文档对应一个天/周/月的聚合结果。
• 优势：每个文档体积极小，完全不会触发5MB上限；前端查询时可直接按时间范围拉取对应维度的文档，加载效率极高。

2. 层级化聚合存储（适合多维度查询） #

如果需要更灵活的维度组合，可以用嵌套子集合的方式组织数据：

• 根集合aggregations下，按年份创建文档（比如2024），每个年文档下包含months子集合；
• months子集合中按月份创建文档（比如10），每个月文档下包含days子集合；
• days子集合中按日期创建文档（比如01），每个天文档下包含hours子集合，存储当天的小时级聚合数据。
• 优势：数据结构层级清晰，前端可以按需遍历不同层级获取对应时间范围的聚合数据，比如要查2024年10月的日平均，直接访问aggregations/2024/months/10/days集合即可。

3. 实时+定时结合的聚合生成 #

替代Python脚本每小时批量计算的方式，用Firebase生态工具实现更高效的聚合：

• 实时小时聚合：用Cloud Functions监听设备原始数据的写入事件，每当有新数据写入时，批量更新对应小时的聚合文档（累加总温湿度、计数，最后计算平均值）；
• 定时维度聚合：用Cloud Scheduler每天凌晨触发Cloud Function，基于前一天的小时级聚合数据计算日平均值，写入daily_aggregations集合；同理每周/每月触发计算周/月平均值。
• 优势：避免了Python脚本的外部依赖，聚合计算更实时，且完全基于Firebase原生服务实现。

4. 原始数据的归档策略（可选） #

如果不需要长期保留所有设备的原始数据，可以定期将超过一定期限的原始数据归档到Cloud Storage（Firebase集成的云存储），进一步减少Firestore中的数据量，同时降低查询聚合时的计算压力。

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