Storing Images in DB - Yea or Nay?

database image theory storage blob

563943 观看

30回复

2775 作者的声誉

So I'm using an app that stores images heavily in the DB. What's your outlook on this? I'm more of a type to store the location in the filesystem, than store it directly in the DB.

What do you think are the pros/cons?

作者: James Hall 的来源 发布者: 2008 年 8 月 6 日

回应 (30)


350

179999 作者的声誉

I'm in charge of some applications that manage many TB of images. We've found that storing file paths in the database to be best.

There are a couple of issues:

  • database storage is usually more expensive than file system storage
  • you can super-accelerate file system access with standard off the shelf products
    • for example, many web servers use the operating system's sendfile() system call to asynchronously send a file directly from the file system to the network interface. Images stored in a database don't benefit from this optimization.
  • things like web servers, etc, need no special coding or processing to access images in the file system
  • databases win out where transactional integrity between the image and metadata are important.
    • it is more complex to manage integrity between db metadata and file system data
    • it is difficult (within the context of a web application) to guarantee data has been flushed to disk on the filesystem
作者: Mark Harrison 发布者: 06.08.2008 05:40

14

120330 作者的声誉

通常情况下,我坚决反对花费最贵和最难扩展部分基础设施(数据库)并将所有负载放入其中。另一方面:它极大地简化了备份策略,特别是当您有多个Web服务器并且需要以某种方式保持数据同步时。

像大多数其他东西一样,它取决于预期的大小和预算。

作者: Michael Stum 发布者: 06.08.2008 05:42

3

0 作者的声誉

其次是文件路径的建议。我曾经做过几个需要管理大型资产收集的项目,而任何直接在数据库中存储东西的尝试都会导致长期的痛苦和挫折。

关于将它们存储在数据库中,我能想到的唯一真正的“专业”是单个图像资产的易用性。如果没有要使用的文件路径,并且所有图像都直接从数据库流式传输,则用户无法找到他们无法访问的文件。

这似乎可以通过中间脚本从Web不可访问的文件存储中提取数据来更好地解决。因此,数据库存储不是必需的。

作者: Jeff 发布者: 06.08.2008 05:51

11

8530 作者的声誉

如果这是基于Web的应用程序,那么将图像存储在第三方存储传送网络(例如Amazon S3或Nirvanix平台)上可能会有优势。

作者: David 发布者: 06.08.2008 05:52

35

38022 作者的声誉

根据我的经验,有时最简单的解决方案是根据主键命名图像。因此,很容易找到属于特定记录的图像,反之亦然。但与此同时,您不会在数据库中存储有关图像的任何内容。

作者: Patrick McElhaney 发布者: 06.08.2008 05:59

39

15707 作者的声誉

数据库中的文件路径绝对可行的方法 - 我听说过来自有TB图像的客户的故事,它变成了一个噩梦,试图在数据库中存储任何大量的图像 - 单独的性能影响太大了。

作者: Greg Hurlman 发布者: 06.08.2008 06:07

17

12179 作者的声誉

在我以前工作的公司,我们在Oracle 8i(当时的9i)数据库中存储了1.55亿个图像。7.5TB值得。

作者: graham.reeds 发布者: 06.08.2008 06:37

27

21408 作者的声誉

不经常编辑的小静态图像(不超过几个megs)应存储在数据库中。这种方法有几个好处,包括更容易移植(图像与数据库一起传输),更容易备份/恢复(图像备份数据库)和更好的可扩展性(一个包含数千个小缩略图文件的文件系统文件夹听起来像一个可扩展性的噩梦我)。

从数据库提供图像很容易,只需实现一个http处理程序,它将从DB服务器返回的字节数组作为二进制流提供。

作者: urini 发布者: 06.08.2008 06:46

56

36751 作者的声誉

这可能有点长,但如果您正在使用(或计划使用)SQL Server 2008,我建议您查看新的FileStream数据类型。

FileStream解决了将文件存储在数据库中的大部分问题:

  1. Blob实际上存储为文件夹中的文件。
  2. 该斑点可使用被访问或者数据库连接在文件系统中。
  3. 备份是集成的。
  4. 迁移“正常”。

但是,SQL的“透明数据加密”不会加密FileStream对象,所以如果这是一个考虑因素,最好只将它们存储为varbinary。

来自MSDN文章:

Transact-SQL语句可以插入,更新,查询,搜索和备份FILESTREAM数据。Win32文件系统接口提供对数据的流式访问。
FILESTREAM使用NT系统缓存来缓存文件数据。这有助于减少FILESTREAM数据可能对数据库引擎性能产生的任何影响。不使用SQL Server缓冲池; 因此,此内存可用于查询处理。

