【问题标题】:What is the most scaleable and efficient way of managing profile pics管理个人资料图片的最可扩展和最有效的方式是什么
【发布时间】:2012-07-17 20:35:57
【问题描述】:

我知道这个问题以前被问过很多次,但我还没有找到适合我具体情况的答案。

使用 PHP 和 MySQL...

我即将将用户个人资料图片添加到应用程序中,并且我看到它有几个选项。其中两个如下:

1. 不引用数据库中的图像并存储图像 像这样:-

  • /assets/avatars/32px/userid.jpg

  • /assets/avatars/90px/userid.jpg

  • /assets/avatars/256px/userid.jpg

这意味着不需要额外的数据库查找,因为我已经有了相关的用户 ID。

1. 将相对路径存储在 users_meta 表中,并在检索用户数据时使用连接检索 url。

每种方法的优缺点是什么?如果您认为这两种方法都不是最好的方法,您认为哪种方法是存储/引用和检索用户个人资料图片的最有效和可扩展的方法。

非常感谢

编辑:添加更多细节:

我对选项 1 的担忧是我不确定文件系统如何处理单个目录中的 100 万多个文件。它会慢到爬行吗?如果是这样,我该如何解决这个问题?有没有可以消除这个潜在问题的结构?也许使用用户加入的时间作为 url 的一部分并按月存储图像。

例如/assets/avatars/10_2012/small/userid.jpg

10_2012 表示所有在 2012 年 10 月注册的用户。

或者在每个目录中只存储 1000 张图像并像这样访问:

  • /assets/avatars/0/small/userid.jpg
  • /assets/avatars/1000/small/userid.jpg
  • /assets/avatars/2000/small/userid.jpg

每当应用达到 1000 * n 个注册用户时添加一个新目录。

这会带来优势吗?

【问题讨论】:

  • 为什么其他问题对你不起作用?
  • 如果您不关心向公众公开图像路径,那么我会选择 NR.1 选项。如果您选择使用数据库选项。
  • 我总是偏执于让外部查看者可以根据他们可以获得的信息请求任意个人资料图片。我会为图像名称分配一个随机数,或者使用密钥对其名称进行散列。
  • 要么我误读了它们,要么它们倾向于处理将图像作为 BLOB 直接存储在数据库中或使用存储在数据库中的相对 url 引用之间的差异。此外,这需要支持大量用户,这肯定超过了您的平均用例。

标签: php mysql


【解决方案1】:

您可以选择选项 1,但使用部分 id 来创建路径。例如,如果您有六位 id,则可以将前两位数字作为路径的一部分:Id 123456.xyz 将变为 /1/2/123456.xyz。等等... 在此示例中,使用数字 ID,它将限制每个目录包含 1000 个文件。

【讨论】:

    【解决方案2】:

    正如您正确指出的那样 - 如果使用文件系统来满足您的需求,您不必进行 额外 数据库查找。这可以节省您的时间和资源。

    我可以看到为此使用数据库的唯一好处是“单点”备份。但我怀疑它是否是一个非常有效的“专业人士”,或者它是否甚至超过了由数据库查找引起的额外间接级别引入的额外复杂性

    编辑(匹配问题中的编辑):文件系统的工作方式很大程度上取决于操作系统。您的目标平台是什么?

    【讨论】:

    • 感谢 YePhick,正如我所说,我的直觉导致了这个结论,但是我想知道如果每个文件夹中有 100 万多个文件,我会开始看到什么样的性能下降。然后磁盘查找会开始爬行吗?如果是这样,我可以使用文件结构/方法来防止这种情况发生吗? (也许通过进一步拆分文件,也许按月存储它们并使用用户加入的日期作为参考来生成 url?
    • 我会说如果你最终在一个文件夹中有 100 万多个文件,那么你的设计需要改变 ;-)
    • 再次感谢...回答您的编辑,Linux... 再考虑一下,我想我上面描述的分离结构最好?你同意吗?
    • 对不起,我真的不同意。您期望拥有 100 个目录,每个目录包含 1K 文件,而单个目录包含 100K 文件,有什么优势?然而,我仍然不解地想像,为什么你会看到来自一个用户的如此大量的照片?也许如果你解释一下你想要实现的目标,向你推荐一些东西会更容易
    • 我永远不会期望每个用户有这么多文件。但是我需要支持 100 万以上的用户。使用我最初的选项 1,我将在一个文件夹中拥有 100 万多个文件,每个大小的每个用户 1 个。当然,通过拥有 1000 个目录,每个目录包含 1000 个文件,我会看到性能有所提高,因为我认为索引单个文件夹中的大量文件会比分离方法慢,导致(我假设每次查找都会显着变慢)跨度>
    【解决方案3】:

    我在我的应用程序中倾向于保存原始图像。

    查找时,生成缩略图(或任何大小的图像)并将其放入缓存目录中,或者如果图像已存在于缓存目录中,则将其返回给用户。

    如果上传图片的人删除或更新了原始图片,您也会将其从缓存中删除。

    这样做非常有用,因为您不需要知道最初保存时图像将使用的每个维度。

    【讨论】:

    • 图片可以在客户端调整大小,使用<img width="xx" height="xx" />。为什么每个人都需要事先知道图片所需的尺寸?
    • 调整图像大小的方法不止一种,例如,如果您要保存缩略图,您可能只需要图​​像的中间部分而不是缩小整个图像。这也有助于降低传输成本,因为当用户只需要一个 32x32 图标时,您不会发送潜在的 5mb 图像。
    • @arxanas 这样用户就不必下载大图来显示小图了吗?
    猜你喜欢
    • 1970-01-01
    • 2013-09-06
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多