【问题标题】:storing uploaded photos and documents - filesystem vs database blob存储上传的照片和文档 - 文件系统与数据库 blob
【发布时间】:2009-07-09 17:39:58
【问题描述】:

我的具体情况

用户可以上传照片和租赁文件的物业管理网站。对于每个公寓单元,可能有 4 张照片,因此系统中的照片数量不会过多。

对于照片,每张都有缩略图。

我的问题

我的第一要务是性能。对于最终用户,我想尽可能快地加载页面并显示图像。

我应该将图像存储在数据库或文件系统中,还是无关紧要?我需要缓存任何东西吗?

提前致谢!

【问题讨论】:

  • 我正在寻找同样的问题。

标签: python postgresql storage photos photo-management


【解决方案1】:

虽然所有事情都有例外,但一般情况下,将图像存储在文件系统中是最好的选择。您可以轻松地为图像提供缓存服务,无需担心额外的代码来处理图像,如果需要,您可以通过标准的图像编辑方法轻松地对图像进行维护。

听起来您的商业模式很适合这种情况。

【讨论】:

  • 想补充一下,Daniel 所说的,数据库只是一个层,提问者想要在其上放置文件。
  • +1 同意 -- 在这种情况下是 FS 放手。如果/何时您将拥有大量文件,需要注意的一件事是健全的文件系统结构(例如,一个文件夹中没有十万个文件)。也就是说,将路径保存在数据库中,并将文件保存在磁盘上。
  • 数据库中的路径和磁盘上的文件是一种非常好的现代方法。我知道 SQL Server 2008 有一个文件流数据类型或类似的功能。
  • 谢谢 squid,我不想为每个“客户公司”创建一个文件夹,而不仅仅是一个文件夹的 1 个大转储
  • @Dillie-O:您能否澄清一下,是否有必要缓存文件,因为浏览器会自行缓存图像文件。
【解决方案2】:

文件系统。没有比赛。 当您将数据存储在数据库中时,数据必须经过更多层。

编辑缓存: 如果您想在用户上传文件时缓存文件以确保操作尽快完成,则将其直接转储到磁盘(即文件系统)几乎是尽可能快的。只要文件不是太大并且您没有太多并发用户,您可以将文件“缓存”在内存中,返回给用户,然后保存到磁盘。老实说,我不会打扰。

如果您在上传文件后在网络上提供文件并希望缓存以提高性能,文件系统仍然是最佳选择。您将从您的网络服务器免费获得缓存(可能需要调整一两个设置)。如果文件在数据库中,您将不会得到这个。

毕竟听起来您永远不应该将文件存储在数据库中。并非如此,您只需要一个充分的理由这样做。

【讨论】:

  • @Daniel。为了获得最佳缓存性能,我必须在 Web 服务器上调整什么“设置或两个”?
  • 能否请您澄清一下,是否有必要缓存文件,因为浏览器会自行缓存图像文件。
【解决方案3】:

绝对将您的图像存储在文件系统上。人们在考虑这些类型的事情时没有考虑到的一个问题是臃肿。将图像作为二进制 blob 填充到数据库中是一种快速膨胀数据库的方法。大型数据库带来更高的硬件要求、更困难的复制和备份要求等。将图像粘贴在文件系统上意味着您可以使用许多现有工具轻松简单地备份/复制它们。文件系统的存储空间也比数据库更容易增加。

【讨论】:

    【解决方案4】:

    评论小羊的回答。

    通常,当文件大小小于 256 KB 时,在 SQL 中存储文件更好,大于 1 兆字节时更值得。因此,在 256-1024 KB 之间,它取决于几个因素。阅读this,了解更多关于使用 SQL 或文件系统的原因。

    【讨论】:

      【解决方案5】:

      在某些操作上,数据库可能比文件系统快,但加载识别良好的数据块 100 KB 不是其中之一。

      另外,一个好的前端网络服务器(如 nginx)比您必须编写的从数据库读取 blob 的任何 webapp 层都要快得多。在一些测试中,对于中型文件(如大 HTML 或中型图像)的原始数据服务,nginx 与 memcached 大致相当。

      去FS。没有比赛。

      【讨论】:

      • 如果您想通过 Web 应用程序的完全访问控制和全 nginx 速度提供多兆字节的文件,请检查“X-Accel-Redirect”响应标头。
      【解决方案6】:

      也许有点切题,但在 MySQL 会议的 this 视频中,演讲者谈到了网站 smugmug 如何使用 MySQL 和各种其他技术来获得卓越的性能。我认为该视频建立在此处发布的一些答案的基础上,但也提出了在数据库范围之外提高网站性能的方法。

      【讨论】:

        猜你喜欢
        • 1970-01-01
        • 2011-02-13
        • 2012-04-19
        • 1970-01-01
        • 2011-10-19
        • 2023-03-09
        • 2019-06-27
        • 1970-01-01
        • 2012-05-05
        相关资源
        最近更新 更多