SQL Server 2008 FILESTREAM性能

Question

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

1. 使用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 Performance - 查看它.还有一篇关于FILESTREAM的25页白皮书 - 还包括一些性能调优技巧.

但也请查看Microsoft Research TechReport To BLOB或Not To BLOB.

这是一篇非常深刻且基础非常好的文章,通过他们的步伐提出所有这些问题.

他们的结论:

该研究表明,如果对象平均大于1兆字节,NTFS具有明显优于SQL Server的优势.如果对象 低于256千字节,则数据库具有明显的优势.在此范围内,它取决于工作负载的写入密集程度以及系统中典型副本的存储时间.

因此判断 - 如果您的blob通常小于1 MB,只需将它们存储为数据库中的VARBINARY(MAX)即可.如果它们通常较大,则只有FILESTREAM功能.

我不担心性能而不是FILESTREAM的其他好处而不是NTFS文件夹中的"非托管"存储:在没有FILESTREAM的情况下将文件存储在数据库之外,你无法控制它们:

• 没有数据库提供的访问控制
• 这些文件不是SQL Server备份的一部分
• 这些文件不是以事务方式处理的,例如你最终可能会得到"zombie"文件,这些文件不再从数据库中引用,或者数据库中没有相应文件的"骨架"条目

单独使用这些功能使得使用FILESTREAM绝对值得.

Answer 2

通过Win32读取FILESTREAM非常快.请参阅使用Win32管理FILESTREAM数据.您应该遵循FILESTREAM最佳实践.毕竟,这就是Sharepoint和MS不会对Office(== Sharepoint)在不良性能存储上打赌的重要性.有关FILESTREAM的一些案例研究和白皮书,我只能用SQL Server挖掘一级方程式赛车数据的拉伦电子燃料分析,但我知道有更多更详细的数值数据.如果我没记错的话,它表明FILESTREAM通常会在一定的文件大小下影响SMB性能约90-95%.对于小文件,开始显示获取FILESTREAM API句柄的开销.

我也是第二个Marc推荐阅读关于这个主题的研究论文(还有一个Channel 9采访Catharine van Ingen,也可以在iTunes播客上获得,她会谈到这项工作),但请记住这篇论文在 FILESTREAM正式发布之前于2006年发布,因此它不考虑FILESTREAM细节.

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