所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
当前回答
假设:应用程序是基于web的
我很惊讶没有人真正提到这一点……委托给其他专家->使用第三方映像/文件托管提供商。
将文件存储在付费的在线服务上,比如
Amazon S3 Moso云存储
另一个StackOverflow线程在这里讨论这个。
这篇文章解释了为什么你应该使用第三方托管提供商。
太值得了。它们能有效地储存。没有带宽从你的服务器上传到客户端请求等等。
其他回答
在数据库中只存储映像的文件路径的问题是,不能再强制数据库的完整性。
如果文件路径所指向的实际映像变得不可用,则数据库会不知不觉地出现完整性错误。
考虑到图像是被寻找的实际数据,并且它们可以在一个集成的数据库中更容易地管理(图像不会突然消失),而不必与某种文件系统(如果文件系统是独立访问的,图像可能会突然“消失”),我倾向于将它们直接存储为BLOB或类似的文件系统。
我将采用文件系统方法。正如其他一些人所指出的,大多数web服务器被构建为从文件路径发送图像。如果您不需要从数据库中写入或输出BLOB字段,那么您将获得更高的性能。当内容不变或希望限制数据库负载时,将图像存储在文件系统中可以更容易地设置静态页面。
文件存储。Facebook的工程师们对此进行了热烈的讨论。一个收获是了解目录中文件的实际限制。
大海捞针:高效存储数十亿张照片
我曾经开发过一个图像处理应用程序。我们将上传的图像存储在类似于/images/[今天的日期]/[id号]的目录中。但是我们还从图像中提取了元数据(exif数据),并将其连同时间戳等一起存储在数据库中。
我们实现了一个文档成像系统,它将所有图像存储在SQL2005 blob字段中。目前有几百GB,我们看到了出色的响应时间和很少或没有性能下降。此外,fr法规遵从性,我们有一个中间件层,将新发布的文档归档到光学点唱机系统,该系统将它们公开为标准NTFS文件系统。
我们对结果非常满意,特别是在以下方面:
易于复制和备份 能够轻松实现文档版本控制系统