Jag*_*agd 5 filestream sql-server-2008
我有大约7TB的各种媒体文件(pdf,jpg,tiff),它们目前驻留在一个非常强大的文件服务器上.我正在考虑将数据移动到SQL Server 2008并使用Filestream属性来帮助我管理数据.我想这样做是因为我有管理这种媒体的网页,随着每天向文件服务器添加更多媒体,它们(网页)变得越来越慢.
编辑:网页很慢,因为它们中的许多都会生成报告,反映文件服务器的各种细节以及存储在其中的内容.从本质上讲,网页会梳理数千个文件夹和文件,以生成有关其中包含内容的报告.某些网页允许用户操作文件夹和文件并将其移动到不同的位置.因此,简而言之,我正在寻找更快的方式来管理这些文件.它还允许我在数据库中维护有关这些文件的元数据,从而允许我在数据库中查询此信息,而不是通过文件服务器为它进行梳理.
我的问题:
1)我做了一个概念验证并验证我可以在SQL Server 2008数据库本地创建一个文件流,并且我已成功读取并向其写入媒体.但是,我还没有弄清楚如何使用UNC作为文件流.换句话说,数据库托管在MySQLDB08上,我的文件存储在TheFileServer01上.我已经读过它了,但我还没到那里.任何有关这方面的帮助将不胜感激!
2)由于我有7TB(并且正在增长)的媒体,我的备份是否因其大小而无法管理？这是否可以阻止我使用Filestream？
任何建议或帮助将不胜感激!
我的问题是你想从文件流中提取什么好处？通常的好处来自BLOB与数据库操作的集成,同时保持基于Win32文件句柄的操作的可用性:
尽管FILESTREAM技术具有许多吸引人的功能,但它可能不是所有情况下的最佳选择.如前所述,在决定是将BLOB数据完全存储在数据库中还是使用FILESTREAM时,BLOB数据的大小和访问模式是最重要的因素.
大小会影响以下内容:
- 使用任一存储机制可以访问BLOB数据的效率.如前所述,使用FILESTREAM对大型BLOB数据进行流式访问更有效,但部分更新(可能更快)更慢.
- 使用任一存储机制备份组合的结构化和BLOB数据的效率.组合SQL Server数据库文件和大量FILESTREAM文件的备份将比仅具有等效总大小的SQL Server数据库文件的备份慢.这是因为备份每个NTFS文件的额外开销(每个FILESTREAM数据值一个).当FILESTREAM文件较小时(由于时间开销占每MB数据备份总时间的较大百分比),此开销变得更加明显.
从纯粹的性能角度来看,您可以在文件系统级别上执行许多步骤来提高性能.您当前的问题是什么,为什么您的系统吞吐量受媒体大小的影响？这意味着您有一个争用的焦点,可能是目录枚举,或者某个其他障碍导致您使用媒体大小缩放响应时间.您对媒体的访问应该是O(1),也许是O(logn),而不是O(n).
我建议你仔细阅读SQL Server 2008中的SQL白皮书FILESTREAM存储,从那里我找到了关于用例的引用.