架构决策没有最优解只有适合当前阶段的方案。一、对象存储MinIO vs 公有云 OSS对比项MinIO自建公有云 OSS成本服务器硬盘按流量付费上传速度局域网 1Gbps家庭上行 10Mbps访问延迟1ms内网50-200ms公网维护成本自己搭、自己管零维护决策选 MinIO原因家庭集群所有设备在局域网内。上传 64MB 视频到 MinIO 只需 0.5 秒到公有云 OSS 要 30 秒10Mbps 上行限制。代价是外网访问要走内网穿透延迟较高。但对于以局域网用户为主的演示场景这个代价可以接受。二、数据库PostgreSQL vs MySQL对比项PostgreSQLMySQL数据类型丰富JSONB、数组基础类型扩展生态pgvector、PostGIS有限约束支持完整外键/检查/排他InnoDB 支持外键并发模型MVCC 快照隔离MVCC RR 级别决策选 PostgreSQL关键原因是用了pgvector做向量搜索这是 PG 独有的扩展sqlCREATE EXTENSION vector; CREATE TABLE video_embeddings ( video_id INTEGER, embedding vector(768) ); -- 向量相似度检索 SELECT * FROM video_embeddings ORDER BY embedding - [0.1, 0.2, ...] LIMIT 5;三、转码策略多清晰度 vs 单清晰度传统做法转三档480p、720p、1080p自适应切换。决策单档 720pCRF37ultrafast原因源文件码率已经极低85-596kbps是高度压缩的产物。转三档相当于“用不同分辨率展示同样的模糊”体积翻三倍但画质没有实际提升。方案体积存储画质三档标准码率3x3x无明显提升单档 CRF371x1x与源一致核心原则源文件糊了转码只是把糊的放大。用 CRF 匹配源码率而不是用固定码率强行转档。四、流协议HLS vs DASH对比项HLSDASH容器MPEG-TSfMP4原生支持SafariChrome/Firefox播放库hls.jsdash.js切片格式.ts.m4s决策选 HLShls.js 兼容性好所有浏览器都能播。dash.js 对非标准 fMP4 解析有问题而 m3u8ts 是更成熟稳定的方案。五、播放方式Range 代理 vs 完整下载方案带宽消耗实现复杂度完整下载每次全量低Range 流式按需传输中本地缓存 Range首次后为 0中高决策Range 代理 本地缓存首次播放通过 Range 请求从存储流式转发同时落盘缓存再次播放直接从本地缓存读取带宽消耗为 0。六、编码参数CRF vs CBR对比项CBR恒定码率CRF恒定质量码率固定自适应体积可控不可控画质复杂场景不足均匀适用场景直播推流VOD 点播决策CRF37源文件本身码率极低CBR 用标准码率转码只会膨胀体积。CRF37 自适应匹配源码率输出体积与源基本一致。七、上传事务性问题MinIO 有视频文件数据库记录不全——上传文件后没有正确写入 DB。解决方案python# 上传后发消息异步写 DB minio_client.put_object(bucket, key, file) message_queue.publish(video.uploaded, {key: key}) # 消费者保证写入 def on_video_uploaded(msg): try: db.execute(INSERT INTO videos (key, ...) VALUES (...)) except Exception: # 补偿清理残留 minio_client.remove_object(bucket, msg[key]) raise用补偿事务或消息队列确保存储和数据库最终一致。八、总结决策点选择理由对象存储MinIO内网传输快、零成本数据库PostgreSQL需要 pgvector 向量扩展转码档位单档 720p源已压糊多档无意义流协议HLShls.js 兼容性好播放方式Range 缓存省带宽、体验好编码参数CRF37匹配源码率不浪费空间核心原则架构选型没有标准答案只有适合当前阶段的方案。家庭集群 有限上行带宽本地存储 单档转码是合理的折中。等带宽和用户量上来了再切换到更标准的方案。
