处理包含过多文件 (BLOB) 的 SQL Server 数据库的策略？

Question

场景：
SQL Server 2005 数据库为 ASP.NET 应用程序提供服务（在单独的 Web 服务器上）。

数据库：
DB 中有大约 5GB 的“正常”数据，以及大约 15GB 的“文件”（例如：200k PDF 存储为图像（BLOB），诸如此类）。用户上传的文件越来越多，并且正在迅速消耗更多的磁盘空间（在接下来的几个月中，DB 可能会增长到 50GB，主要是文件）。

顾虑：
在数据库中存储如此多的文件已经引起了问题（例如：数据库的总大小很大使得偶尔的整个数据库备份和部署变得困难。）。

而且我们担心会出现更多问题。（例如：性能问题 - 可能是由于无法将整个数据库保存在 RAM 中引起的，也许？）

问题：
您对这个问题有什么技术解决方案？将文件存储在文件系统中？将数据库一分为二，并为文件使用一个更大、更慢的数据库？

如果需要更多详细信息：
这些文件不是非常重要，并且不需要非常快的访问时间 - 几秒钟就可以了，目前最多每小时可能有十几个选择。数据库中的其他“正常”数据包括每秒需要多次的信息。

Answer 1

我负责管理一个非常相似的数据库，目前为 3TB，并且每天增长 5GB。

Filestream (2008+) 没有解决备份/恢复挑战。
对于大于 1MB 的文件，Filestream 的性能优于 LOB 存储，因此 Paul Randal 的测试表示。它的工作负载依赖于 256KB-1MB，通常在 <256KB 时更糟。
在某些环境中 Filestream 的一大优点是它绕过缓冲池并使用 Windows 系统缓存。
如果将文件放在文件系统上，则会失去与数据库记录的事务一致性。您还增加了备份数百万个单独文件的开销，这可能很麻烦。

权衡 Filestream 的利弊，看看它是否适合您的情况。在我们的例子中，我们采取了不同的方法并选择对数据库进行分区，以便我们可以利用部分可用性/分段恢复。

我们不可用的一种选择（您可能有）是将旧的/存档文件组标记为只读。然后可以不经常备份只读文件组。

如果您坚持使用 2005 标准版（分区是企业版功能）并且您可以选择历史只读，那么您可以用老式的方式解决这个问题。

最后一个选项（我们正在考虑用于我们的 3TB blobber）是将文件数据移动到文档数据库或云存储（例如AmazonS3、Azure BLOB 存储）。这确实引入了我之前提到的事务一致性问题，但它减轻了那些非常昂贵的 SQL Server 的负担。

Answer 2

尝试SQL Server 中的FILESTREAM功能，

FILESTREAM 通过将 varbinary(max) 二进制大型对象 (BLOB) 数据存储为文件系统上的文件，将 SQL Server 数据库引擎与 NTFS 文件系统集成

关于它的好文章