SQL Server 2008 FILESTREAM性能

我有一些关于sql Server 2008的FILESTREAM功能的问题。

>使用FILESTREAM功能返回从sql Server 2008流传输的文件与从共享目录中直接访问文件的性能有什么不同？
>如果100个用户在10秒钟的窗口内请求100个100Mb文件(通过FILESTREAM存储)，sql Server 2008的性能会缓慢的爬行？

解决方法

如果100位用户在10秒钟的窗口内请求100个100Mb文件(通过FILESTREAM存储)，sql Server 2008的性能会缓慢的爬行？

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

保罗·兰达尔(Paul Randal)在SQL Server 2008: FILESTREAM Performance发表了一篇非常好的博客文章，看看吧。还有一个25-page whitepaper on FILESTREAM可用 – 还包括一些性能调优提示。

还可以查看Microsoft Research TechReport To BLOB or Not To BLOB。

这是一篇非常深刻和非常好的文章，将所有这些问题放在脚步之上。

他们的结论：

The study indicates that if objects
are larger than one megabyte on
average,NTFS has a clear advantage
over sql Server. If the objects are
under 256 kilobytes,the database has
a clear advantage. Inside this range,
it depends on how write intensive the
workload is,and the storage age of a
typical replica in the system.

所以从此判断 – 如果你的blob通常小于1 MB，那么只需将它们作为VARBINARY(MAX)存储在数据库中。如果它们通常较大，那么只需要FILESTREAM功能。

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

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

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