策略是要处理其中包含太多文件（BLOB）的SQL Server DB？

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

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

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

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

问题：
您对这个问题有什么建议？将文件存储在文件系统中？将数据库分成两部分，并为文件分配一个更大，更慢的文件？

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

我照顾一个非常相似的数据库，目前为3TB，每天增长5GB。

• Filestream（2008+）不能解决备份/还原难题。
• Paul Randal的测试表明，对于大于1MB的文件，Filestream的性能要优于LOB存储。它的工作量取决于256KB-1MB，并且通常小于<256KB。
• 在某些环境中，Filestream的一大优点是它绕过了缓冲池，而是使用Windows系统缓存。
• 如果将文件放在文件系统上，则会失去与数据库记录的事务一致性。您还增加了备份数百万个单独文件的开销，这可能很麻烦。

权衡Filestream的优缺点，看是否适合您的情况。在我们的案例中，我们采取了另一条路线，并选择了对数据库进行分区，因此我们可以利用部分可用性/零碎恢复。

您可能无法使用的一种选择是将较旧/归档文件组标记为只读。然后可以不经常备份只读文件组。

如果您坚持使用2005 Standard（分区是企业版功能），并且可以选择对历史记录进行只读操作，则可以采用老式的方法来解决。

• 拆分表。您可以考虑活动/历史路线或基于日期的日期，例如每月表格。
• 将历史数据放置在只读文件组上，并仅在存档其他数据时备份。确保您的用户了解这只会减少备份时间。当您没有部分可用性功能时，还原可能需要一段时间。
• 在表上创建分区视图。

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

尝试使用SQL Server中的FILESTREAM功能，

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

关于它的好文章

1. SQL Server FileStream简介
2. 到BLOB或不到BLOB：数据库或文件系统中的大对象存储
3. SQL Server 2008中的文件流存储