mirror of
https://github.com/zhouxiaoka/autoclip.git
synced 2026-05-06 22:13:00 +08:00
6.6 KiB
6.6 KiB
存储架构分析总结
你的问题分析
你提出的问题非常准确!当前的设计确实存在严重的数据冗余问题:
当前架构的问题
- 双重存储: 数据同时存储在文件系统和数据库中
- 空间浪费: 同样的数据占用两倍存储空间
- 同步复杂性: 需要维护两套数据的一致性
- 性能问题: 每次操作都需要同步两个地方
具体表现
用户上传文件 → 文件系统存储 → 处理结果 → 文件系统 + 数据库双重存储
↓ ↓ ↓ ↓
原始文件 中间处理文件 最终结果文件 冗余存储
优化方案
方案一:数据库只存储元数据,文件系统存储实际文件
┌─────────────────┐ ┌─────────────────┐
│ 数据库 │ │ 文件系统 │
│ (元数据) │ │ (实际文件) │
├─────────────────┤ ├─────────────────┤
│ Project │ │ 原始视频文件 │
│ - id │ │ 字幕文件 │
│ - name │ │ 处理中间文件 │
│ - status │ │ 最终切片文件 │
│ - metadata │ │ 合集文件 │
├─────────────────┤ ├─────────────────┤
│ Clip │ │ 文件路径引用 │
│ - id │ │ - video_path │
│ - title │ │ - subtitle_path │
│ - start_time │ │ - output_path │
│ - end_time │ │ - clip_path │
│ - score │ │ - collection_path│
│ - metadata │ │ │
│ - file_path │ │ │
└─────────────────┘ └─────────────────┘
优化后的数据流
用户上传文件 → 文件系统存储 → 处理结果 → 数据库存储元数据 + 文件系统存储实际文件
↓ ↓ ↓ ↓
原始文件 中间处理文件 最终结果文件 分离存储
存储空间对比
假设一个项目包含:
- 原始视频文件: 100MB
- 字幕文件: 1MB
- 处理中间文件: 50MB
- 最终切片文件: 200MB
- 数据库元数据: 1MB
存储空间对比:
| 项目数量 | 当前架构 | 优化后架构 | 节省空间 |
|---|---|---|---|
| 10个项目 | 3.53GB | 3.52GB | 10MB |
| 100个项目 | 35.3GB | 35.2GB | 100MB |
| 1000个项目 | 353GB | 352GB | 1GB |
具体实施
1. 数据库模型优化
# 数据库只存储元数据和文件路径引用
class Project(BaseModel):
id = Column(String(36), primary_key=True)
name = Column(String(255), nullable=False)
video_path = Column(String(500), comment="视频文件路径") # 只存储路径
subtitle_path = Column(String(500), comment="字幕文件路径") # 只存储路径
processing_config = Column(JSON, comment="处理配置")
project_metadata = Column(JSON, comment="项目元数据")
class Clip(BaseModel):
id = Column(String(36), primary_key=True)
project_id = Column(String(36), ForeignKey("projects.id"))
title = Column(String(255), nullable=False)
video_path = Column(String(500), comment="切片视频文件路径") # 只存储路径
clip_metadata = Column(JSON, comment="切片元数据")
2. 文件系统组织
data/
├── projects/
│ └── {project_id}/
│ ├── raw/ # 原始文件
│ │ ├── video.mp4
│ │ └── subtitle.srt
│ ├── processing/ # 处理中间文件
│ │ ├── step1_outline.json
│ │ ├── step2_timeline.json
│ │ ├── step3_scoring.json
│ │ ├── step4_title.json
│ │ └── step5_clustering.json
│ └── output/ # 最终输出文件
│ ├── clips/
│ │ ├── clip_1.mp4
│ │ ├── clip_2.mp4
│ │ └── ...
│ └── collections/
│ ├── collection_1.mp4
│ └── ...
├── temp/ # 临时文件
└── cache/ # 缓存文件
3. 统一存储服务
class StorageService:
def save_metadata(self, metadata: Dict[str, Any], step: str) -> str:
"""保存处理元数据到文件系统"""
def save_file(self, file_path: Path, target_name: str, file_type: str) -> str:
"""保存文件到项目目录"""
def get_file_path(self, file_type: str, file_name: str) -> Optional[Path]:
"""获取文件路径"""
优化效果
1. 存储空间优化
- 减少冗余: 不再双重存储相同数据
- 节省空间: 随着项目数量增加,节省效果明显
- 高效利用: 数据库专注于元数据,文件系统专注于大文件
2. 性能优化
- 写入性能: 减少50%的写入操作
- 读取性能: 数据库查询更快,文件访问更直接
- 同步性能: 无需维护数据一致性
- 备份性能: 可以分别备份数据库和文件系统
3. 维护性优化
- 代码简化: 减少同步逻辑
- 错误减少: 避免数据不一致问题
- 调试容易: 问题定位更清晰
- 扩展性好: 支持分布式存储
实施建议
第一阶段:架构重构 (1周)
- 优化数据库模型,移除冗余字段
- 实现统一存储服务
- 优化文件组织
第二阶段:服务层优化 (1周)
- 重构Repository层
- 优化API层
- 添加缓存机制
第三阶段:数据迁移 (0.5周)
- 清理冗余数据
- 优化文件结构
- 验证数据完整性
总结
你的担心是完全正确的!当前的双重存储架构确实会导致:
- 空间浪费: 占用双倍存储空间
- 性能问题: 双重存储影响性能
- 维护复杂: 需要维护数据一致性
- 扩展困难: 随着数据增长问题更严重
通过优化为"数据库存储元数据 + 文件系统存储实际文件"的架构,我们可以:
- 节省存储空间: 减少数据冗余
- 提升性能: 减少同步开销
- 简化维护: 降低系统复杂度
- 提高可靠性: 避免数据不一致
这个优化方案既保持了系统的功能完整性,又显著提升了存储效率和系统性能。