SQL Server 2008 文件流性能

Question

我对 SQL Server 2008 的 FILESTREAM 功能有一些疑问。

1. 使用 FILESTREAM 功能与使用 FILESTREAM 功能返回从 SQL Server 2008 流式传输的文件在性能上有何差异？直接从共享目录访问文件？

2. 如果 100 个用户在 10 秒的窗口内请求 100 100Mb 文件（通过 FILESTREAM 存储），SQL Server 2008 的性能是否会慢得像爬行一样？

Answer 1

如果 100 个用户在 10 秒的窗口内请求 100 100Mb 文件（通过 FILESTREAM 存储），SQL Server 2008 的性能是否会慢得像爬行一样？

在什么样的服务器上？什么样的硬件来服务这些文件？什么样的磁盘、网络等？这么多的问题.......

Paul Randal 在 上发表了一篇非常好的博客文章 SQL Server 2008：文件流性能 - 一探究竟。还有一个 关于 FILESTREAM 的 25 页白皮书 可用 - 还涵盖一些性能调整技巧。

---

但也请查看微软研究院技术报告 BLOB 或不 BLOB.

这是一篇非常深刻、基础非常扎实的文章，将所有这些问题都解决了。

他们的结论是：

研究表明，如果对象 是 平均大于一个兆字节, ，NTFS具有明显的优势 通过 SQL Server。如果对象是 低于256千的数据库，数据库具有明显的优势. 。在这个范围内， 这取决于写入密集程度 工作负载是，并且存储期限 系统中的典型副本。

因此，从这一点来看，如果您的 blob 通常小于 1 MB，只需将它们作为 VARBINARY(MAX) 存储在数据库中。如果它们通常较大，则只需使用 FILESTREAM 功能即可。

我不会太担心性能，而不是 FILESTREAM 相对于 NTFS 文件夹中的“非托管”存储的其他优势：在没有 FILESTREAM 的情况下将文件存储在数据库外部，您无法控制它们：

• 数据库不提供访问控制
• 这些文件不是 SQL Server 备份的一部分
• 这些文件不是以事务方式处理的，例如您最终可能会得到数据库中不再引用的“僵尸”文件，或者数据库中的“骨架”条目，而磁盘上没有相应的文件

仅这些功能就使得使用 FILESTREAM 绝对值得。

Answer 2

通过 Win32 读取 FILESTREAM 相当快。看 使用 Win32 管理 FILESTREAM 数据. 。您应该遵循 文件流最佳实践 尽管。毕竟，这就是 权力 Sharepoint MS 不会把像 Office (==Sharepoint) 这样重要的东西押在性能不佳的存储上。有一些关于 FILESTREAM 的案例研究和白皮书，我只能挖掘一下 Laren Electronics 使用 SQL Server 促进一级方程式赛车数据分析 但我知道还有更多更详细的数字数据。如果我没记错的话，它表明在一定的文件大小上，FILESTREAM 通常会影响 SMB 性能约 90-95%。对于小文件，获取 FILESTREAM API 句柄的开销开始显现。

我还赞同 Marc 建议阅读有关该主题的研究论文（还有第 9 频道对 Catharine van Ingen 的采访，也可在 iTunes 播客上观看，她在其中谈到了这项工作），但请记住，该论文发表于 2006 年 前 FILESTREAM 已正式发布，因此不考虑 FILESTREAM 细节。

至于你的第二个问题，仅通过指定负载而不指定系统容量来询问性能是没有意义的。具有大量存储 SAN 的 128 个 CPU Superdome 甚至不会注意到您的负载。在装有大量间谍软件的 256 MB 笔记本电脑上运行的 SQL 甚至无法看到您的负载...