数据库与文件系统中的图像

我们有一个项目即将到来,我们将build立一个完整的后端CMS系统,将为我们的整个外联网和内联网提供一个包。 我一直在试图find答案的问题是哪个更好:将图像存储在数据库(SQL Server 2005)中,以便我们可以具有完整性,单个复制计划等,或存储在文件系统上?

我们遇到的一个问题是,我们有多个服务器负载均衡,需要始终具有相同的数据。 到目前为止,我们有SQL复制照顾,但文件复制似乎有点困难。 另一个问题是,我们希望同一图像有多个分辨率,我们不确定在文件系统上创build和存储每个版本是最好的,或者可以根据请求dynamic地提取和创build分辨率图像。

我们关心的是以下几点:

  • 数据的完整性
  • 数据复制
  • 多个决议
  • 数据库与文件系统的速度
  • 数据库与文件系统的开销负载
  • 数据pipe理和备份

有没有人有类似的情况或有什么build议? 先谢谢您的帮助!

11 Solutions collect form web for “数据库与文件系统中的图像”

微软研究院发表了一篇很好的研究论文,名为To Blob或不是Blob ,他们研究各种variables和影响。

他们的发现最终:

  • 最大可达256 KB,blob存储在数据库中比在文件系统中更有效
  • 对于1 MB或更大,文件系统更高效
  • 在它之间是一个抛硬块

自从这篇文章发表以来,SQL Server 2008还添加了FILESTREAM属性,它使得在文件系统中存储东西,但是在事务控制下,这是一个现实。 强烈build议你检查一下!

这个问题经常出现 – 看到这个search结果。

没有一个正确的答案 – 这取决于具体情况。

就个人而言 – 保留数据库中的文件path和文件系统上的文件。 每个人都有自己的优势。 您可以备份文件以及数据库。 这也是这个pipe理结核数据的家伙的结论。

静态文件的复制,特别是跨多个服务器,可能难以pipe理。 这实际上归结为pipe理,监视和debugging复制问题与数据库大小和负载之间的权衡。

我想我可能会select数据库方法,如果加载成为一个问题,请在图像调用周围放置一些caching层。

在数据库中存储path的build议缺less真正的问题,即在多台机器上复制这个问题。

那么,如果你的前两个需求是完整性和复制,那么答案肯定是DB。

你还有其他的观点:

  • 完整性 – 数据库,这就是为什么数据库存在与平面文件系统。

  • 复制 – 不知道你的意思是图像复制,但如果是这样,那么显然是DB,因为你不会负载平衡这,当然。

  • 可以从数据库图像执行多个分辨率,但这会增加处理成本。 此外,分辨率越高,尺寸越大,networking等待时间越长。 多个决议交换空间的速度。

  • 速度 – 取决于对图像的访问,可能可以忽略不计。 如果你在一个文件共享中进行镜像,无论如何你都必须在networking上等待,networking几乎一直是瓶颈。

  • 开销 – 坦率地说,这取决于您对开销的定义以及您如何访问图像。

  • pipe理,数据库,手下来。 单一存储=less一点担心,无论如何,您应始终在数据库上运行备份。 通过多个服务器进行文件系统备份在许多方面是昂贵的。

你的担心分解成两个阵营。 以下内容涉及将文档存储在数据库中:

  • 数据的完整性
  • 数据复制
  • 多个决议
  • 数据pipe理和备份

这些担心(可能)赞成将文件存储在文件系统上:

  • 数据库与文件系统的速度
  • 数据库与文件系统的开销负载

所以,决定什么是最重要的,并据此select。

辩论的任何一方都有有效的担忧,所以请始终给出您的要求。 多less数据,多less图片,多大?

内联/ BLOB存储

