Initial commit of akmon project

doc_chat/kafka_mqtt_clickhouse.md

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