SQL Server
优点：易于备份
缺点：性能？
文件系统
优点：速度
缺点：冗余，备份很慢（目前正在研究进行合成完整备份，这可能会更好）
S3等
优点：带宽从我的数据中心转移到了几乎没有限制的亚马逊存储。
缺点：成本，成本分析非常棘手（估计我的带宽的80％是用于ROI的图像），如果有必要，则很难或昂贵地转向服务提供商
还有其他人可以应对数百万的图像挑战吗？您是如何解决的？
#1 楼
我们没有数百万个图像，但确实有数十万个图像，我们使用混合方法-mysql用于元数据，图像存储在本地磁盘上用于备份，然后推送到Amazon s3，在此将它们提供给用户。我们在Amazon和可用性方面都没有遇到任何麻烦。迁移到Cloudfront是我们的计划，只需寻找时间。此讨论可能对您的决定有所帮助：http：//ask.metafilter.com/59635/Millions-of- images
我将使用SQL Server中的元数据和文件系统（或s3或cloudfront）上的文件。但是最好的答案取决于其他一些使用模式：
图像是否经常更改
您可以直接从文件系统（即
img src="..."）提供图像吗？需要他们进行访问控制。如果是后者，那么数据库解决方案是最佳的是您大部分时间是否在提供少量图像（最近的10％），还是分发相对广泛。
的备份无论您如何安排，数百万张图像都会变得很复杂-这只是大量数据。在致力于该解决方案之前，我想找到一个很好的案例研究，以备份SQL Server中的Blob。 （以下文章可能会有用：http://www.databasejournal.com/features/mssql/article.php/3738276/Storing-Images-and-BLOB-files-in-SQL-Server-Part-4.htm ）
评论
备份将变得很复杂，但是至少对于文件级备份，您（通常）不必仅还原一个记录/图像就还原整个备份。 IMO，默认情况下是文件系统，除非数据库为您提供了您否则无法做的事情。 +1
–JasonBirch
2010年7月15日在23:35
文件系统是为存储文件而设计的-您可以找到为有效存储数百万个文件而设计的文件系统。数据库是为诸如元数据之类的东西而设计的-查询和关联。除非您的图像很少，否则这可能是最好的方法（不包括云解决方案）。
– dmsnell
10年7月16日在12:31
#2 楼
如果您决定将它们存储在文件系统中，则可能需要阅读一下ServerFault问题，以了解是否需要做：在文件系统中存储一百万个图像。#3 楼
忽略说“不要在数据库中存储图像/二进制数据”的人，因为他们的答案基于旧信息（假设您将数据存储在VarBinary类型列中）。现在，可以通过使用SQL Server 2008中的FILESTREAM数据类型来减轻使用SQL Server存储图像的性能问题。本质上，FILESTREAM数据类型使您可以将在数据库中存储数据的便利性与从服务中获得的性能结合起来NTFS文件存储中的文件。引用SQL Mag：
“ SQL Server 2008的新FILESTREAM
支持结合了
直接从NTFS访问LOB的优点。
具有参考性的文件系统
SQL Server关系数据库引擎提供的完整性和易于访问性
。“
有关更多信息info在MSDN上阅读了Ravi S.Maniam的博客。
评论
FILESTREAM存储是否会完全更改备份/还原故事？这是我们目前最大的麻烦……如果将它们存储在VarBinary中，那将是相对简单的故事。
– Webjedi
2010年7月26日23:57
否，FILESTREAM数据与其他数据一样被处理，因此将与数据库一起备份。引用MSDN：“您可以将所有备份和恢复模型与FILESTREAM数据一起使用，并且FILESTREAM数据将与数据库中的结构化数据一起备份。” -technet.microsoft.com/zh-CN/library/bb933993.aspx
– Dan Diplo
2010年7月27日在8:35
#4 楼
尽管我不应对数百万个映像的挑战，但我会使用Amazon CloudFront。所有文件都存储在S3存储桶中，但通过Amazon的内容交付系统存储在服务器中。我不会单独使用S3。我的第二个选择是文件系统。简单易行，唯一的问题是，如果所有这些文件最终都存放在一个目录中，那么整个事情都会崩溃，很难。对我来说，对于这样的系统，SQL并不是我的选择。您不仅要为带宽传输付费，还要为查询的处理付费-这将取决于托管，但我假设您使用的是专用服务器或至少要收取费用的vps为周期。然后，如果它使用与图像服务器相同的数据库，则会降低整个站点的速度。如果不是这样，那么您将不得不管理两个数据库连接而增加所有这些复杂性。
评论
在我的情况下，目前所有内容都在我拥有的服务器上。因此，本身就没有交易成本。
– Webjedi
2010年7月15日在22:16
#5 楼
数据库设计用于事务数据/一致性和安全性。倾向于创建和删除媒体文件（图像，音频，视频），但很少更新。因此，通常不需要使它们与其他数据在事务上保持一致，并且数据库不会在那里给您带来任何真正的好处。文本内容可能是另一回事。
只要您对有人拥有文件URL的情况下直接拉出文件的概念没有任何问题，那么文件系统就可以了。如果您运行的是照片库之类的东西，而您希望在人们下载文件之前对其进行充电，则可能是另一回事。也就是说，用户付款后，他们可能会获得该用户专有的URL或仅在短时间内有效的URL，并且应用程序会处理指向同一图像的多个URL或临时URL。这仍然可以由应用程序和文件系统来处理，但是最终只能通过应用程序为媒体提供服务，而不是直接下载文件（这通常会排除S3的任何好处），并且数据库和文件系统之间的差异较小。
评论
不要不不不不将图像数据（斑点）存储在数据库中。许多年前，我们就犯了这个错误，从那以后一直为此付出代价。虽然数据库非常适合元数据。请参阅我关于FILESTREAM数据类型的文章-可能会改变主意。