存储图像在DB -是或否?

我负责一些管理许多TB图像的应用程序。我们发现在数据库中存储文件路径是最好的。

这里有几个问题:

• 数据库存储通常比文件系统存储更昂贵
• 您可以使用标准的现成产品超级加速文件系统访问
  • 例如，许多web服务器使用操作系统的sendfile ()系统调用直接从文件系统异步发送文件到网络接口。存储在数据库中的图像不会从这种优化中受益。
  李< / ul > < / >
  • 像web服务器等，不需要特殊的编码或处理来访问文件系统中的图像
  在映像和元数据之间的事务完整性很重要的地方，
  • 数据库胜出。
    • 管理db元数据和文件系统数据之间的完整性更加复杂
    • (在web应用程序的上下文中)很难保证数据已经被刷新到文件系统的磁盘上
    李< / ul > < / >

你的网络服务器(我假设你正在使用)是用来处理图像的，而数据库不是。因此，我会大力投反对票。

在数据库中只存储路径(可能还有文件信息)。

我个人会将大数据存储在数据库之外。

通常，我强烈反对采用基础设施中最昂贵和最难扩展的部分(数据库)，并将所有负载都放在其中。另一方面:它极大地简化了备份策略，特别是当你有多个web服务器，需要以某种方式保持数据同步时。

像大多数其他事情一样，这取决于预期的规模和预算。

其次是关于文件路径的建议。我曾经参与过几个需要管理大型资产集合的项目，任何直接在DB中存储东西的尝试都会导致长期的痛苦和沮丧。

我能想到的唯一真正的“好处”是，将它们存储在数据库中，可以方便地保存单个图像资产。如果没有可用的文件路径，并且所有图像都直接从DB中流出，那么用户就不会有发现他们不应该访问的文件的危险。

不过，这似乎可以用一个中间脚本从网络无法访问的文件存储中提取数据来更好地解决。因此，DB存储并不是真正必要的。

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

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

DB中的文件路径是肯定的方法-我从拥有TB图像的客户那里听到了一个又一个故事，试图在DB中存储任何大量的图像都成为了一场噩梦-单是性能损失就太多了。

在我曾经工作过的一家公司，我们在Oracle 8i(当时是9i)数据库中存储了1.55亿张图像。7.5 tb的价值。

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

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

这可能有点冒险，但如果你正在使用(或计划使用)SQL Server 2008，我建议你看看新的文件流数据类型。

FileStream解决了在DB中存储文件的大部分问题:

1. blob实际上以文件的形式存储在文件夹中。
2. 可以通过文件系统上的数据库连接或使用要么访问blob。
3. 备份是集成的。
4. 迁移“就是管用”。

然而，SQL的“透明数据加密”不加密FileStream对象，因此如果考虑到这一点，最好将它们存储为varbinary。

摘自MSDN文章:

Transact-SQL语句可以插入、更新、查询、搜索和备份FILESTREAM数据。Win32文件系统接口提供对数据的流访问 FILESTREAM使用NT系统缓存来缓存文件数据。这有助于减少FILESTREAM数据对数据库引擎性能的影响。SQL Server缓冲池未被使用;

坊间传言说，除非你是一个数据库供应商，试图证明你的数据库可以做到这一点(比如，微软吹嘘Terraserver在SQL Server中存储了大量的图像)，否则这不是一个很好的主意。当另一种选择——将图像存储在文件服务器和数据库中的路径上要容易得多时，为什么要麻烦呢?Blob fields有点像越野车的越野功能——大多数人不使用它们，那些使用它们的人通常会惹麻烦，然后还有一些人会使用，但只是为了好玩。

我将采用文件系统方法。正如其他一些人所指出的，大多数web服务器被构建为从文件路径发送图像。如果您不需要从数据库中写入或输出BLOB字段，那么您将获得更高的性能。当内容不变或希望限制数据库负载时，将图像存储在文件系统中可以更容易地设置静态页面。

尝试使用SQL模拟文件系统通常是一个糟糕的计划。如果您坚持使用文件系统作为外部存储，那么最终编写的代码会更少，结果也会更好。

有一件事我还没有看到任何人提到，但绝对值得注意的是，在大多数文件系统中也存在与存储大量图像相关的问题。例如，如果您采用上面提到的方法，以主键命名每个图像文件，在大多数文件系统上，如果您试图将所有图像放在一个大目录中，一旦您达到了非常大的图像数量(例如数十万或数百万)，您将遇到问题。

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

