it-swarm.cn

从SQL服务器与文件系统与S3等服务图像

我的应用程序(经典的asp yay!)有大约210万张@ 25GB的图像,只代表90天的数据,我想至少要365。我需要控制住这些并考虑所有选择。您对以下做法的利弊有何看法:

  • SQL Server专业版:易于备份缺点:性能?
  • 文件系统优点:速度缺点:冗余,备份速度很慢(目前正在研究做综合完整备份而不是更好)
  • S3之类的优点:带宽从我的数据中心转移到亚马逊,几乎无限存储。缺点:成本,成本分析是棘手的(估计我的带宽的80%是用于ROI目的的图像),如果有必要,很难/昂贵的服务提供商

有没有其他人处理数百万的图像挑战,你是如何解决它的?

12
Webjedi

我们没有数百万张图片,但确实有数十万张图片,我们使用混合方法 - mysql用于元数据,存储在本地磁盘上的图像用于备份,并推送到Amazon s3,在那里向用户提供。我们对亚马逊和可用性没有任何问题。迁移到云端是我们的计划,只需要找到时间。

这个讨论可能对您的决定有所帮助:
http://ask.metafilter.com/59635/Millions-of-images

我会使用SQL服务器中的元数据和文件系统(或s3或cloudfront)上的文件。但最好的答案取决于其他一些使用模式:

  • 经常改变图像
  • 你可以直接从文件系统提供图像(即img src="..."),还是需要它们进行访问控制。如果是后者,那么数据库解决方案是最好的
  • 你是在大多数时间服务少量的图像(最近10%)或分布相对广泛。

无论你如何安排数百万张图像的备份都会很复杂 - 这只是大量的数据。在我致力于解决方案之前,我想找到一个关于在SQL服务器中备份blob的好案例研究。 (这是一篇可能有用的文章: http://www.databasejournal.com/features/mssql/article.php/3738276/Storing-Images-and-BLOB-files-in-SQL-Server-Part -4.htm

6
mooreds

忽略那些说“不要将图像/二进制数据存储在数据库中”的人,因为他们的答案基于旧信息(假设你将是将数据存储在VarBinary类型列中)。现在可以通过在SQL Server 2008中使用 FILESTREAM 数据类型来缓解使用SQL Server存储图像的性能问题。本质上,FILESTREAM数据类型允许您将数据存储的简易性结合起来具有从NTFS文件存储中提供文件所获得的性能的数据库。

引用 SQL Mag

“SQL Server 2008的新FILESTREAM支持结合了直接从NTFS文件系统访问LOB的好处,以及SQL Server关系数据库引擎提供的参照完整性和易用性。”

欲了解更多信息,请阅读 由MSV上的Ravi S.Maniam撰写的这篇博客

3
Dan Diplo

如果你决定将它们存储在文件系统中,你可能想要读一下这个ServerFault问题,而不是: 在文件系统中存储一百万个图像

3
Mark Henderson

虽然我没有处理数百万的图像挑战,但我会使用Amazon CloudFront。所有文件都存储在S3存储桶中,但是通过亚马逊的内容传送系统服务器。我不会单独使用S3。

我的第二选择是文件系统。简单易行,唯一的问题是如果所有这些文件都在一个目录中结束,整个事情就会崩溃,很难。

对我来说,SQL不适合像这样的系统。您不仅需要为带宽传输付费,还需要为处理查询付费 - 这将取决于托管,但我认为您使用的是专用服务器,或者至少需要向您收取费用对于周期。然后,如果它使用与图像服务器相同的数据库,它将减慢整个站点的速度。如果没有,那么您添加了必须管理两个数据库连接的所有这些复杂性。

2
Frank Robert Anderson

数据库专为事务数据/一致性和安全性而设计。

媒体文件(图像,音频,视频)往往会被创建并可能被删除,但很少更新。所以一般来说,没有必要让它们在事务上与其他数据保持一致,数据库也不会给你带来任何实际好处。文本内容可能是另一回事。

只要你有文件的URL直接拉动文件的概念没有任何问题,那么文件系统就可以了。如果您正在运行像照片库这样的东西,您希望在人们下载文件之前收取费用,那么这可能是另一回事。也就是说,一旦用户付费,他们可能获得特定于该用户的URL或仅在短时间内有效,并且该应用程序处理指向同一图像的多个或临时URL。这仍然可以由应用程序和文件系统处理,但您最终通过应用程序而不是直接文件下载(这将主要排除S3的任何好处)提供媒体,并且DB和文件系统之间的差异较小。

1
Gary