# 大规模健康时序数据的存储选型：Supabase vs ClickHouse vs InfluxDB 3

结论先行：原始高频健康数据（MQTT/蓝牙上报，写多读少、长期保留、需大跨度聚合）不宜长期堆在 Supabase(Postgres)。推荐采用“混合架构”：
- Supabase：承载关系/权限/最近快照/应用侧事件与实时订阅（聊天与通知等）。
- ClickHouse 或 InfluxDB 3：承载海量原始时序与聚合视图，负责低成本高吞吐写入与大跨度查询。

## 1) 何时用谁（快速决策）
- 优先 ClickHouse：需要通用 SQL、多维过滤、复杂聚合（TopN、百分位/直方图）、OLAP 报表与成本可控的长保留。
- 可选 InfluxDB 3：数据严格是“时序度量 + 标签”的简洁模型，关注 Retention/Downsampling，客户端/生态偏向时序栈（Telegraf 等）。
- Supabase：仅存最近快照、小体量派生指标、索引映射（用户/设备/权限/数据入口）。

## 2) 推荐架构（混合）
MQTT/BLE → 网关(鉴权/幂等) → Kafka(ts.health) →
- Sink → ClickHouse（或 InfluxDB 3）：写入明细表 + 物化/降采样视图
- 回写 → Supabase：最新快照、告警、索引
前端：
- 趋势/历史：查询 ClickHouse/Influx；
- 业务/权限/会话：查询 Supabase；
- 实时：Supabase Realtime；

## 3) ClickHouse 设计要点（示例）
- 明细表（MergeTree，月分区 + 主键顺序 + TTL）：
```
CREATE TABLE health_raw (
  user_id UUID,
  device_id UUID,
  metric LowCardinality(String),
  ts DateTime64(3, 'UTC'),
  value Float64,
  meta JSON,
  ingest_dt Date DEFAULT today()
) ENGINE = MergeTree
PARTITION BY toYYYYMM(ts)
PRIMARY KEY (user_id, metric, ts)
ORDER BY (user_id, metric, ts)
TTL ts + INTERVAL 365 DAY DELETE;
```
- 物化视图：分钟/小时聚合，用于长跨度查询；Kafka 引入可用 Kafka Engine 或外部 Sink（Telegraf/Vector/Fluent Bit/Connectors）。

## 4) InfluxDB 3 要点
- measurement+tags+fields+timestamp；Retention & Downsampling 用 bucket/任务；
- 接入：Telegraf mqtt_consumer → influxdb_v3 输出最省事；亦可 Kafka → Telegraf/自写消费者。

## 5) 与 Supabase 集成
- 保留关系/权限/会话/通知；
- 建 `user_metrics_last` 快照表（metric、last_value、last_ts、link），用于快速渲染与跳转到时序库查询；
- 后端 API 聚合：统一鉴权（基于 Supabase 用户），内部代查 ClickHouse/Influx 并合并结果。

## 6) 成本与运维
- ClickHouse 压缩/列存，长保留更省；InfluxDB 3 简化时序运维；Supabase 避免明细爆表降成本；
- 监控：写入延迟、失败率、分区大小、查询耗时、Kafka lag、告警阈值。

## 7) 落地步骤
1. 保持现有 Supabase 聊天/通知；
2. 按上面 schema 搭一套 ClickHouse（或 InfluxDB 3）与 1m/1h 物化/降采样；
3. 网关产出 Kafka ts.health 并接 Sink；
4. 前端曲线改走时序库（或由后端代理）；
5. 上线监控与告警、成本评估与冷热分层。

小结：原始大规模健康时序数据 → ClickHouse/InfluxDB 3；Supabase 负责“关系 + 实时 + 快照索引”，两者配合既稳又省。