文件存储。Facebook的工程师们对此进行了热烈的讨论。一个收获是了解目录中文件的实际限制。

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

我不确定这在多大程度上是一个“现实世界”的例子，但我目前有一个存储交换卡牌游戏细节的应用程序，包括卡牌的图像。假设数据库的记录计数到目前为止只有2851条记录，但考虑到某些卡片已经多次发布，并且有备用的艺术品，实际上更有效的尺寸是扫描艺术品的“主正方形”，然后在请求时为卡片动态生成边界和杂项效果。

这个图像库的最初创建者创建了一个数据访问类，它根据请求呈现图像，并且对于查看和单独的卡片来说，它的速度非常快。

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

到目前为止，这个解决方案工作得很好，因为应用程序本身被定位为桌面上的单个实例。有一个网站将所有这些数据存档，以供在线访问，但我绝不会使用相同的解决方案。我同意文件访问更可取，因为它可以更好地适应图像请求的频率和数量。

希望这不是太多的废话，但我看到了这个主题，并想从一个相对成功的中小型应用程序中提供一些我的见解。

我们在表中存储图像的只有原因是因为每个表(或每个工作范围的一组表)都是临时的，在工作流结束时被删除。如果有任何形式的长期存储，我们肯定会选择存储文件路径。

还应该注意的是，我们在内部使用客户端/服务器应用程序，因此不需要担心web界面。

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

如果你需要在文件系统中存储大量的图像，需要考虑以下几点:

• 备份和恢复。你如何保持图像同步。
• 文件系统的性能。这取决于您正在做的事情和文件系统，但您可能希望实现一个散列机制，这样您就不会有一个包含数十亿个文件的目录。
• 复制。您是否需要在多个服务器之间保持文件同步?

通过网络将二进制数据从数据库中取出会导致巨大的延迟问题，并且伸缩性不好。

将路径存储在数据库中，让你的web服务器承担负载——这就是它的设计目的!

和大多数问题一样，这并不像听起来那么简单。在某些情况下，将图像存储在数据库中是有意义的。

• 您正在存储的图像 动态变化，比如发票和你想要的 因为它是在1月1日 2007年?李< / >
• 政府希望你保持6年的历史
• 存储在数据库中的映像不需要不同的备份策略。存储在文件系统上的映像可以
• 如果图像在数据库中，则更容易控制对图像的访问。空闲管理员可以访问磁盘上的任何文件夹。这需要一个非常坚定的管理员去窥探数据库提取图像

另一方面也有相关的问题

需要额外的代码来提取 并流图像
• 可能存在延迟 比直接文件访问慢
• 数据库服务器负载过重

不，因为页面分割。实际上，您定义的行可以是1KB - n MB，因此数据库的页面中会有大量空白，这对性能不利。

当然是文件系统。然后你可以使用所有的操作系统功能来处理这些图像-备份，web服务器，甚至只是使用imagemic之类的工具进行批量修改。如果您将它们存储在DB中，那么您需要编写自己的代码来解决这些问题。

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

像管理普通表一样管理它，并具有文件系统的性能。

您需要记住的一件事是数据集的大小。我相信Dillie-O是唯一一个稍微说到点子上的人。

如果你有一个小的，单用户的消费应用程序，那么我会说DB。我有一个DVD管理应用程序，使用文件系统(在程序文件中)，它是一个PIA备份。我希望他们每次都能把它们存储在数据库中，让我选择保存文件的位置。

对于一个更大的商业应用，我会开始改变我的想法。我曾经在一家开发县书记员信息管理应用程序的公司工作。我们将图像存储在磁盘上，以一种编码格式(以处理大量文件的FS问题)，基于县指定的仪器编号。这在另一个方面是有用的，因为图像可以在DB记录之前存在(由于他们的工作流程)。

和大多数事情一样:“这取决于你在做什么”

将图像存储在文件系统中的另一个好处是，您不需要做任何特殊的事情来让客户端缓存它们……

.．.当然，除非图像不能通过文档根访问(例如身份验证障碍)，在这种情况下，你需要检查你的代码正在发送的缓存控制头。

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

