所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。

你认为优点和缺点是什么?


当前回答

根据我的经验,有时最简单的解决方案是根据主键来命名图像。因此,很容易找到属于特定记录的图像,反之亦然。但与此同时,你并没有在数据库中存储图像的任何信息。

其他回答

我是一个企业文档管理系统的首席开发人员,一些客户在这个系统中存储了数百gb的文档。在不久的将来会达到tb级。我们使用文件系统方法是出于本页提到的许多原因,另外还有一个原因:存档。

我们的许多客户必须遵守行业特定的存档规则,例如存储到光盘或非专有格式的存储。此外,您还可以灵活地向NAS设备添加更多磁盘。如果你把文件存储在你的数据库中,即使使用SQL Server 2008的文件流数据类型,你的存档选项也会变得非常狭窄。

我最近创建了一个PHP/MySQL应用程序,用于在MySQL表中存储pdf /Word文件(到目前为止每个文件的大小为40MB)。

优点:

上传的文件复制到备份服务器连同其他一切,不需要单独的备份策略(安心)。 设置web服务器稍微简单一些,因为我不需要有一个上传/文件夹,并告诉我所有的应用程序它在哪里。 我可以使用事务进行编辑以提高数据的完整性——我不必担心孤立的和丢失的文件

缺点:

mysqldump现在需要很长时间,因为其中一个表中有500MB的文件数据。 总的来说,与文件系统相比,内存/cpu效率不是很高

我认为我的实现是成功的,它满足了备份需求并简化了项目布局。对于使用该应用程序的20-30人来说,性能还不错。

有一件事我还没有看到任何人提到,但绝对值得注意的是,在大多数文件系统中也存在与存储大量图像相关的问题。例如,如果您采用上面提到的方法,以主键命名每个图像文件,在大多数文件系统上,如果您试图将所有图像放在一个大目录中,一旦您达到了非常大的图像数量(例如数十万或数百万),您将遇到问题。

常见的解决方案是将它们散列到平衡的子目录树中。

对于大量的小图像,数据库可能更好。

我有一个带有许多小缩略图的应用程序(每个缩略图2Kb)。当我将它们放到文件系统中时,由于文件系统的块大小,它们每个都消耗了8kb。空间增加了400% !

有关块大小的更多信息,请参阅这篇文章: iphone文件系统的块大小是多少?

我将使用文件系统方法,主要是因为它具有更好的灵活性。考虑一下,如果图像的数量变得很大,一个数据库可能无法处理它。对于文件系统,您可以简单地添加更多的文件服务器,假设您正在使用NFS或kind。

文件系统方法的另一个优点是能够做一些奇特的事情,例如可以使用Amazon S3作为主要存储(在数据库中保存url而不是文件路径)。如果S3发生中断,则退回到文件服务器(可能是包含该文件路径的另一个数据库条目)。一些巫术适用于Apache或任何你正在使用的web服务器。