作者: Ray 发布者: 06.08.2008 08:15

3

5417 作者的声誉

街上的一句话是,除非你是一个数据库供应商,试图证明你的数据库可以做到这一点(比如,让我们说微软吹嘘Terraserver在SQL Server中存储了一些bajillion图像),这不是一个好主意。当替代方案 - 在文件服务器上存储图像和数据库中的路径更加容易时,为什么要这么麻烦?Blob领域有点像SUV的越野能力 - 大多数人不使用它们,那些通常遇到麻烦的人,然后有些人这样做,但只是为了它的乐趣。

作者: deadprogrammer 发布者: 06.08.2008 09:19

25

9334 作者的声誉

我还没有看到有人提到的一件事,但绝对值得注意的是,在大多数文件系统中存储大量图像也存在问题。例如,如果您采用上述方法并在主键之后命名每个图像文件,则在大多数文件系统上,如果在达到大量图像后尝试将所有图像放在一个大目录中,则会遇到问题(例如,数十万或数百万)。

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

作者: John 发布者: 20.08.2008 06:25

99

6638 作者的声誉

文件存储。Facebook工程师对它进行了很好的讨论。一个要点是了解目录中文件的实际限制。

大海捞针:高效存储数十亿张照片

作者: jason saldo 发布者: 20.08.2008 06:35

7

24118 作者的声誉

我不确定这是一个“现实世界”的例子,但我目前有一个应用程序存储交易卡游戏的详细信息,包括卡片的图像。虽然迄今为止数据库的记录数仅为2851条记录,但考虑到某些卡已多次发布并具有替代图形,实际上扫描图形的“主要方块”然后动态更有效。在请求时为卡片生成边框和杂项效果。

此图像库的原始创建者创建了一个数据访问类,该类根据请求呈现图像,并且它可以非常快速地查看和单个卡。

这也可以在发布新卡时简化部署/更新,而不是压缩整个图像文件夹并将其发送到管道并确保创建正确的文件夹结构,我只需更新数据库并让用户再次下载它。目前这个大小高达56MB,这不是很好,但我正在为未来的版本开发增量更新功能。此外,还有一个“无图像”版本的应用程序,允许那些通过拨号获得应用程序而没有下载延迟。

此解决方案迄今为止运行良好,因为应用程序本身作为桌面上的单个实例。有一个网站可以存档所有这些数据以供在线访问,但我绝不会使用相同的解决方案。我同意文件访问会更好,因为它可以更好地扩展到为图像提出的请求的频率和数量。

希望这不是太多喋喋不休,但我看到了这个主题,并希望从相对成功的中小规模应用程序中提供一些我的见解。

作者: Dillie-O 发布者: 20.08.2008 06:42

4

72325 作者的声誉

我曾经在一个图像处理应用程序。我们将上传的图像存储在类似/ images / [今天的日期] / [id号]的目录中。但我们还从图像中提取元数据(exif数据)并将其存储在数据库中,以及时间戳等。

作者: Thomas Owens 发布者: 20.08.2008 06:51

140

7910 作者的声誉

As with most issues, it's not as simple as it sounds. There are cases where it would make sense to store the images in the database.

  • 您正在存储动态变化的图像,比如发票,而您想获得2007年1月1日的发票?
  • 政府希望你保持6年的历史
  • 存储在数据库中的图像不需要不同的备份策略。存储在文件系统上的图像可以
  • 如果图像位于数据库中,则更容易控制对图像的访问。空闲管理员可以访问磁盘上的任何文件夹。需要一个真正确定的管理员才能在数据库中窥探以提取图像

另一方面,存在相关问题

  • 需要额外的代码来提取和流式传输图像
  • 延迟可能比直接文件访问慢
  • 数据库服务器上的负载较重
作者: Rad 发布者: 22.08.2008 04:33

7

12855 作者的声誉

SQL Server 2008提供了两全其美的解决方案:文件流数据类型

像常规表一样管理它并具有文件系统的性能。

作者: Andrei Rînea 发布者: 28.08.2008 09:37

28

2122 作者的声誉

正如其他人所说,SQL 2008附带了一个Filestream类型,允许您将文件名或标识符存储为数据库中的指针,并自动将图像存储在文件系统中,这是一个很好的场景。

如果您使用的是较旧的数据库,那么我会说如果您将其存储为blob数据,那么您实际上不会以搜索功能的方式从数据库中获取任何内容,因此它可能是最好的在文件系统上存储地址,并以这种方式存储图像。