上游 :简化体系结构和实施,简化系统的备份和恢复或迁移; 只要做一个转储,备份,导出(无论你的数据库的味道),并将其移动到新的数据库。 版本控制/一致性由DB处理,因此允许时间点恢复。 安全/访问控制也更加清晰,因为对图像BLOB的访问是访问整个行的固有内容。 将图像移动到数据库之外并让HTTP服务器获取它,同时更好地实现并发性和可伸缩性,可能会在确保人们无法破解URL和请求不属于自己的图像时遇到问题。 如果您将它们放在数据库之外,请确保您的安全策略涵盖用户之间的图像访问控制。 您的HTTP服务器身份validation必须与整个系统的身份validation集成,或者您提供映像的HTTP服务器程序使用某种会话机制来确保HTTP请求有效。 这是多租户数据库中非常重要的一个问题。 在单一用途的单租户系统中,只需简单的身份validation就不需要担心了。

缺点 :对于真正意义上的大型数据库,备份和恢复会令人沮丧,甚至是成本高昂的问题,因为在那里你可能有一个小的核心数据集,否则你可能会有很多GB或TB的图像数据。 从完整性的angular度看,将所有数据视为一个一致的数据库是有好处的,但除非您使用具有企业级质量的数据库,数据仓库调整备份和恢复(例如Oracle RMAN和滚动备份),否则备份将会很糟糕。

始终考虑在任何系统中恢复的时间。 如果您的存储需求<几GB,甚至50-100GB,并且您有足够的备份空间计划,联机存储更清洁。 在此之上,分离关注点并让文件系统完成工作成为一个关键优势。 没有什么比尝试恢复,恢复和打开一个巨大的数据库,为了一个小数据错误。 恢复时间将是我最关心的问题。

通常,就CMS而言,在数据库中保存图像数据可能不如文件系统高效。 有一次,您可能只是想静态显示图像,在其他时候,您希望图像devise人员可以使用该图像进行更新等。

考虑每次您想要使用图像时检索图像的处理开销。

有几点你为什么要考虑FileSystem

  1. 浏览器可以完成所有的工作,并且可以从代理caching图像等方面受益
  2. 作为上述的一个分支,您可以轻松使用内容分发networking(CDN)
  3. 使用rsync等工具很容易复制图像数据
  4. 处理(即CPU)时间大幅度优化

假设你在一个Windows环境中,没有很好的理由来使用文件系统。 您可能需要小心如何将图像存储在表格中以避免不必要的页面拆分,但这是性能调整,不是一个大问题。

缺乏文件系统

不会自动复制

– 通过为每个实例设置不同的物理位置,可能会使复制复杂化

– 非常大量的文件

文件系统的上游

– 如果你正在存储一些非常大的文件,它会performance得更好一些。

我会;

1)为每个图像分配唯一标识符(GUID)2)使用该GUID标记/命名图像3)在操作系统(文件系统)中存储GUID 4)在数据库中存储完全限定文件名(FQN)指针。

在存储和维护方面将图像存储在数据库中是太昂贵的。 只存储FQN指针将提供更好的解决scheme。 您还可以通过触发器和某些存储过程来构build后端完整性检查。

我不会将图像存储在数据库中的一个原因(我的答案来自sql服务器):

我不希望SQL Server数据caching由网站的简单图像填充。 我希望数据caching实际上有数据。 另外,如果你有一个多层架构,它比一个二进制数据块更容易传递一个图像的URL。 如果你只是想要某些人看到图像(安全),你会遇到问题。

感谢所有的快速input,我们现在只有大约5-10GB的图像,其中很多是因为我们有相同图像的多个分辨率。

另外一个问题是,如果我们想要扩展以保存文档,演示文稿和无限制的video呢? 数据库方法是否支持让我们将video存储在数据库中,并将这些video保存在Flash中?

再次感谢所有的input!

  • 在还原SQL Server 2005数据库之后将用户链接到login
  • 我如何获取多个列在游标循环中使用?
  • SQL Server 2008比SQL Server 2005的优势?
  • 启用S​​QL Server代理需要很长时间
  • 从几列中select最小值的最佳方法是什么?
  • 是否有可能在SQL Server中强制行级locking?
  • 什么是最好的检查项目是否存在:select计数(ID)或存在(...)?
  • 按名称查找存储过程
  • 将现有的MS SQL表的列设置为NOT NULL
  • 如何使用sql server management studio将blob插入到数据库中
  • INSERT语句与FOREIGN KEY约束冲突