如果您使用的是较旧的数据库，那么我会说，如果您将其存储为blob数据，那么您将无法通过搜索特性的方式从数据库中获得任何内容，因此最好将地址存储在文件系统上，并以这种方式存储图像。

这样还可以节省文件系统上的空间，因为您只会在文件系统上节省确切数量的空间，甚至是压缩的空间。

此外，您可以决定保存一些结构或元素，允许您在文件系统中浏览原始图像而不需要任何db访问，或者将文件批量传输到另一个系统、硬盘驱动器、S3或其他场景—更新程序中的位置，但保留结构，当尝试增加存储空间时，也不需要尝试将图像从db中取出。

也许，它也会允许你抛出一些缓存元素，基于常用的图像url到你的web引擎/程序，所以你也把自己保存在那里。

我是一个企业文档管理系统的首席开发人员，一些客户在这个系统中存储了数百gb的文档。在不久的将来会达到tb级。我们使用文件系统方法的原因包括本页提到的许多原因以及另一个原因:存档。

我们的许多客户必须遵守行业特定的存档规则，例如存储到光盘或非专有格式的存储。此外，您还可以灵活地向NAS设备添加更多磁盘。如果你把文件存储在你的数据库中，即使使用SQL Server 2008的文件流数据类型，你的存档选项也会变得非常狭窄。

这里的诀窍是不要成为一个狂热分子。

这里需要注意的一点是，在专业文件系统阵营中没有人列出特定的文件系统。这是否意味着从FAT16到ZFS可以轻松击败所有数据库?

不。

事实上，许多数据库都胜过许多文件系统，即使我们只讨论原始速度。

正确的做法是为您的精确场景做出正确的决定，要做到这一点，您需要一些数字和一些用例估计。

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

第一个解决方案，数据库中的图像，有点“干净”，因为你的数据访问层将只需要处理数据库对象;但这只在你必须处理小数字的时候有用。

显然，当您处理二进制大对象时，数据库访问性能正在下降，数据库维度将增长很多，再次导致性能损失…通常数据库空间比文件系统空间要昂贵得多。

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

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

在做出这种选择时，还要考虑在访问二进制对象时是否必须处理权限和身份验证:当数据存储在db中时，这些必要条件通常可以以更简单的方式解决。

如果您没有使用SQL Server 2008，并且有充分的理由将特定的映像文件放在数据库中，那么您可以采用“两者兼备”的方法，将文件系统用作临时缓存，并将数据库用作主存储库。

例如，您的业务逻辑可以在提供映像文件之前检查该映像文件是否存在于磁盘上，并在必要时从数据库检索。这为你购买了多个web服务器的能力和更少的同步问题。

我更喜欢将图像路径存储在DB中，并将图像存储在文件系统中(在服务器之间使用rsync以保持所有内容的合理最新)。

然而，我所做的一些内容管理系统的工作需要在CMS中使用图像，原因有几个——可见性控制(因此资产被保留到新闻稿发布之前)、版本控制、重新格式化(一些CMS将动态调整缩略图的大小)以及将图像链接到所见即所得页面的易用性。

因此，我的经验法则是始终将应用程序的内容保存在文件系统中，除非它是CMS驱动的。

我将采用文件系统方法。不需要创建或维护带有映像的DB，从长远来看，这将为您节省一些主要的麻烦。

这取决于你要存储的图像数量和它们的大小。我曾经使用数据库存储图像，我的经验是相当不错的。

在我看来，使用数据库存储图像的优点是，

如果你的图片很小(比如<64k)和数据库的存储引擎支持内联(记录中)blob，它进一步提高性能，因为不需要间接(实现了引用的局部性)。

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

在我当前的应用程序中，我两者都在做。当用户确定要附加到记录上的图像时，我使用ImageMagick将其调整为适合在屏幕上显示的大小(对于我的应用程序约为300x300)，并将其存储在数据库中以方便访问，但随后还将用户的原始文件复制到网络共享，以便它可用于需要更高分辨率的应用程序(如打印)。

