超大规模商品图片存储与管理的最佳实践方案咨询

针对10万+商品、2000万+图片的场景，先直接分析两个备选方案的优劣，再给出更适配的落地方案：

方案1：按商品层级创建文件夹 #

优势 #

• 路径规则直观，无需查询数据库即可通过商品ID定位到对应图片集合
• 本地文件系统直接访问单文件时延迟较低

致命劣势 #

• 文件系统性能瓶颈：10万商品对应10万个product_x主文件夹，直接放在products目录下会导致该目录条目过多，主流文件系统（如ext4、XFS）在目录条目超1万后，遍历、查找性能会大幅下降
• 操作效率极低：编辑商品（如批量删变体、替换图片）时需递归操作多层文件夹，IO开销大且易出错；迁移或备份时，海量小文件的复制/同步速度远低于大文件

方案2：媒体数据表存储图片路径 #

优势 #

• 部署灵活，可存储图片多元元数据（如关联变体ID、图片类型、尺寸、上传时间），支持复杂查询（如筛选某类变体的所有缩略图）
• 无需维护复杂文件夹结构，新增/删除图片仅需操作数据库记录

性能担忧的解决办法 #

2000万条记录在主流关系型数据库（MySQL、PostgreSQL）中完全可控，做好以下优化即可：

• 建立复合索引：针对product_id+variant_id+image_type创建联合索引，确保关联查询速度
• 引入缓存层：用Redis缓存热门商品的图片路径列表（如Top20万热门商品），减少数据库查询次数
• 分表优化：若数据量持续增长，可按product_id分表，进一步降低单表数据量

更优落地方案：媒体数据表 + 对象存储服务 #

结合两种方案优势，规避本地文件系统局限性，推荐采用以下架构：

1. 媒体数据表：存储图片完整元数据（商品ID、变体ID、图片类型、对象存储键、哈希值、尺寸等），通过索引优化保证查询效率
2. 对象存储（OSS/S3/COS）：替代本地文件系统存储图片，这类服务天生适配海量小文件存储，具备高可用、自动扩容、CDN加速能力，还支持按前缀批量删除（如删除某商品所有图片，只需指定前缀products/{product_id}/）
3. 规则化对象键：采用products/{product_id}/{variant_id}/{image_type}_{file_hash}.jpg命名规则，既保证路径可预测，又通过文件哈希避免重名、实现内容去重
4. 批量操作优化：删除/迁移商品图片时，直接调用对象存储批量API，效率远高于本地文件夹操作；编辑商品时仅需修改数据库元数据，无需手动调整文件路径

内容的提问来源于stack exchange，提问作者Ozal Zarbaliyev