所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
当前回答
在我曾经工作过的一家公司,我们在Oracle 8i(当时是9i)数据库中存储了1.55亿张图像。7.5 tb的价值。
其他回答
根据我的经验,我必须管理两种情况:图像存储在数据库和图像文件系统的路径存储在db。
第一个解决方案,数据库中的图像,有点“干净”,因为你的数据访问层将只需要处理数据库对象;但这只在你必须处理小数字的时候有用。
显然,当您处理二进制大对象时,数据库访问性能正在下降,数据库维度将增长很多,再次导致性能损失…通常数据库空间比文件系统空间要昂贵得多。
另一方面,在文件系统中存储大型二进制对象将导致您的备份计划必须同时考虑数据库和文件系统,这对于某些系统可能是一个问题。
使用文件系统的另一个原因是当你必须与第三方访问共享你的图像数据(或声音、视频等)时:在这一天,我正在开发一个web应用程序,它使用的图像必须从“外部”我的网络农场访问,以这样一种方式访问数据库来检索二进制数据是根本不可能的。所以有时候也会有设计上的考虑促使你做出选择。
在做出这种选择时,还要考虑在访问二进制对象时是否必须处理权限和身份验证:当数据存储在db中时,这些必要条件通常可以以更简单的方式解决。
如果你需要在文件系统中存储大量的图像,需要考虑以下几点:
备份和恢复。你如何保持图像同步。 文件系统的性能。这取决于您正在做的事情和文件系统,但您可能希望实现一个散列机制,这样您就不会有一个包含数十亿个文件的目录。 复制。您是否需要在多个服务器之间保持文件同步?
I'm not sure how much of a "real world" example this is, but I currently have an application out there that stores details for a trading card game, including the images for the cards. Granted the record count for the database is only 2851 records to date, but given the fact that certain cards have are released multiple times and have alternate artwork, it was actually more efficient sizewise to scan the "primary square" of the artwork and then dynamically generate the border and miscellaneous effects for the card when requested.
这个图像库的最初创建者创建了一个数据访问类,它根据请求呈现图像,并且对于查看和单独的卡片来说,它的速度非常快。
This also eases deployment/updates when new cards are released, instead of zipping up an entire folder of images and sending those down the pipe and ensuring the proper folder structure is created, I simply update the database and have the user download it again. This currently sizes up to 56MB, which isn't great, but I'm working on an incremental update feature for future releases. In addition, there is a "no images" version of the application that allows those over dial-up to get the application without the download delay.
到目前为止,这个解决方案工作得很好,因为应用程序本身被定位为桌面上的单个实例。有一个网站将所有这些数据存档,以供在线访问,但我绝不会使用相同的解决方案。我同意文件访问更可取,因为它可以更好地适应图像请求的频率和数量。
希望这不是太多的废话,但我看到了这个主题,并想从一个相对成功的中小型应用程序中提供一些我的见解。
DB中的文件路径绝对是可行的方法——我从拥有TB图像的客户那里听到了一个又一个故事,试图在DB中存储大量图像都是一场噩梦——单是性能损失就太大了。
其次是关于文件路径的建议。我曾经参与过几个需要管理大型资产集合的项目,任何直接在DB中存储东西的尝试都会导致长期的痛苦和沮丧。
我能想到的唯一真正的“好处”是,将它们存储在数据库中,可以方便地保存单个图像资产。如果没有可用的文件路径,并且所有图像都直接从DB中流出,那么用户就不会有发现他们不应该访问的文件的危险。
不过,这似乎可以用一个中间脚本从网络无法访问的文件存储中提取数据来更好地解决。因此,DB存储并不是真正必要的。