(还有一些其他的因素:Navision将只显示BMP，所以当我调整它的大小时，我也转换为BMP存储，数据库被复制到远程站点，在那里能够显示图像是有用的。打印工作只在总部进行，所以我不需要复制原始文件。

在我的小应用程序中，我至少有100万个文件，最近一次统计大约200GB。所有文件都位于通过iscsi挂载在linux服务器上的XFS文件系统中。路径存储在数据库中。对文件路径和文件名使用某种智能命名约定。

恕我直言，使用文件系统是为了做什么-存储文件。在存储二进制数据方面，数据库通常不比标准文件系统提供任何优势。

关于这个话题，这里有一份有趣的白皮书。

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

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

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

这里还有一点要记住。支持使用数据库存储blob的原因之一是符合ACID要求。然而，测试人员在白皮书中使用的方法(SQL Server的批量日志选项)使SQL Server吞吐量翻了一番，有效地将ACID中的“D”更改为“D”，因为blob数据没有在事务的初始写入时被记录下来。因此，如果完全符合ACID是您的系统的重要要求，那么在比较文件I/O和数据库blob I/O时，将SQL Server数据库写入吞吐量减半。

文件存储上的图像是最好的选择，并将元数据存储在数据库中作为补充。从web服务器的角度来看，提供东西的最快方法是直接指向它。如果它在数据库中——比如Sharepoint——你就有ADO的开销。用网把它拉出来，流出来，等等。

Documentum -虽然臃肿和复杂-有它的权利，文件是在共享和可供您决定如何存储它们-磁盘上的服务器，SAN, NAS，无论什么。Documentum的策略是根据数据库中的主键对文件夹和文件名进行编码，从而将文件存储为树状结构。DB成为了解什么文件是什么文件和加强安全性的资源。对于大容量系统，这种方法是一种很好的方法。

在处理元数据时也要考虑这一点:如果您需要更新元数据语料库的属性，DB是您的朋友，因为您可以使用SQL快速执行更新。使用其他标记系统，您手头没有简单的数据操作工具

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

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

1. 易于复制和备份
2. 能够轻松实现文档版本控制系统

如果你正在计划一个面向公众的网站，那么你不应该选择任何一个选项。您应该使用内容分发网络(CDN)。在互联网上传递大量静态内容时，CDN具有价格、可扩展性和速度优势。

没有人提到的是DB保证原子操作、事务完整性和处理并发性。对于文件系统，甚至引用完整性都不存在了——那么您如何知道您的文件名仍然是正确的呢?

如果你的文件系统中有你的图像，当你写一个新版本甚至删除文件时，有人正在读取文件-会发生什么?

我们使用blob是因为它们也更容易管理(备份、复制、传输)。他们为我们工作得很好。

我最近创建了一个PHP/MySQL应用程序，用于在MySQL表中存储pdf /Word文件(到目前为止每个文件的大小为40MB)。

优点:

• 上传的文件复制到备份服务器连同其他一切，不需要单独的备份策略(安心)。
• 设置web服务器稍微简单一些，因为我不需要有一个上传/文件夹，并告诉我所有的应用程序它在哪里。
• 我可以使用事务进行编辑以提高数据的完整性——我不必担心孤立的和丢失的文件

缺点:

• mysqldump现在需要很长时间，因为其中一个表中有500MB的文件数据。
• 总的来说，与文件系统相比，内存/cpu效率不是很高

我认为我的实现是成功的，它满足了备份需求并简化了项目布局。对于使用该应用程序的20-30人来说，性能还不错。

我将使用文件系统方法，主要是因为它具有更好的灵活性。考虑一下，如果图像的数量变得很大，一个数据库可能无法处理它。对于文件系统，您可以简单地添加更多的文件服务器，假设您正在使用NFS或kind。

文件系统方法的另一个优点是能够做一些奇特的事情，例如可以使用Amazon S3作为主要存储(在数据库中保存url而不是文件路径)。如果S3发生中断，则退回到文件服务器(可能是包含该文件路径的另一个数据库条目)。一些巫术适用于Apache或任何你正在使用的web服务器。

在必须保证引用完整性和ACID遵从性的地方，需要在数据库中存储图像。

你不能保证图像和存储在数据库中的关于该图像的元数据引用同一个文件。换句话说，不可能保证文件系统上的文件只与元数据在同一时间和同一事务中被修改。

数据数据库

文件的文件系统

在数据库中只存储映像的文件路径的问题是，不能再强制数据库的完整性。

如果文件路径所指向的实际映像变得不可用，则数据库会不知不觉地出现完整性错误。

考虑到图像是被寻找的实际数据，并且它们可以在一个集成的数据库中更容易地管理(图像不会突然消失)，而不必与某种文件系统(如果文件系统是独立访问的，图像可能会突然“消失”)，我倾向于将它们直接存储为BLOB或类似的文件系统。

在数据库中存储图像仍然意味着图像数据最终位于文件系统中的某个位置，但被遮蔽，因此您不能直接访问它。

+类型:

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

- f:

• 性能损失——数据库查找通常比文件系统查找慢
• 您不能直接编辑图像(裁剪，调整大小)

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

假设:应用程序是基于web的

我很惊讶没有人真正提到这一点……把它委托给其他专家-> 使用第三方映像/文件托管提供商。

将文件存储在付费的在线服务上，比如

• Amazon S3
• Moso Cloud Storage

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

这个线程解释了为什么你应该使用第三方托管提供商。

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

我几乎从不把它们存储在数据库中。最好的方法通常是将映像存储在一个由中央配置变量控制的路径中，并根据DB表和主键(如果可能的话)命名映像。这给了你以下优势:

• 通过更新全局配置，将映像移动到另一个分区或服务器。
• 通过搜索图像的主键来查找与图像匹配的记录。
• 您的图像可以访问处理工具，如imagemagick。
• 在web应用程序中，您的图像可以由web服务器直接处理(节省处理)。
• CMS工具和Coldfusion等网络语言可以处理本地上传。

我使用过许多数字存储系统，它们都在文件系统上存储数字对象。他们倾向于使用分支方法，因此在文件系统中会有一个存档树，通常从年份开始，例如2009，子目录将是月，例如8月，下一个目录将是日，例如11，有时他们也会使用小时，然后文件将以记录的持久ID命名。使用BLOBS有其优点，我听说它经常用于化学工业的it部分，用于存储数千或数百万张照片和图表。它可以提供更精细的安全性，单一的备份方法，潜在的更好的数据完整性和改进的跨媒体搜索，Oracle在他们过去称为Intermedia的包中有许多特性(我想它现在被称为其他东西)。文件系统还可以通过XACML或其他XML类型安全对象等系统提供粒度安全性。具体示例请参见Fedora Object Store的D Space。

在以前的一个项目中，我将图像存储在文件系统上，这在备份、复制和文件系统与数据库不同步方面造成了很多麻烦。

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

正如有人已经提到的，“视情况而定”。如果数据库中的存储被认为是文件系统的1对1替代方案，那么它可能不是最佳选择。

但是，如果数据库后端将提供额外的值，而不仅仅是blob的序列化和存储，那么它可能是真正有意义的。

你可以看看WKT光栅，这是一个旨在在PostGIS中开发光栅支持的项目，它反过来又作为PostgreSQL数据库系统的地理空间扩展。WKT光栅背后的想法不仅是定义光栅序列化和存储的格式(使用PostgreSQL系统)，而且，比存储更重要的是，指定数据库端从SQL访问的高效图像处理。长话短说，这个想法是将操作重心从客户端转移到数据库后端，这样它就尽可能靠近存储本身。WKT光栅，作为PostGIS，是专门用于特定领域的应用，地理信息系统。

要获得更完整的概述，请检查系统的网站和演讲 (PDF)。

对于大量的小图像，数据库可能更好。

我有一个带有许多小缩略图的应用程序(每个缩略图2Kb)。当我将它们放到文件系统中时，由于文件系统的块大小，它们每个都消耗了8kb。空间增加了400% !

查看这篇文章关于块大小的更多信息: iphone文件系统的块大小是多少? < / p >

如果您使用Teradata，那么Teradata Developer Exchange有一篇关于加载和检索lobs和blobs的详细文章。

http://developer.teradata.com/applications/articles/large-objects-part-1-loading

我会选择两种解决方案，我的意思是……我将开发一个小组件(EJB)，它将映像存储在DB中，并将映像存储到服务器的路径。只有当我们有一个新的图像或原始图像更新时，这个DB才会更新。然后，我还将该路径存储在业务DB中。

从应用程序的角度来看，我将始终使用文件系统(从业务DB检索路径)，通过这种方式，我们将修复备份问题，并避免可能的性能问题。

唯一的缺点是我们将存储相同的图像2次…好的一点是内存很便宜，拜托!