60 lines
3.1 KiB
Markdown
60 lines
3.1 KiB
Markdown
# 大规模健康时序数据的存储选型：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 负责“关系 + 实时 + 快照索引”，两者配合既稳又省。 |