这样您还可以节省文件系统的空间,因为您只需要节省确切的空间量,甚至可以节省文件系统上的压缩空间。

此外,您可以决定使用某些结构或元素进行保存,这些结构或元素允许您浏览文件系统中的原始图像而无需任何数据库命中,或者将文件批量传输到另一个系统,硬盘驱动器,S3或其他方案 - 更新位置你的程序,但保持结构,再次尝试增加存储时尝试将图像从数据库中删除。

也许,它还允许你根据常用的图像网址将一些缓存元素添加到你的web引擎/程序中,这样你就可以将自己保存在那里。

作者: crucible 发布者: 30.08.2008 09:50

31

22194 作者的声誉

这里的诀窍是不要成为狂热者。

这里需要注意的一点是,pro文件系统阵营中没有人列出特定的文件系统。这是否意味着从FAT16到ZFS的所有内容都能轻松击败每个数据库?

没有。

事实上,许多数据库都击败了许多文件系统,即使我们只讨论原始速度。

正确的做法是为您的确切方案做出正确的决定,为此,您需要一些数字和一些用例估算。

作者: dicroce 发布者: 31.08.2008 05:54

6

3530 作者的声誉

我的经验我必须管理这两种情况:存储在数据库中的图像和文件系统上的图像,路径存储在db中。

第一个解决方案,即数据库中的图像,有点“干净”,因为您的数据访问层必须只处理数据库对象; 但只有当你必须处理低数字时,这才是好的。

显然,处理二进制大对象时的数据库访问性能会降低,并且数据库维度会增长很多,导致性能再次降低......通常数据库空间比文件系统空间昂贵得多。

另一方面,在文件系统中存储大型二进制对象将导致您具有必须同时考虑数据库和文件系统的备份计划,这对于某些系统来说可能是个问题。

进入文件系统的另一个原因是,当您必须与第三方访问共享您的图像数据(或声音,视频等)时:在这几天我正在开发一个使用必须从“外部”访问的图像的Web应用程序“我的网络农场以这样一种方式,数据库访问来检索二进制数据根本不可能。因此,有时也会有一些设计考虑因素可以帮助您做出选择。

在进行此选择时,还要考虑在访问二进制对象时是否必须处理权限和身份验证:当数据存储在db中时,这些必需品通常可以更容易地解决。

作者: ila 发布者: 02.09.2008 07:20

10

6535 作者的声誉

如果您不在SQL Server 2008上并且有一些可靠的理由将特定的图像文件放入数据库中,那么您可以采用“两种”方法并将文件系统用作临时缓存并将数据库用作主存储库。

例如,您的业务逻辑可以在提供之前检查光盘上是否存在图像文件,并在必要时从数据库中检索。这可以为您提供多个Web服务器的功能和更少的同步问题。

作者: a7drew 发布者: 02.09.2008 02:01

7

56 作者的声誉

这取决于您要存储的图像数量以及它们的大小。我过去曾使用数据库来存储图像,而且我的经验相当不错。

IMO,使用数据库存储图像的优点是,

A.您不需要FS结构来保存图像
B.当要存储更多项目时,数据库索引的性能优于FS树
C.智能调整的数据库在缓存查询结果方面表现良好
D.备份很简单。如果您具有复制设置并且内容从靠近用户的服务器传送,它也可以很好地工作。在这种情况下,不需要显式同步。

如果您的映像将很小(比如<64k)并且数据库的存储引擎支持内联(记录中)BLOB,则它会进一步提高性能,因为不需要间接(实现了引用的位置)。

当您处理少量大尺寸图像时,存储图像可能是个坏主意。在db中存储图像的另一个问题是,创建,修改日期等元数据必须由应用程序处理。

作者: nikhilbelsare 发布者: 05.09.2008 10:54

26

71 作者的声誉

这是一篇关于这个主题的有趣的白皮书。

BLOB或不BLOB:数据库或文件系统中的大对象存储

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

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

这是另外一点需要牢记的。支持使用数据库存储blob的原因之一是ACID合规性。但是,测试人员在白皮书中使用的方法(SQL Server的批量记录选项)使SQL Server吞吐量加倍,有效地将ACID中的“D”更改为“d”,因为未记录blob数据该事务的初始写入。因此,如果完全ACID合规性是系统的重要要求,则在将文件I / O与数据库blob I / O进行比较时,将数据库写入的SQL Server吞吐量数量减半。

作者: user13550 发布者: 16.09.2008 08:28

