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

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


当前回答

数据数据库

文件的文件系统

其他回答

其次是关于文件路径的建议。我曾经参与过几个需要管理大型资产集合的项目,任何直接在DB中存储东西的尝试都会导致长期的痛苦和沮丧。

我能想到的唯一真正的“好处”是,将它们存储在数据库中,可以方便地保存单个图像资产。如果没有可用的文件路径,并且所有图像都直接从DB中流出,那么用户就不会有发现他们不应该访问的文件的危险。

不过,这似乎可以用一个中间脚本从网络无法访问的文件存储中提取数据来更好地解决。因此,DB存储并不是真正必要的。

关于这个话题,这里有一份有趣的白皮书。

是否使用BLOB:数据库或文件系统中的大型对象存储

答案是“视情况而定。”当然,这取决于数据库服务器及其blob存储方法。它还取决于存储在blob中的数据类型,以及如何访问这些数据。

使用数据库作为存储机制,可以有效地存储和传递较小的文件。较大的文件可能最好使用文件系统存储,特别是如果它们将经常被修改/更新。(blob碎片在性能方面成为一个问题。)

Here's an additional point to keep in mind. One of the reasons supporting the use of a database to store the blobs is ACID compliance. However, the approach that the testers used in the white paper, (Bulk Logged option of SQL Server,) which doubled SQL Server throughput, effectively changed the 'D' in ACID to a 'd,' as the blob data was not logged with the initial writes for the transaction. Therefore, if full ACID compliance is an important requirement for your system, halve the SQL Server throughput figures for database writes when comparing file I/O to database blob I/O.

数据数据库

文件的文件系统

通过网络将二进制数据从数据库中取出会导致巨大的延迟问题,并且伸缩性不好。

将路径存储在数据库中,让你的web服务器承担负载——这就是它的设计目的!

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

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