从SQL Server，文件系统，S3等服务器之外提供图像

我的应用程序（经典的asp yay！）在25GB容量下具有约210万张图像，并且仅代表90天的数据，我希望至少达到365天。我需要控制这些，并正在考虑所有选择。您对以下做法的利弊有何看法：

• SQL Server优点：易于备份缺点：性能？
• 文件系统优点：速度缺点：冗余，备份速度很慢（目前正在研究进行合成完整备份，这可能会更好）
• S3之类的优点：带宽从我的数据中心转移到了Amazon，几乎无限制的存储。缺点：成本，成本分析非常棘手（估计我的带宽的80％是用于ROI的图像），如果有必要，则很难/昂贵地转嫁给服务提供商

还有其他人要应对数百万的图像挑战吗，您是如何解决的？

我们没有数百万个图像，但确实有数十万个图像，并且我们使用混合方法-mysql用于元数据，将图像存储在本地磁盘上以进行备份，然后将其推送到Amazon s3，在此将其提供给用户。我们在亚马逊和可用性方面没有遇到任何麻烦。迁移到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）

如果您决定将它们存储在文件系统中，则可能需要阅读一下ServerFault问题，以了解是否需要做：在文件系统中存储一百万个映像。

忽略那些说“ 不要在数据库中存储图像/二进制数据 ”的人，因为他们的答案基于旧信息（假设您将数据存储在VarBinary类型列中）。现在，可以通过使用SQL Server 2008中的FILESTREAM数据类型来减轻使用SQL Server存储图像的性能问题。本质上，FILESTREAM数据类型使您可以将在数据库中存储数据的简便性与从服务中获得的性能结合起来NTFS文件存储中的文件。

引用SQL Mag：

“ SQL Server 2008的新FILESTREAM支持将直接从NTFS文件系统访问LOB的好处与SQL Server关系数据库引擎提供的参照完整性和易于访问性结合在一起。”

有关更多信息，请阅读MSDN上Ravi S.Maniam的博客。

虽然我不应对数百万个映像的挑战，但我会使用Amazon CloudFront。它所有的文件都存储在S3存储桶中，但通过Amazon的内容分发系统存储在服务器中。我不会单独使用S3。

我的第二选择是文件系统。简单易行，唯一的问题是，如果所有这些文件都存放在一个目录中，那么整个事情将崩溃，很难。

对于这样的系统，SQL对我来说不是一个选择。您不仅要为带宽传输付费，还要为查询的处理付费-这将取决于托管，但我假设您使用的是专用服务器或至少要收取费用的vps为周期。然后，如果它使用与图像服务器相同的数据库，它将降低整个站点的速度。如果不是这样，那么您将不得不管理两个数据库连接而增加所有这些复杂性。

数据库设计用于事务性数据/一致性和安全性。

媒体文件（图像，音频，视频）倾向于创建甚至删除，但很少更新。因此，通常无需使它们与其他数据在事务上保持一致，并且数据库不会在那里给您带来任何真正的好处。文本内容可能是另一回事。

只要您对有人拥有文件URL的情况下直接拉出文件的概念没有任何问题，那么文件系统就可以了。如果您运行的是照片库之类的东西，而您希望在人们下载文件之前对其进行充电，则可能是另一回事。也就是说，用户付款后，他们可能会获得该用户专有的URL或仅在短时间内有效的URL，并且应用程序会处理指向同一图像的多个URL或临时URL。这仍然可以由应用程序和文件系统来处理，但是最终您将通过应用程序为媒体提供服务，而不是直接下载文件（这通常会排除S3的任何好处），并且数据库和文件系统之间的差异较小。