如何解决处理大量上载图像的最佳目录结构是什么?
| 我正在创建一个网站,要求每个用户都上传个人资料图片以及调整大小的版本。我将使用mysql存储图像的ID和其他信息。我从来不需要处理重新排列静态文件的问题,因此,仅假设该站点有成千上万的用户即可。我想知道存储图像的最佳目录结构是什么? 我以前看过几种提到的方式: 1)md5(image_id),如果哈希为49f68a5c8493ec2c0bf489821c21fc3b,则结构为/ 49 / f6 / 8a / 5c / 84/93 / ec / 2c / 0b / f4 / 89/82 / 1c / 21 / fc / 3b .jpg(或..... 3b / filename.jpg)。这种方法似乎可以处理很多事情,但看起来可能会创建几个目录。可能对此方法有变化吗? 2)/年/月/日/(可能是小时)/id.jpg 那么该怎么办?解决方法
像这样在唯一的哈希上钻取子目录是一个很好的解决方案,但是示例中子目录的数量太多了。每个两个字符的子目录可以支持256个条目,因此,如果要拥有5000个用户,则仅深入单个级别时,每个子目录将仅获得约20个文件,这是完全合理的。两个层次的深度将轻松处理数百万个用户。
另外,我不会将文件名剪切为哈希中其余的任何字符。无论文件有多深,都使用完整的哈希作为文件名。如果您需要(例如)将文件移动到新存储中,则文件将更易于管理。即,不要这样做:
49/f68a5c8493ec2c0bf489821c21fc3b.jpg
做这个:
49/49f68a5c8493ec2c0bf489821c21fc3b.jpg
,如果我存储的文件名只是一个id的图像,则倾向于使用以下结构;
/0/1.jpg
/500/501.jpg
/1000/1001.jpg
/1500/1501.jpg
这个想法是创建不超过500张图像的文件夹,并将基本文件夹编号作为起点。这不需要任何特殊的数据库字段或散列,并且您可以选择大于或小于500。
,图片/md5(user_id)/user_id/*.jpg的前两个字符
这样,您就不会在目录中包含成千上万个其他文件/目录,并避免嵌套太多树
例如
images/a9/1000/foo.jpg
images/a9/1000/bar.jpg
images/a9/107/baz.jpg
images/1f/24/goo.jpg
,我通常将密钥存储在图像记录旁边的数据库中,格式如下:
userid/md5(image_id)_time.ext
这很好,因为它使人们无需做大量工作就能“窃取”整个收藏集。另外,如果您更新原始图片并希望将“旧”图片存储一段时间(在某些情况下可能会有所帮助),则它有助于名称冲突。另外,您可以将其设置为永不过期,因为您将永远不会对其进行更新。您可能需要定期进入并刷新\'old \'文件,但这是另一个问题。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。