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

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


当前回答

没有人提到的是DB保证原子操作、事务完整性和处理并发性。对于文件系统,甚至引用完整性都不存在了——那么您如何知道您的文件名仍然是正确的呢?

如果你的文件系统中有你的图像,当你写一个新版本甚至删除文件时,有人正在读取文件-会发生什么?

我们使用blob是因为它们也更容易管理(备份、复制、传输)。他们为我们工作得很好。

其他回答

如果这是基于web的应用程序,那么将图像存储在第三方存储交付网络(如Amazon的S3或Nirvanix平台)上可能会有优势。

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

我们在表中存储图像的唯一原因是每个表(或每个工作范围的一组表)都是临时的,在工作流结束时被删除。如果有任何形式的长期存储,我们肯定会选择存储文件路径。

还应该注意的是,我们在内部使用客户端/服务器应用程序,因此不需要担心web界面。

这里的诀窍是不要成为一个狂热分子。

这里需要注意的一点是,在专业文件系统阵营中没有人列出特定的文件系统。这是否意味着从FAT16到ZFS可以轻松击败所有数据库?

No.

事实上,许多数据库都胜过许多文件系统,即使我们只讨论原始速度。

正确的做法是为您的精确场景做出正确的决定,要做到这一点,您需要一些数字和一些用例估计。

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

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