所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
所以我用的是一个在数据库中大量存储图像的应用程序。你对此有什么看法?我更倾向于将位置存储在文件系统中,而不是直接存储在DB中。
你认为优点和缺点是什么?
当前回答
通常,我强烈反对采用基础设施中最昂贵和最难扩展的部分(数据库),并将所有负载都放在其中。另一方面:它极大地简化了备份策略,特别是当你有多个web服务器,需要以某种方式保持数据同步时。
像大多数其他事情一样,这取决于预期的规模和预算。
其他回答
通过网络将二进制数据从数据库中取出会导致巨大的延迟问题,并且伸缩性不好。
将路径存储在数据库中,让你的web服务器承担负载——这就是它的设计目的!
有一件事我还没有看到任何人提到,但绝对值得注意的是,在大多数文件系统中也存在与存储大量图像相关的问题。例如,如果您采用上面提到的方法,以主键命名每个图像文件,在大多数文件系统上,如果您试图将所有图像放在一个大目录中,一旦您达到了非常大的图像数量(例如数十万或数百万),您将遇到问题。
常见的解决方案是将它们散列到平衡的子目录树中。
我个人会将大数据存储在数据库之外。
优点:存储所有东西在一个请,容易访问数据文件,容易备份 缺点:降低数据库性能,很多页面分割,可能导致数据库损坏
我几乎从不把它们存储在数据库中。最好的方法通常是将映像存储在一个由中央配置变量控制的路径中,并根据DB表和主键(如果可能的话)命名映像。这给了你以下优势:
通过更新全局配置,将映像移动到另一个分区或服务器。 通过搜索图像的主键来查找与图像匹配的记录。 您的图像可以访问处理工具,如imagemagick。 在web应用程序中,您的图像可以由web服务器直接处理(节省处理)。 CMS工具和Coldfusion等网络语言可以处理本地上传。
我将使用文件系统方法,主要是因为它具有更好的灵活性。考虑一下,如果图像的数量变得很大,一个数据库可能无法处理它。对于文件系统,您可以简单地添加更多的文件服务器,假设您正在使用NFS或kind。
文件系统方法的另一个优点是能够做一些奇特的事情,例如可以使用Amazon S3作为主要存储(在数据库中保存url而不是文件路径)。如果S3发生中断,则退回到文件服务器(可能是包含该文件路径的另一个数据库条目)。一些巫术适用于Apache或任何你正在使用的web服务器。