将图像（jpg，gif，png）存储在文件系统或数据库中？

Question

  

可能重复：
  Which is more secure: filesystem or database?
  User images - database vs. filesystem storage
  store image in database or in a system file ?

我无法决定应该遵循哪一个。你们能提出一些意见吗？我应该将我的图像存储在文件系统还是数据库中？ （我想阻止别人偷我的照片）

当你回答这个问题时，请包括安全性，表演等的比较。

感谢。

---

完全重复： User Images: Database or filesystem storage?
完全重复： Storing images in database: Yea or nay?
完全重复： Should I store my images in the database or folders?
完全重复： Would you store binary data in database or folders?
完全重复： Store pictures as files or or the database for a web app?
完全重复： Storing a small number of images: blob or fs?
完全重复： store image in filesystem or database?

Answer 1

将图像移动到数据库中并编写代码来提取图像可能比它的价值更麻烦。它将全部回到围绕保护图像或性能要求的业务需求。

我建议坚持在数据库中存储文件路径或目录位置的经过验证的真实系统，并将文件保存在磁盘上。原因如下：

• 文件系统更易于维护。有些想法必须放在图像的结构和组织中。即每个客户的目录，每个[Attribute-X]的子目录和每个[Attribute-Y]的另一个子文件夹。在一个目录中保留太多图像将最终减慢文件访问速度（即数十万）
• 如果存储在数据库中的想法是对文件系统丢失的反制措施（即磁盘发生故障，或者意外删除目录），那么我会反对使用源代码控制时的建议，检索任何丢失/丢失/删除文件都没问题。
• 如果您需要扩展并转移到内容分发方案，则必须退回到文件系统或执行大量提取以推送到提供商。
• 它也有这样的说法：“将结构化数据保存在数据库中”。 Microsoft有一篇关于Managing Unstructured Data的文章。
• 如果安全性是一个需要解决的问题，那么文件系统就具有ACL的整体结构。重新考虑安全性可能超出了业务要求的范围。

此主题的大量讨论也可在以下网址找到：

• Question 3748
• Question 561447

将您的图像存储为varbinary或某种类型的blob（取决于您的平台），我建议它比它的价值更麻烦。您需要扩展的工作意味着您需要维护的更多代码，单元测试以及防范缺陷。

如果您的环境可以支持SQL Server 2008，那么您可以在SQL 2008中使用新的FileStream数据类型实现两全其美。

• MSDN文章宣称FileStream datatype in SQL 2008为高性能。
• SQL Skills has a great article with some SQL 2008 Filestream performance measurements。
• 以下是一篇文章varbinary vs. FileStream and performance of both datatypes。
• 如果您是SQL Mag订阅者，您可以看到很棒的article at SQL Mag on SQL 2008 FileStream。
• Microsoft Research article:To Blob or Not To Blob

我很乐意在Flickr或Facebook等大型用户群的真实场景中进行研究。

同样，这一切都可以追溯到您的业务需求。祝你好运！

Answer 2

在防止“盗窃”方面存储它们并不重要。如果您将字节流传送到浏览器，则任何人都可以拦截并保存它。没有办法阻止这种情况（我假设您正在谈论将图像传送到浏览器）。

如果您只是谈论在机器上保护图像，那也没关系。操作系统可以像数据库一样安全地锁定，防止任何人访问图像。

在性能方面（向浏览器呈现图像时），我个人认为从文件系统提供服务会更快。无论如何，您必须在单独的HTTP事务中呈现图像，这几乎肯定需要多次访问数据库。我怀疑（虽然我没有硬数据）将图像URL存储在数据库中指向文件系统上的静态图像会更快 - 然后获取图像的行为是由Web服务器打开的简单文件而不是运行代码来访问数据库。

Answer 3

你可能不得不得到一大堆“但文件系统 数据库”的答案。这不是其中之一。

filesystem选项取决于很多因素，例如，服务器是否已对目录执行写入操作？ （是的，我见过apache无法写入DocumentRoot的服务器。）

如果您希望跨平台实现100％的交叉兼容性，那么数据库选项是最佳选择。它还允许您存储与图像相关的元数据，例如用户ID，上传日期，甚至同一图像的备用版本（例如缓存缩略图）。