13

934 作者的声誉

我们已经实现了一个文档成像系统,它将所有图像存储在SQL2005 blob字段中。目前有几百GB,我们看到了出色的响应时间,很少或没有性能下降。此外,在法规遵从性方面,我们有一个中间件层,可将新发布的文档存档到光学点唱机系统,该系统将它们作为标准NTFS文件系统公开。

我们对结果非常满意,特别是在以下方面:

  1. 易于复制和备份
  2. 能够轻松实现文档版本控制系统
作者: dan90266 发布者: 26.10.2008 05:55

22

27015 作者的声誉

没有人提到的是DB保证原子操作,事务完整性和处理并发。即使引用完整性也不在文件系统的窗口 - 所以你怎么知道你的文件名真的是正确的?

如果您在文件系统中有图像,并且有人在您编写新版本或甚至删除文件时正在读取文件 - 会发生什么?

我们使用blob因为它们更容易管理(备份,复制,传输)。它们对我们很有用。

作者: Draemon 发布者: 28.11.2008 06:33

7

59276 作者的声誉

我最近创建了一个PHP / MySQL应用程序,它将PDF / Word文件存储在MySQL表中(到目前为止每个文件大到40MB)。

优点:

  • 上传的文件与其他所有内容一起复制到备份服务器,不需要单独的备份策略(安心)。
  • 设置Web服务器稍微简单一点,因为我不需要上传/文件夹,并告诉我所有的应用程序它在哪里。
  • 我开始使用事务进行编辑以提高数据完整性 - 我不必担心孤立和丢失文件

缺点:

  • mysqldump现在占用了很长的时间,因为其中一个表中有500MB的文件数据。
  • 总的来说,与文件系统相比,内存/ CPU效率并不高

我称我的实现成功,它负责备份要求并简化项目的布局。对于使用该应用程序的20-30人来说,性能很好。

作者: too much php 发布者: 08.12.2008 04:31

30

5895 作者的声誉

在必须保证参照完整性和ACID合规性的地方,需要在数据库中存储图像。

您不能事务性地保证图像和存储在数据库中的图像的元数据引用相同的文件。换句话说,不可能保证文件系统上的文件只在与元数据同时和相同的事务中被改变。

作者: mluebke 发布者: 19.02.2009 09:28

20

94 作者的声誉

仅将文件路径存储到数据库中的映像的问题是不再强制数据库的完整性。

如果文件路径指向的实际图像变得不可用,则数据库无意中会出现完整性错误。

鉴于图像是正在寻找的实际数据,并且它们可以在一个集成数据库中更容易管理(图像不会突然消失),而不必与某种文件系统接口(如果文件系统是独立访问的,图像MIGHT突然“消失”),我会直接将它们存储为BLOB等。

作者: wiseguy 发布者: 08.04.2009 04:35

3

191778 作者的声誉

在数据库中存储图像仍然意味着图像数据最终会在文件系统中的某个位置结束,但会被遮挡,因此您无法直接访问它。

+ VES:

  • 数据库完整性
  • 它易于管理,因为您不必担心在添加或删除图像时保持文件系统同步

-ves:

  • 性能损失 - 数据库查找通常比文件系统查找慢
  • 你无法直接编辑图像(裁剪,调整大小)

这两种方法都很常见并且很常见 看看优缺点。无论哪种方式,你都必须考虑如何克服这些缺点。存储在数据库中通常意味着调整数据库参数并实现某种缓存。使用文件系统需要您找到一些方法来保持文件系统+数据库同步。

作者: Salman A 发布者: 18.05.2009 06:36

11

46239 作者的声誉

假设:应用程序是基于Web的/基于Web的

我很惊讶没有人真正提到这一点......将其委托给其他专家 - > 使用第三方图像/文件托管服务提供商

将您的文件存储在付费在线服务上

另一个StackOverflow线程在这里谈论这个。

此主题解释了为什么您应该使用第三方托管服务提供商。

这太值得了。他们有效地存储它。没有带宽从您的服务器上传到客户端请求等。

作者: Pure.Krome 发布者: 18.05.2009 01:18

4

20234 作者的声誉

在之前的项目中,我将图像存储在文件系统上,这导致了许多令人头疼的事情,包括备份,复制和文件系统与数据库不同步。

在我的最新项目中,我将图像存储在数据库中,并将它们缓存在文件系统上,并且它的工作原理非常好。到目前为止我没有遇到任何问题。

作者: Christoffer Hammarström 发布者: 16.12.2009 02:29
32x32