18

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

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

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

4

2 回答 2

24

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

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

Paul Randal 有一篇关于SQL Server 2008的非常好的博客文章：FILESTREAM Performance - 查看。还有一份关于 FILESTREAM 的 25 页白皮书- 还涵盖了一些性能调整技巧。

但也请查看 Microsoft Research TechReport To BLOB or Not To BLOB。

这是一篇非常深刻且基础非常好的文章，它解决了所有这些问题。

他们的结论：

研究表明，如果对象平均大于 1 兆字节，NTFS 比 SQL Server 具有明显的优势。如果对象 小于 256 KB，则数据库具有明显优势。在此范围内，这取决于工作负载的写入密集程度以及系统中典型副本的存储年龄。

因此，据此判断 - 如果您的 blob 通常小于 1 MB，只需将它们作为 VARBINARY(MAX) 存储在数据库中。如果它们通常更大，那么只有 FILESTREAM 功能。

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

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

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

于 2009-12-29T21:42:34.827 回答
7

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

在推荐阅读有关该主题的研究论文时，我还第二次推荐 Marc（还有对 Catharine van Ingen 的第 9 频道采访，也可以在 iTunes 播客上找到，她在其中谈到了这项工作），但请记住，该论文在 FILESTREAM 正式发布之前于 2006 年发布，因此它不考虑 FILESTREAM 的具体情况。

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

于 2009-12-29T21:52:11.667 回答