另一方面，您需要编写自定义代码以从DB读取图像并将其提供给用户，而任何标准Web服务器都只允许您按原样发送图像。

但是，当谈到底线时，您应该选择适合您项目的选项和服务器配置。

Answer 4

将它们存储在FileSystem中，将文件路径存储在DB中。

当然，你可以使这个可扩展和分布，你只需要保持图像dirs在它们之间同步（对于JackM）。或者使用连接到多个Web前端服务器的共享存储。

无论如何，你的另一个问题涵盖了窃取部分，基本上是不可能的。能够访问图像的人总是可以（或多或少的工作）在本地保存它们......即使它意味着“打印屏幕”并粘贴到photoshop并保存。

Answer 5

这取决于您希望处理的图像数量，以及您需要处理的图像。我有一个应用程序需要每天临时存储100K到数百万个图像。我将它们以2gb连续块写入文件系统，将图像标识符，文件名，起始位置和长度存储在数据库中。

对于检索我只是将索引保存在内存中，文件打开只读并来回寻找它们。我找不到更快的方法来做到这一点。它比查找和加载单个文件快得多。一旦将许多单个文件转储到文件系统中，Windows就会变得非常慢。

我认为它可能有助于提高安全性，因为如果没有索引数据，图像将难以检索。

为了实现可扩展性，将Web服务放在其前面并将其分发到多台计算机上不会花费很长时间。

Answer 6

如果您希望应用程序可扩展，请不要在实际的Web服务器上使用文件系统。您可以将文件的位置存储在持久性数据存储区中，例如数据库或NoSQL解决方案。

对于AWS解决方案，您应该：

• 将图像存储在S3
上
• 将S3密钥保存到数据库
• 通过cloudfront（亚马逊CDN）为S3提供服务​​

Answer 7

对于我关注的Web应用程序，我们将图像存储在数据库中，但要确保它们在文件系统中得到了很好的缓存。

来自其中一个Web服务器前端的图像请求需要快速memcache 检查数据库中的图像是否已更改，如果没有，则从文件系统中进行更改。如果它已更改，则从中央数据库中获取它并将副本放入文件系统中。

这提供了将它们存储在文件系统中的大部分优点，同时保留了一些 数据库的优点 - 我们只有一个位置可以生成所有数据 备份更容易，意味着我们可以毫不费力地扩展到相当多的机器。它 也不会对数据库施加过多的负担。

Answer 8

将文件保存到数据库将提供一些安全性，以便另一个用户需要访问数据库以检索文件，但是，就效率而言，每个图像加载的SQL查询，留下所有负载到服务器端。帮自己一个忙，找到一种方法来保护文件系统中的图像，它们很多。

Answer 9

数据库最大的开箱即用优势是可以从网络上的任何位置访问它，如果您有多个服务器，这是必不可少的。

如果要从其他计算机访问文件系统，则需要设置某种共享方案，这可能会增加复杂性并可能出现同步问题。

如果您确实将图像存储在数据库中，您仍然可以使用本地（非共享）磁盘作为缓存来减轻数据库的压力。您只需要在数据库中查询时间戳或其他内容，以查看文件是否仍然是最新的（如果您允许可以更改的文件）。

Answer 10

如果问题是可扩展性，那么通过将内容移入数据库会带来巨大的损失。您可以通过DNS循环访问Web服务器，但是为每个映像添加CGI进程和数据库查找的开销是疯狂的。它还使您的数据库更难维护，并且您的图像更难以处理。

至于问题的其他部分，您可以像数据库记录一样轻松地保护对文件的访问，但是在一天结束时，只要有一个返回文件的URL，您就有了有限的选项来防止正在使用的URL（至少不强制使用cookie和/或javascript）。

Answer 11

将文件存储在文件服务器中，并将原始数据存储在数据库中。虽然文件服务器（特别是基于HTTP）可以很好地扩展，但数据库服务器却没有。不要将它们混合在一起。

Answer 12

如果您需要编辑，管理或维护图像，则应将其存储在数据库之外。

此外，文件系统具有许多数据库不具备的安全功能。

数据库适用于将指针（文件路径）存储到实际数据中。